2.1 released

General
1

Updating to 2.1 and now begin again… and worse when copying and pasting Xojo crashed (and not always)
Now change all IN/OUT code again…

where

row.BooleanColumn("Advance") = u.Advance

now is

row.Column("Advance").BooleanValue = u.Advance

and so on

hundread os code lines to change…

[code]Var row As New DatabaseRow

row.BooleanColumn(“Advance”) = u.Advance
row.IntegerColumn(“atack”) = u.Atack
row.IntegerColumn(“CounterCol”) = u.CounterCol
row.BooleanColumn(“Exchange”) = u.Exchange
row.BooleanColumn(“Exited”) = u.Exited
row.IntegerColumn(“ID”) = u.ID
row.BooleanColumn(“IsAttacking”) = u.isAttacking
row.BooleanColumn(“IsDead”) = u.isDead
row.BooleanColumn(“IsTarget”) = u.isTarget
row.IntegerColumn(“Left”) = u.Left
row.BooleanColumn(“Moved”) = u.Moved
row.IntegerColumn(“Movement”) = u.Movement
row.BooleanColumn(“MustAttack”) = u.MustAttack
row.BooleanColumn(“MustBeAttacked”) = u.MustBeAttacked
row.Column(“name”) = u.name
row.Column(“Nation”) = u.Nation
row.IntegerColumn(“offsetLeft”) = u.offsetLeft
row.IntegerColumn(“offsetTop”) = u.offsetTop
row.Column(“OldPlace”) = u.OldPlace
row.Column(“Place”) = u.Place
row.Column(“Reinforcement”) = u.Reinforcement
row.BooleanColumn(“Selected”) = u.Selected
row.IntegerColumn(“Side”) = u.Side
row.Column(“tipus”) = u.tipus
row.IntegerColumn(“Top”) = u.Top[/code]
etc.etc.

2

Is this your only copy of the code?

Assuming not …Doesnt an earlier build have the coding method you want to switch back to?
Arbed editor can identify the differences and update/revert with a mouseclick.

3

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.

4

[quote=465160:@Enric Herrera]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.[/quote]
Enric, you’re making the assumption that you must upgrade your code to use RowSet. That’s just not the case.

5

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

6

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

7

You can change:

Var row As New DatabaseRow

to

Var row As New DatabaseRecord

and it should work, no?

8

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

9

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.

10

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.

11

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

12

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.

13

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.

14

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

15

We’ve tried to tell Xojo so in PreRelease…

That’s exactly what has been suggested… <https://xojo.com/issue/58102> (sorry, title is a bit misleading… the content is what’s important)

16

[quote=465227:@Jürg Otter]We’ve tried to tell Xojo so in PreRelease…

[/quote]
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

17

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

18

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.

19

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.

20

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). :wink: