2.1 released

  1. ‹ Older
  2. 2 weeks ago

    Doesnt an earlier build have the coding method you want to switch back to?

    My code has been changing, probably the latest version before 2.0 is not up to date, so I should check every methods and line where DatabaseRow is involved either way.

    Before making a such change Xojo team should have found a better solution.

  3. Greg O

    Nov 28 Xojo Inc scout.galaxy.barn

    @Enric H My code has been changing, probably the latest version before 2.0 is not up to date, so I should check every methods and line where DatabaseRow is involved either way.

    Before making a such change Xojo team should have found a better solution.

    Enric, you’re making the assumption that you must upgrade your code to use RowSet. That’s just not the case.

  4. Greg, with 2.1 if I do not upgrade the code it won't compile... or you are suggesting to keep the 2.0?

    -image-

  5. Dave S

    Nov 28 San Diego, California USA

    No, he is suggesting to forget that R2 ever existed, and follow the canons of r2.1 as if IT were the successor to R1.1

  6. Alberto D

    Nov 28 Pre-Release Testers, Xojo Pro

    You can change:

    Var row As New DatabaseRow

    to

    Var row As New DatabaseRecord

    and it should work, no?

  7. Tobias B

    Nov 28 Pre-Release Testers, Xojo Pro Bern, Switzerland
    Edited 2 weeks ago

    @Greg OLone Enric, you’re making the assumption that you must upgrade your code to use RowSet. That’s just not the case.

    To explain that further: if you keep DatabaseRecord instead of DatabaseRow and RecordSet instead of RowSet everything will be as it was before including the accessor functions like

    row.BooleanColumn()

    that you used in your code

  8. Tobias, reverting to DatabaseRecord (This item was deprecated in version 2019r2. Please use DatabaseRow as a replacement) has its consequences, is perhaps less work that changing all code lines, but I keep using obsolete code, until …?
    Release 2.0 was a mistake but now I'm inside it and it's complicated to go back.

  9. Dave S

    Nov 28 San Diego, California USA

    FORGET ABOUT R2.0 either go back to R1.1 or move to R2.1
    most of the changes in R2.0 were a drastic mistake (which it took weeks to convince Xojo of this)
    as such many were removed for R2.1. so there is syntax in R2.0 that will not be supported again
    So it is best to bite the bullet now, before you are too invested in this tragedy.

  10. Thanks Dave, is exactly what I realize I should do, now that I left the anger and I'm accepting the fact.

  11. Tobias B

    Nov 28 Pre-Release Testers, Xojo Pro Bern, Switzerland

    It's important not to confuse the release of Xojo 2019r2.0 with API 2.0. In r2.1 some details of API 2.0 that were in r2.0 have been reverted/changed and thus r2.0 was retracted. If you are coming from 2019r1.1 (supports API 1.0) to 2019r2.1 (supports API 2.0 and API 1.0) you can switch to the new API or wait with it. API 1.0 was deprecated but it was stated that this does rather mean "deemphased" and it will be supported for quite some time still. In 2019r2.1 the deprecation warning was even disabled by default. If you don't use "save-as" on an project started earlier, API 1 will still be shown in autocomplete.

  12. I already save-as all current projects, and worked in them so, I must be patient, revert what is necessary and accept r2.1 is the version to follow.

  13. Karen A

    Nov 28 Pre-Release Testers
    Edited 2 weeks ago

    @Tobias B If you don't use "save-as" on an project started earlier, API 1 will still be shown in autocomplete.

    That unfortunately is not a good solution because it is too easy to do a "Save As" and forget that it loses backward compatibility even if you don't use API 2...

    I use "Save As" often to fork code to try things ... which means without being able to do a "Save As" as an API 1.0 project I may need to stay at 2019R1.1 for coding.

    At least for projects started with with API 1, the "Save As" dialog should have an option to keep the project in API 1 format.

    I am afraid they won't do that however... If not I think it's possible to create an IDE script and app which together will allow a save as that keeps the project usable in older IDEs. Maybe i will try that... If I can't get that to work I won't consider renewing unless/until I absolutely have to.

    -Karen

  14. Jürg O

    Nov 28 Pre-Release Testers, Xojo Pro
    Edited 2 weeks ago

    @Karen A That unfortunately is not a good solution because it is too easy to do a "Save As" and forget that it loses backward compatibility even if you don't use API 2...

    We've tried to tell Xojo so in PreRelease...

    @Karen A At least for projects started with with API 1, the "Save As" dialog should have an option to keep the project in API 1 format.

    That's exactly what has been suggested... Feedback Case #58102 (sorry, title is a bit misleading... the content is what's important)

  15. Karen A

    Nov 28 Pre-Release Testers

    @Jürg O We've tried to tell Xojo so in PreRelease...

    I know... i was there and said as much back then...

    If I do create a solution using an IDE script and an app, do you think it would be of general interest?

    I don't know IDE scripting very well but the docs, Actually I think to have a UI for the "Save As", I would need an IDE script which would call a console App which would then launch an GUI app to get the new name/location, which sends that back to the console app, which then returns it to the IDE script, which then closes the original project and opens the new one...

    Seems unnecessarily complex , but logically should work and I can't see a simpler way right now.

    -karen

  16. Ivan T

    Nov 28 Pre-Release Testers

    @Enric H I already save-as all current projects, and worked in them so, I must be patient, revert what is necessary and accept r2.1 is the version to follow.

    never ever use a Xojo feature as soon as it is released! In general it takes a couple releases to work ok.

  17. Emile S

    Nov 28 Europe (France, Strasbourg)

    a. staying with API 1 ?
    Every now and then, I made a copy in the Finder, into a backup projects folder of the current state and I append the date to it for future reference(s).
    This seems, IMHO, a good idea with API 2.

    b. Changing Xojo to a new version ?
    IMHO and if you can do that (there is n workaround you are waiting for in a new version): always stay with the actual Xojo version until the project is done. You will upgrade before you start another project. Two “good reasons” (also IMHO):
    a. this keeps you away of bad things that can appears sometimes after a new version is released (we alread saw that in the past; this is not a rant, just something that can happens, sometimes, rarely).
    b. even if the new release does not have troubles, you may reach slowdown because of changes (even good changes): we most of the time have to ‘waste’ time to adapt to the new version and if you have a project running (/ near the release time), you cannot slow down the development.

    As usual, this is my opinion, do what you want, what you know is better for you.

    Regards.

  18. I have had the bad habit to update very soon and look at the news and use them, now I'll be more patient... for example Catalina is there and I have no intention to change for now.

  19. Emile S

    Nov 28 Europe (France, Strasbourg)

    Enric: I understand, but with ellapsed years (I’m in my 60s), I became prudent (I am still curious for everything, but I refrain myself on some domains). ;)

  20. @Emile S Enric: I understand, but with ellapsed years (I’m in my 60s), I became prudent (I am still curious for everything, but I refrain myself on some domains). ;)

    I'm in my 70s and I'm still a crazy one

  21. Emile S

    Nov 28 Europe (France, Strasbourg)

    ;) !

or Sign Up to reply!