Transitioning to Xojo 2019r2

  1. ‹ Older
  2. 4 months ago

    Mark C

    Oct 30 Pre-Release Testers, Xojo Pro Spain 03170

    all this is so sad, makes me very fed up.
    I wonder what any new users might think when seeing the unrest of the long time users to the current update.

    any good news about 19r2, and I hear there some good updates, has been lost in the far larger negative comments.
    I wonder how many other users like me, who are part of the beta program, have stopped testing any more.

    the one glaringly unrepresented people in this are the 'new users', none of them have had anything to add to the assumption that the original (I am not going to call them old) events would make them run to the arms of some other language which is likely to have some equally 'confusing' naming convention.

    there are new users on the forum that I have seen asking questions but none have suggested they are here due to the ease of understanding an event name.

    It may well be that the hope at Xojo towers is that people will do as Geoff suggests and 'convert code when it makes sense', it appears that the majority of users who are posting on the subject simply think that it makes no sense to do anything of the sort.

    For me the most unbelievable change, beyond the event name change, is the serial port.
    I have no comprehension as to anything that might be benefitted by this, thankfully I can completely ignore that change and likely stick with the original serial control forever, or until I change compiler, but that also means any small help I may be able to offer new users, gained with many years of experience with the original serial control, will be lost to them, as will all the other help available from other far more experienced developers.

    There are many ways to have avoided this, and still are, without anyone needing to claim a victory or lose face.
    ts a simple choice for most of us when it comes to renew time and that I suspect this will be the final arbiter as to the fate of the Xojo.

  3. Joseph E

    Oct 30 Pre-Release Testers CA
    Edited 4 months ago

    @Geoff P Having intuitive and consistent APIs across the board makes Xojo easier to learn and use which helps bring more users into the community.

    Many new users are beginners and don't really have any concept of APIs, Frameworks and such. They're just trying to develop their first program, connect a database, show some records, develop a helpful program for work. The last thing they are doing is critiquing your naming consistency in the APIs.

    Window.show, window.open, window.opening; no one new will care, they'll look at the manual and figure it out. Those experienced programmers won't care either, they'll pick the tool that provides the most productivity to get the job done. No one is going to quit Xojo if it works for them due to inconsistencies in the API. Many, many long term projects evolve and as such inconsistencies creep in, most rational people can deal with that.

    I'm sorry but it seems you have alienated a significant portion of your long-term base. These are the very people that help new users pick up and run with Xojo via this helpful forum.

  4. Jürg O

    Oct 31 Pre-Release Testers, Xojo Pro
    Edited 4 months ago

    @Geoff P What you DO NOT need to do, is convert code for no good reason.

    You probably know that I know that very well. And I won't do that. So let's put this in words of the "receiver". But first: get an idea of your receiver's situation:
    We have commercial products. They suffer from serious lacks and issues. To name just a few: Windows (Software/Hardware)Rendering faults and HiDPI issues, macOS looking outdated (no native-looking 'Sidebar' possible) and flattery (can't use monospacedDigitSystemFont), Linux with occasional printing crashes. Want want and need to fix that since yesterday. Our customers are asking and demanding. That's what we need "now". Same/similar story for many others of your existing long term users.

    So what's in store for us in 2019r2? We've waited many months for it. We get to use at most a handful of workarounds (involving performance penality by instantiation and using new API 2 objects/classes). As you have very well said: we DO NOT need to convert code. Or: we don't need API 2. It doesn't make our products better. It doesn't help to support our customer's needs "now".
    Xojo could have provided solutions to current needs within weeks. Instead we've waited (not to say: wasted) months for not much of what we need "now".

    And what do we get in addition? You're announcing even more "exciting stuff" (Android, Web 2, ...). What does this make us think? Well: "What we need since yesterday will be put off even longer. Maybe never coming."

    @Geoff P: Do us a favor and put yourself in our situation. Look at Xojo from the "outside". What would you need and expect? What do you get (instead)? What course should be taken for the sake of both parties?
    Then go back to your position and give us an answer. And deliver. Sooner rather than later.

    I understand and appreciate the "ideal of API 2". It just doesn't help me with what I need to do now or with what I would like to have done for a long time already. For us and our customers/products. 2019r2 has neglected your long term user's current/urgent needs. And unfortunately for you, driven away quite some of them already.

    And what has been delivered in 2019r2 comes in a way that's not convenient and even less productive to continue working and improving our existing commercial products and code bases. Again: for that we don't need API 2 right now. It's nice to have it for the long term, but we feel neglected with our needs that we have expessed for a long time already. Do you understand why some of us are feeling tired ?

  5. Jürg O

    Oct 31 Pre-Release Testers, Xojo Pro

    @Geoff P For some, converting their entire project makes sense so they do it but that's not a requirement at all.

    For those that want to do convert their entire project (it seems a lot of your customers want that - we don't), but also for those that don't want/need to do so immediately or just want to upgrade incrementally/eventually...

    2019r2 and API 2 is really nice for a "fresh start". But it doesn't quite allow to use it along with existing code bases in a productive way. It could/should be way more useful. Read again here .

    Note: This is not about API 2 (that's all nice and good). It's about maintaining and improving existing projects of your professional and long term users. Also from that point of view (intending/wanting to adapt API 2, incrementally or full) 2019r2 has been neglecting them, is missing a lot of functionality allowing to transition in a productive way. Some helpful ideas have been mentioned many times - even before 2019r2 hit the public.

    Having said that, too - I still think the previous post is even more important to consider.

  6. Geoff P

    Oct 31 Xojo Inc Austin, Texas

    @Dave S Then why does 80% of API2.0 even exist?

    Because the new APIs are more consistent and intuitive. Going forward, users will have a better experience overall.

  7. Geoff P

    Oct 31 Xojo Inc Austin, Texas

    @Jürg O For those that want to do convert their entire project (it seems a lot of your customers want that - we don't), but also for those that don't want/need to do so immediately or just want to upgrade incrementally/eventually...

    2019r2 and API 2 is really nice for a "fresh start". But it doesn't quite allow to use it along with existing code bases in a productive way. It could/should be way more useful. Read again here .

    Note: This is not about API 2 (that's all nice and good). It's about maintaining and improving existing projects of your professional and long term users. Also from that point of view (intending/wanting to adapt API 2, incrementally or full) 2019r2 has been neglecting them, is missing a lot of functionality allowing to transition in a productive way. Some helpful ideas have been mentioned many times - even before 2019r2 hit the public.

    Having said that, too - I still think the previous post is even more important to consider.

    API 2 should not be causing you any issues. You can ignore it entirely for existing projects if you'd like. You don't have to use the new events if you want to stay backwards compatible. We went to great lengths to make it as painless a transition as we could while still allowing users to incrementally transition.

  8. Louis D

    Oct 31 Pre-Release Testers, Xojo Pro QC, Canada

    API 2 should not be causing you any issues. You can ignore it entirely for existing projects if you'd like.

    I think that a demonstration of that statement is necessary to show that event renaming does not cause issues with third party classes that may be used by many customers in programs using exclusively API 1 or exclusively API 2.

    Saying something 1000 times does not make it true. But a real life demonstration ends all arguments. You have a vested interest in ending thse bitter arguments.

  9. Jürg O

    Oct 31 Pre-Release Testers, Xojo Pro

    @Geoff P API 2 should not be causing you any issues. You can ignore it entirely for existing projects if you'd like. You don't have to use the new events if you want to stay backwards compatible.

    You've written that repeatedly. Sure - that's so obvious and easy.
    But it has nothing to do with the quoted situation (users that for some reason want to migrate partially/entirely).

    @Geoff P We went to great lengths to make it as painless a transition as we could while still allowing users to incrementally transition.

    Ah, I don't consider an unsorted list of > 10000 deprecations a way to start a "painless transition". And that's just one pick out of many issues mentioned in this thread.
    And I'm thinking also of other "less-producitivy" issues introduced, such as that simply loading a big project now takes an additional 3-5 Minutes just for "Preparing Workspace" (really - what's so enormous processing-power-requiring going on in such a long processing time just to load?). Again it's just one pick out of many reported issues early enough - even in PreRelease.

    And there are other things many of us care about / need now more than what the future will bring. No word on that. That still feels to be ignored by Xojo.

  10. Norman P

    Oct 31 Pre-Release Testers, Xojo Pro outside listening to the crick...

    @Jürg O are you still seeing a huge number of extraneous changes in text files when edited in 2019r2 ?

  11. Ron B

    Oct 31 Pre-Release Testers
    Edited 4 months ago

    I need some help/advice, please.

    As stated previously, my Application which runs well under 2019r1.1 does not run properly under 2019r2. I will readily admit that it is most likely a coding flaw that has let me slide for a long time, but it is causing major problems just trying to get one thing to work properly. Here's the basic situation...

    I have a SQLiteDatabase that holds information that the user downloads from our web page. The processing is fairly simple - download the data, then initialize a SQLiteDatabase, then load the database with the downloaded data.

    In the processing, the system checks to see if the database file exists and if so executes a db_file.delete before continuing. Here's a snippet:

    Data_DB = New SQLiteDatabase
    data_db_file = App_Parent.Child( "Data_DB.sql" )
    If ( data_db_file.exists ) Then
      data_db_file.Delete()
    End If
    Data_DB.DatabaseFile = data_db_file
    If ( NOT Data_DB.CreateDatabaseFile() ) Then
      MsgBox( "Database File Creation Error:  " + Data_DB.ErrorMessage )
    Else
      .......  

    This code has worked for many years under all previous releases. However, it does not execute properly under 2019r2. It does not delete the DB file and does not raise an exception. It does, however, set LastErrorCode for the DB File to 104 - file in use. The result is that the new data downloaded is just added to the SQLiteDatabase.

    I have tried to add a Data_DB.Close before the Delete, but that also does not allow the file to be deleted.

    What do I need to do to be able to delete the DB File so i can get a fresh start ?

    There is similar code in several other places - all worked in 2019r1.1 but not in 2019r2.

    Added Note: This code sets LastErrorCode to 101 in 2019r1.1 - where can i find a list of error codes and their meaning?

    It seems that using 2019r1.1 to lookup documentation (such as right click on an item) it takes you to the 2019r2 documentation pages.

    Please help !

    Ron Bower

  12. Emile S

    Oct 31 Europe (France, Strasbourg)

    @Jürg O list of > 10000 deprecations

    and all of these lines appears in a very small height part of the IDE window…

    Or must all API2 users also have to go to GIT and clones (if the edition can be done there: I never fired this kind of software, so I do not know *) ?

    Where the API2 is <better/consistent/whatever> ?
    Example taken from 19r2.1:
    FolderItem.CreateAsFolder becomes FolderItem.CreateFolder ?

    Nota: of course, the removed As does not add or remove anything (nor in typing [autocomplete is here to help] nor for understanding).
    This is a bad example because I love this change and it does not hurt m y memory (for unknow reasons).

    *There is always a good reason why things are done AND things are not done: in that case, if “nobody” use that small part of the IDE window, of course, they do not have any problem.
    A good proof is the fact people do not stop to complain because of the removal of the graphics removal (no more able to Paint elsewhere than in the Paint Event). They never analyze the project nor read the results (arrow keys are inactive and the visible area is very small).

  13. Jürg O

    Oct 31 Pre-Release Testers, Xojo Pro

    @Norman P @Jürg O are you still seeing a huge number of extraneous changes in text files when edited in 2019r2 ?

    Not as much as during PreRelease. The usual noise (quotes, values/format, new properties).
    But... don't even try to add or duplicate a Label in Layout and save. It's Text/Value will be saved in "Value" - and be "undefined" when opening in earlier version. So what should I say? As long as you don't touch any layout, it seems "doable" to save in 2019r2 and open in previous version. Because then you can just revert the whole Block in #tag Window.

  14. Emile S

    Oct 31 Europe (France, Strasbourg)

    Were you able to always open an API2 project with < 2019r2 IDE application ?
    I do not think so.

  15. Norman P

    Oct 31 Pre-Release Testers, Xojo Pro outside listening to the crick...

    @Emile S A good proof is the fact people do not stop to complain because of the removal of the graphics removal (no more able to Paint elsewhere than in the Paint Event).

    There were TONS of complaints, bug reports and feature requests to restore that ability

    The OLD APIS, particularly on macOS using the older Carbon UI frameworks, permitted this
    Newer OS API's didn't
    The OS forced this change so there wasnt a lot Xojo could do to "fix" it

  16. Norman P

    Oct 31 Pre-Release Testers, Xojo Pro outside listening to the crick...

    @Jürg O Not as much as during PreRelease. The usual noise (quotes, values/format, new properties).
    But... don't even try to add or duplicate a Label in Layout and save. It's Text/Value will be saved in "Value" - and be "undefined" when opening in earlier version. So what should I say? As long as you don't touch any layout, it seems "doable" to save in 2019r2 and open in previous version. Because then you can just revert the whole Block in #tag Window.

    Yeah I've seen about the same where editing in 2019r2 basically breaks being able to use it in an old version because of the property renames as well

    :(

  17. Dave S

    Oct 31 San Diego, California USA

    @Geoff P Because the new APIs are more consistent and intuitive. Going forward, users will have a better experience overall.

    That is the whole point that almost your entire client base is trying to make... NO THEY ARE NOT.

  18. Jürg O

    Oct 31 Pre-Release Testers, Xojo Pro
    Edited 4 months ago

    @Norman P Yeah I've seen about the same where editing in 2019r2 basically breaks being able to use it in an old version because of the property renames as well

    Honestly: I haven't tried to save in 2019r2 much... but now that you have made me try this I immediately stumbled upon a bug: Feedback Case #58093
    Since this Thread is not about "Bugs", but about "Transitioning" I just will say that: "It's not a good idea for Transitioning to save a .xojo_project in 2019r2 if you still need to open/build it in 2019r1.1 for a while".
    Which again doesn't quite help 'Transitioning to 2019r2' (with/without API 2)... :(

  19. Norman P

    Oct 31 Pre-Release Testers, Xojo Pro outside listening to the crick...

    @Jürg O Honestly: I haven't tried to save in 2019r2 much... but now that you have made me try this

    sorry ... I had already experienced this on a small trial and should have reported it myself

  20. Beatrix W

    Oct 31 Pre-Release Testers, Third Party Store Europe (Germany)
    Edited 4 months ago

    Like this: Feedback Case #57120

  21. Thom M

    Oct 31 Pre-Release Testers Greater Hartford Area, CT

    @Geoff P API 2 should not be causing you any issues. You can ignore it entirely for existing projects if you'd like. You don't have to use the new events if you want to stay backwards compatible. We went to great lengths to make it as painless a transition as we could while still allowing users to incrementally transition.

    Unfortunately, this isn't really true. Simply using a project in r2 causes it to rewrite properties in the version control format. I have a project I work on that (for now) must remain compatible with very old operating systems. So we have one branch for the legacy 2015r2.4 code, and another branch for the modern 2019r2 code. The branches are not intended to be feature complete, but if there is something we want in both, we make the change in the legacy branch and merge into the modern branch. The property rewrites have to be ignored, otherwise merges will be... disastrous. So if I make one change in the modern branch, Xojo rewrites 92 files worth of properties that I have to dig through and NOT check in, all while making sure I don't miss any actual code. This has nothing to do with wether or not I'm using API 2 features. Since properties got renamed, so did the file format.

  22. Newer ›

or Sign Up to reply!