Xojo 2019 Release 2.1

Xojo 2019 Release 2.1 hit the web today.  If you are using R2 and any of API 2.0 this dot release is a must for you.  I almost would have almost preferred this release to be called R3.  The biggest change in Release 2.1 is that the API 2.0 events have been dropped from API 2.0 entirely.  There are also quite a few other changes and bug fixes that might impact your projects too.

Removal of the API 2.0 events was a concession to the 3rd party Xojo market (myself included).  There really was just no tenable way for Xojo developers to support both the old and new events simultaneously and after much lobbying and teeth gnashing they were removed.  

If you had implemented the new Events the R2.1 IDE will rename them back to the old events.  This is a good feature, but I’m always leery of the IDE changing code on me without my knowledge.  I recommend making a backup of your project before using this release.

Not everything is perfect with API 2.0 as it’s still hard to provide backwards compatibility with versions of Xojo prior to R2.1.  All of the new API 2.0 Properties and class Methods are significantly different and permanently change your source code that is not compatible with pre-API 2.0 versions of Xojo.  To help with this Xojo has added a new compatibility flag under the Gear icon in the Inspector that works with classes and properties.  You can check if the Object, Method, or Property is API 1 or API 2 compatible.

Really, these flags should be titled XojoVersion < 2019.021 and XojoVersion >=2019.02.1 to make it more clear.  But in reality this means that a Xojo developer must be using Xojo 2019 R2.1 or better to take advantage of these flags.  To be honest I’m still unclear on how these flags really work and the documentation regarding them is sparse.

Another change is a new menu option called Analysis Warnings under the Project Menu.  This dialog lets you pick and choose which warnings to see when you Analyze your project.  If you set “Item X is deprecated.  You should use Item Y instead,” to false you will no longer receive the API 2.0 deprecation warnings.  This is set to false by default so you won’t receive the deprecation warning unless you go looking for it.

The FolderItem class has new methods:  CreateFolder, CopyTo, MoveTo, and Open that now raise exceptions.

Window.Controls is now Iterable and you can use them in a For Each Loop to iterate through all controls on a window.

The DateTime class now has an optional parameter that lets you specify the TimeZone.

There are ton of bug fixes.  Here are some of the highlights:

The IDE no longer crashes on macOS 10.15 (Catalina) when clicking on a color swatch in the Inspector and then navigating to another control before closing the color picker.

RemoveAllRows no longer crashes the application under certain circumstances.

The Database Editor no longer throws exceptions when dropping table columns.

They fixed a number of memory leaks.  This includes (but probably not limited to) ODBCDatabase when binding parameters to prepared statements, MSSQLServerDatabase when using Prepared statements.  When database objects go out of scope or are set to nil.

There are numerous examples of Deprecations with Replacement warnings now working properly with various classes.  Constants have been replaced with more enums and so on.  There’s just a boatload things working better with API 2.0.

In general if you are already using R2 then you MUST upgrade to R2.1.  If you’re not using R2 then I still suggest waiting for at least another cycle since more bugs will be found and probably a few more things tweaked.

If you feel like you’ve wasted your time with R2 I feel your pain.  The whole R2 cycle was really long yet API 2.0 was rushed through without much  thought about the existing Xojo community and ecosystem despite attempts at communicating this information.  I just don’t see the benefits of disrupting the entire user base, 3rd party ecosystem, not to mention 20 years of documentation, internet search engine results and so on, for what, in my opinion, are arbitrary and meaningless name changes.  Some of the name changes make little sense but that’s a different argument that I’ve made before.

Personally, I would have appreciated the approach that they took with the URLConnection class that replaced HTTPSocket.  It was a new class and you didn’t have to use it.  It is using the new style exceptions rather than relying on error codes and it is a complete break from the old class.  They did this with DateTime and RowSet and I’m fine with those.  But having FolderItem (and other classes) now doing double duty depending on *how* you create them is a long-term support disaster.

So there you go Xojo coders.  Xojo 2019 R2.1 is out and it’s better than R2 and has major changes that make our lives a little easier.  What are your thoughts about Xojo 2019 R2.1?


[Edit] Apparently the Analysis Warnings dialog is NOT new. I’ve just never noticed it and, until now, I guess I’ve never needed to care.

