Porting to API 2.0

As I am porting and existing project to API 2.0, and I don’t want to accept any deprecated code left in the ported project, I get a bit tiresome of the silly changes I have to make.
For what sake: Rs.movefirst becomes Rs.MoveToFirstRow ? And why Rs.EOF becomes Rs.AfterLastRow ?
Many changes seem logical to me, but some are really too far fetched.

2 Likes

Wait until you come to the mids and the date to datetime conversion. Yes, most of the changes are pretty silly.

3 Likes

Yes, it is not easy to make changes…

I had yesterday the reverse problem: I wrote on an M1 (current Xojo) a “Search String into TextArea” Feature (and it worked fine), then (back home), I translated back into the standard API (2015r1) and get a stone in my shoe with IndexOf (I was not able to write this correctly: I still have an error at compile time).
I slept, do some urgent things today and do not had time to get back to the trouble… to try to resolve it once more.

They can extract the Standard API from Xojo (so it produce a smaller dmg) and propose a second Xojo application called Xojo 2022 Classic * (be usable with your license #). So people who still have projects to use with that version can continue and the other people get today a full featured Xojo without the code that will be deprecated… one day.
And their sources (for the current Xojo version) will be lighter.

The transition can be accelerated; people will avoid to overwrite their old projects with a current version when they want to check the project compatibility.

  • Of course, that version is not supported, bug reports are rejected, etc.

Doh ! It’s the morning (in fact the afternoon) ! I slept the whole morning ? Yes, I do that.:star_struck:

EOF is suposed to be just a condition that indicates no more data can be read from a data source. A standard in condding. AfterLastRow is just a !"#% idea making the language verbose and silly, harder to take it seriously :roll_eyes:

I find these changes quite logical. What has End of File (EOF) got to do with a recordset?

Use the IDE to fix these things - Find & Replace All makes short work of these little changes.

1 Like

Be vary careful with string handling as there are some big differences between API 1 and 2 that are not always readily apparent. Think -1 and 0 for some string function return values.

3 Likes

Very true. String.IndexOf is not Instr(String), but the former is more consistent with the language than the later.

2 Likes

I am aware Bob. this is why I don’t use find and replace much but want to look at every single line of code and do intensive testing.