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 [quote]row.BooleanColumn()[/quote] that you used in your code
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.
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.
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.
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.
[quote=465227:@Jürg Otter]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.
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.