24 thoughts on “Xojo 2019 Release 2.1

  1. Rush job as usual. From my 130 errors when opening my main project there are 30 left.

    I really don’t understand how you can be that out of touch with reality. This is from Geoff:

    I understand that API 2.0 does not feel like a benefit to you. However, that’s not what we are hearing from the majority of customers. R2 is the most-used version of Xojo and we are getting very few complaints. I’m not saying that your feelings are unwarranted. I’m just telling you what we are seeing on our end.

    So it was just us whiners from the forum.

    • I think the statistical verbiage arguments defining who is the average customer misses the point. I wouldn’t say Geoff is characterizing the vocal forum users as whiners, but that he was/is tone deaf to feedback based factual consequences. Renaming the events was a stupid move for “ALL” customers. In that same forum thread Geoff said, “If less than 200 users are using the forum on a regular basis and there are many thousands of forum users, then that regular group Is statistically insignificant.” This shows a real disregard for for the valuable input from those users who know the product the very best. Something that destroys the third party market and screws up backwards compatibility show a reckless disregard for the truth and their bottom line.

      The release of R2.1 is just one data point. In the future, will they stop being so tone deaf to the users who give them the best feedback on what is wrong with the product?

      • There arent “thousands of forum users”
        There ARE thousands of forums members but how many of them have been active in the past year ? 2 years ?
        Do you count someone as “active user” when they have not even logged in, never mind posted, in many months or years ?

      • The mention of less than 200 active users being statistically insignificant is taken out of context.

        Dave Sizemore was suggesting that those that are complaining represent a significant portion of the users. He then went on to say that of the 19,000, less than 200 are active. That of course implies that 200 at the maximum would represent a significant portion of our users which is obviously not true.

        We do not disregard those who bring up issues on the forum. However, it’s important to recognize that the active forum users do in fact represent only a tiny fraction of our total active user base. That’s why it’s important that if you have an issue with something in Xojo itself, create a case in Feedback.

        • Geoff,

          In my experience in many environments most people when unhappy about something, particularly when they feel they feel they have little chance of changing it, simply don’t say anything.

          Those on the forum tend to be those most engaged with the product be they pros or citizen developers… As such they tend to be more vocal.. but that does not mean that the issues we experience are not being felt by the “silent majority” as well to coin a phrase and date myself! 😉

          In response to me in the locked thread your said:
          “Licensed users as that’s what is going on: a license key check.”

          How can you know if they are just “kicking the tires” or seriously using it? One way might be to see if the same license keys are ALSO being used with IDEs <2019R2… Don't know if you are doing that or not.

          You also said:
          "Most users download the latest version and just continue their projects."

          That was mostly true for me pre 2019r2…

          Not being able to even do as Save As to fork in R2+, and still be able open in less than than R2 changed that for me. (though when I have time I think I can "fix" that)

          you said:
          "However, most users (of again nearly any language/tool) aren't creating large, sophisticated applications. They are creating smaller apps that solve discrete problems."

          I am not sure how small an application needs to be to be considers small but i can say the times I have banged out a project for use at work in less than a week have been few and far between…

          Those that will be used by others are can take much longer…

          I think over time most users that stay with teh product tend to undertake more and more ambitious projects as their skills improve…

          And when doing things for work one needs to make changes over time as needs change. Those can be "customers forever" if you keep them happy.

          The 2nd app I did for my current job was something i wrote about 8 years ago that people use to submit testing requests remotely to my department … It had a lot of UI and a database from which the request was built, and it produced PDF, emailed to us etc … it is used everyday by people in other departments, but as things change every once in awhile I need to update it… there is no way I have the time to redo it in API 2 and because it needs to run on some old machine I need it to stay backwards compatible, and I do saves to fork to try new things…

          My last big project was more complex. it took me about 2 months to get the basic functionality down, and then was gradually improved over the next year to do everything needed…

          I did move up in IDE's while writing it, but doing that had no real risk of losing backwards compatibility even when I did a Save As to fork…

          Let me give you some idea about what it involved.
          At work the chemists in another group were trying to create a chemical reaction to create a certain class of compounds in a certain size range. The thing is their reactions were producing between about 200 to over 500 compounds in a single experiment and they were running 8 of those a day… My job was to identify as many as i could and compile the data in a way that let them understand what the reaction was doing so they could optimize it to give mostly what we wanted to make.

          I was using GCMS (Gas Chromatography/ Mass Spectroscopy) to separate and try to ID what what they were… If you have been an NCIS fan, that instrument is what Abbie called "Major MassSpec"…

          Unfortunately much of the time it does not produce definitive answers as easily as on TV!

          It gives a list of most likely matches for each peak, and the top match is not always the right one.

          But even if it was, to compile the data in a useful fashion I needed information about the chemical properties and structure of each compound… To get that I had to take the GCMS match result for each peak and use that to search several databases on the web to get the information I needed (and one thing was a way of representing the structure as an ASCII string – called SMILES- that I could the analyze to determine the relevant chemical class(es) the compound belonged to)…

          I stored all that in a database for all the top matches for every peak so as not need to search the for the same ones over and over.

          I also stored the information for each peak for each sample in the database.

          I used that peak data to produce hand coded custom PDF reports for each sample with graphs, summary of amounts by class and size etc, as well as lists of all the compounds by class and retention time, with their names, boiling points, and chemical structures from the database.

          All of this let them make sense out of that mass of data they produced so they could figure out what to try next.

          Each report could be 30+ pages.

          teh app also produced an interactive graph of the sample of different paramters of summary dat, to see trends in the data.

          For samples that looked "interesting" one could hover ofter that point to show the summary info that sample, or pop up a full report by double clicking on…

          But remember I said the top match is not always right? Well i realized one additional piece of information I get from this net databases would also help me to eliminate unlikely matches and so improve the results so worked to add that…

          Anyway a lot of work… while l working on that I did move to new IDE's… but would not if AP2 had come out during that time- though I would have fired up such a release up to look at it.

          You may be right in that new users are likely only doing only small projects… but new users don't stay new…

          At least that is how it seem to me!

          – Karen

        • I do presume that Geoff knows something about statistical sampling. So he could say that the sample might not be representative (though he would need to specify in which regard), but to claim that „200 users is statistically insignificant“ is insincere at best.

        • I wrote, “I think the statistical verbiage arguments defining who is the average customer misses the point.” You saying that I took your words out of context shows that you don’t understand this point. Arguing with customers about what is or is not statistically significant for gathering valid input is completely tone deaf. You should have not gotten into this argument in the first place!

          The goal is to arrive at the truth and then make proper decisions based on the truth. Those in the forum and the beta testers are the ones who are the most intimate with Xojo and therefore can give you the best feedback. Why did you ignore the repeated beta tester warnings about the event naming consequences? That is what is really at issue here because it is direct evidence that you don’t listen to the voice of the customer which is backed up by the reversal with R2.1 and the removal of R2.0.

          You could have saved a lot of time, money, and angst with the customer base if you would have listened. Yet you continue to argue meaningless points on the forum and here in an effort to defend what you said. All you are doing is increasing the offense and creating more ill will. Look at the responses to your comments here, are they glowing reports of how excellent it is is to ignore valuable customer input? Look at the last few posts Bob wrote on this blog.

          – Comparing Lazarus to Xojo
          – Customers For Life
          – Ruminations on API 2.0
          – I’m Not Xojo’s Target Audience. Is Anyone?
          – I’m Tired

          I think one of the most tell things Bob wrote from those posts is as follows.

          —–

          Bob wrote:

          One of the topics that I brought up was that these issues (the new Event names and marking anything from API 1.0 Deprecated – even though they’ll be around for a many years to come) were brought up early and often in the beta program. I said that honestly, it made us feel that our input is not valued. Geoff’s response is that the beta testers that brought these issues up is a small subset of the overall beta program and what they (Xojo) didn’t realize was those beta testers have other Xojo developers behind them (other Xojo developers) that aren’t in the beta program. They assumed that most of our users were using the most recent version of Xojo.

          So, in other words, the biggest, most active users of their development tool, that are in the beta program because they want to be and need Xojo to work because of THEIR clients, their concerns could be ignored. It means the professional Xojo users aren’t considered a part of their target audience.

          —–

          The forum and beta tester inputs are your most valuable inputs as demonstrated by the R2.0 fiasco. You didn’t listen to them and it blew up in public view. The event naming problem was not a difficult case to discern the horrific consequences if it were released, so what is it that blinded you to the point where you ignored the warnings? The answer is hubris.

  2. Ok, let’s cut a long story short:

    I installed 2019R2.1 2 hours ago. I opened our most significant project, which was even running fine on 2019 R2. After running the project in the IDE it crashes, within seconds. Again, this program did not crash in any release for the past years.

    It is late here in Europe now: 3am16. But this is not the only reason why I’m giving up on Xojo, and I was a loyal customer for many years. We don’t have the time to deal with a broken IDE, which seems even to break more, release by release.

    Due to our customers, we depend on the Xojo product for the time being. And I yet don’t have an alternative to program Windows Services. Xojo is doing great on that.

    But we have no other choice, unfortunately, to move as fast as we can to a more sustainable programming tool.

    I’m sorry, but it is time to leave ASAP.

    • Ok, I am a big supporter of fairness: After some debugging, it turns out that the root cause of my IDE crash was a bad plugin, which on top got already updated, and I have overlooked this fact.

      Nevertheless, the author of the plugins had to publish many updates in recent weeks. Unfortunately, this is, of course, due to the whole mess of API 2.0 and an unsustainable roadmap. Though the issue wasn’t Xojo’s mistake, it stays very disappointing for a professional “end-user” who is making a life with programming and needs a stable product.

      • I say it again: the root cause of the problems is the Rapid Release Model. I predicted at its introduction that Xojo would become a perpetual beta quality product, that stability and reliability are being sacrificed for flashy new features that aren‘t properly working while bugs would accumulate, and that‘s exactly what we got.

        It wasn‘t rocket science to see this coming.

        • P.S. the mind set of most Xojo users seems to be „but it will be better next release“ – that is the mind set of a drug addict. Just look at Xojo for iOS – has it become what it was supposed to be?

        • The Rapid Release Model (RRM) is not the root cause of the quality problems. The RRM just means they release on a predictable schedule. Big features may take a year or more to implement and the RRM does not force them to release software in a 3 month cycle. When a feature is done, then it enters the release cycle.

          The requirements and design can have a major impact on the quality of the software. Again this is not a function of the RRM.

          Coding defects is what most people observe and point their finger at because it personally affects them which gives the impression of beta software. Escaped defects are a function of process and resources, yet many companies weigh the risk/reward ratio and knowingly release software with bugs. Again this is not a function of the RRM for they have the option to pull a feature back if they think it is not ready. Most coders are trying to hack out code as fast as they can without regard to quality and maintainability either from management pressure or personal lack of diligence. These are not functions of RRM.

          When it comes to QA many confuse “testing” with “verification.” Testing infers one is poking at the software. Verification is to take the requirements and design and verify that it performs as expected. A testing mentality opens up a lot of holes for defects to escape. Since bugs tend to hide in the corners, using a testing mentality or impatience to complete the verification process leads to a constant beta status. QA is not a function of RRM.

          The one thing the RRM can have an effect is where it becomes an idol where they say a feature MUST be released on this date. The old axiom “good, fast, cheap–choose two” applies here when artificial restriction are imposed. The RRM itself is not imposing this mentality.

          RRM aligns with the camp of agile development model which is shown to produce better results. I don’t know if Xojo practices agile development.

          • The RRM requires them to release new flashy features every time – THAT is what causes the beta quality issues. Xojo is driven by hype and the hope that „it will be fixed with the next release“, not quality anymore.

            If your interpretation of the model would be correct then Xojo would be of better and better quality. But their staff is too small to release new features every few months. Consequently features are rushed and the quality goes down.

            Simple as that.

          • I second that Markus, and I do agree that this is unfortunately exactly what we are seeing, for years now. The only way out might be that they will offer themselves special functionality via plugins only to ensure that “the core” is working properly. But this is not what we are facing for years. Instead of fixing the core they are not only enhancing it, but they are changing it completely.

            Other languages are not difficult to learn either, so I’m really asking myself why we should stay. We already moved away from Xojo Web and don’t use their “cloud” solution any longer. It was a “hype” when announced but then really NOTHING happened. And the hope I had that a next release might get this fixed, evaporated completely.

  3. Odd but I cant reply to markus
    > The RRM requires them to release new flashy features every time – THAT is what causes the beta quality issues. Xojo is driven by hype and the hope that „it will be fixed with the next release“, not quality anymore.

    Xojo’s implementation of the RRM is what pushes them to put new features out in each release. Thats not inherent with RRM though – just how Xojo uses it.

    I’ve worked in a couple other organization that used RRM. One quite successfully. The other more like Xojo.
    In the first rapid releases could be purely bug fix releases, or new features. They were rarely a mix of both.This was very effective and worked very well.
    In the other, where it was less successful, there was often pressure from marketing to put in new features in every release because they felt unable to get press from bug fix releases. And that often lead to the same results we see at Xojo. Its very hard to plan out big features far enough in advance you can implement them well, cover all kinds of uses cases AND do it on a schedule that first with quarterly releases.

    It would be nice to see Xojo try doing RRM differently and NOT put big new features in every release as the last 13 or so years havent shown that this implementation of RRM is fantastically successful or leading to better & better quality and fewer bugs

    • Norman, word! But I have little hope Xojo will ever rethink their approach again :-(. On top of that, they are releasing the new “features” in environments changing themselves at a very high pace: be it ipadOS, new Android flavors etc., and let’s not even talk about new web frameworks and standards …

    • Markus,

      RRM does not force them to release new flashy features every time! This is a business/strategy function which is related to poor decision making. Because you said, “I predicted at its introduction that Xojo would become a perpetual beta quality product,” means you have dog in the fight which blinds you to the truth because you are defending your own bias. Your reasoning blames the tools and not the ones using the tools. Norman gave examples of poor and successful usage of RRM and Xojo has complete control over what and when to release new features. Strip away the RRM issue and answer the question, what is the root problem for the quality issues?

  4. So if you have one big release with new features followed by bug fix releases to end up with a stable version – which btw is the way things used to be – then that is suddenly sold as “the right way to use the RRM”?

    Are you guys kidding me?

    The RRM from the outset was billed as getting new features to users quicker. If you have enough staff to churn out quality implementations and do proper quality checks then yes, that can work. But Xojo has always been a small company and there was simply no way that they could successfully pull this off.

    And from that it followed that the quality of Xojo would go down.

    Or as Beatrix so succinctly put it: „The usual rush job“.

    So PLEASE stop trying to rewrite history or redefine what RRM is in trying to be right.

  5. … and Brendan: stop trying to shoot the messenger and smear his arguments. That might work in politics (where “sound bites” are all that seems to matter) but it is a very bad discussion tactic when you try to convey information, and says more about you than the one you attack.

  6. I am neither defending or cursing the RRM. I am saying the RRM has not been the cause of failure. The event naming problem in R2 was caused by not listening to the beta testers. API 2.0 had been in development for some time and it wasn’t a rush problem, but a decision making problem! The original navigator was a paradigm shift and was akin to, “if it wasn’t broke, fix it anyways.” The same thing happened there where Geoff didn’t listen to the customers and internal feedback. If they lack staff, that is a financial/strategic decision and the RRM is not responsible for them hiring or firing staff. If they are putting out new major features in order to gain market share, then that is marketing driving the decision process and not an attribute of RRM. If they are rushing development, then they are choosing to do that. When you have huge monolithic releases with long periods between releases, it can also cause rushed development because they may have the fixed date. The RRM actually helps in this area since it can take the pressure off because things can be pushed off to the next release window and thus it gives them more flexibility. The RRM is a valid release strategy, but how you use it determines success or failure. So equating the RRM as a deterministic route to failure ignores the truth of the situation with Xojo.

    Like I mentioned before, I don’t know if they are using agile methodologies. If the they wan’t to improve quality, that is one thing they can do today because agile is really a mindset change on how software is developed.

    • Agreed
      How you use RRM and the other processes around it will influence success or failure

      Like trying to use a hammer to screw in a nail
      Is that a failure of the hammer ? OR a failure to analyze the problem well enough and apply the right processes to come up with “I need a screw driver!” ?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.