Transitioning to Xojo 2019r2

Off-Topic
#1

It seems that the 2019r2 thread was shutdown as I understand that the thread was going a bit off-topic (hmmm… name of this topic).

Anyway, I would really like to have some place to discuss transitioning earlier release applications to 2019r2. As stated in a discussion with Kem in the other thread, my application does not operate correctly under 2019r2. It’s difficult to tell exactly where the problem lies but it appears to be a problem in deleting an existing file. I can’t be certain but ASSUME there are other problems.

When I check the application I get thousands of messages about deprecated items and really am lost about what a logical approach might be. Changing Dim to Var, changing MsgBox to MessageBox, changing references to ListBox objects, etc. Alternatively, maybe take a module at a time and fix all items in that module, then go to the next.

My desktop license is valid through July 2023 and I sure would like to be able to take advantage of new releases. However, I will have to stick with Xojo 2019r1.1 until I can workout all the issues with my application including months worth of retro testing.

I understand that Xojo may not want to hear a lot of bashing of their new product on their own forum, but would they want it transitioned to somewhere outside of Xojo?

How about a thread where we can discuss transition approaches, issues, cautions, etc ?

Ron Bower

#2

I spent quite a bit of time last week to get rid of a lot of the deprecation warnings.

I started with replacing the obvious stuff like TextSize to FontSize. I carefully tried to replace the event names. Had some problems there when there were parent classes. Then I tried to do the simple stuff like left(string, number) to string.left(number). dim isn’t deprecated, by the way. Now I’m trying to do the more complex stuff like mid to middle and instr to indexof.

But I don’t stick to some method because the work is utterly boring. Mindnumbingly utterly soulsucking. I compile often and try to run the app when I make a more delicate change like for mid. I screwed up a couple of times already. But that’s why I have the SVN.

2700 deprecation warnings are remaining from over 10000. And I think that Xojo forgot to deprecate stuff like join, replace and replaceall.

#3

most of the warnings are duplicates, start with the simplest first.
if something behave odd put it in a test project.
i updated a project to api2 but unfortunately i did not made notes. :frowning:

#5

I had 4800 deprecations; after some work it’s now down to less than 400.

I made a copy and am working with that. Global replace works fine for things like dim -> Var and .field -> .Column

But do a search first and scan the results to check you won’t be changing something you didn’t mean to. Also do analyse project at each step.

#6

There is this this Blog Post from Xojo: Your Path Forward with API 2.0
Sure, that answers some questions and clears up misconceptions some users might have. It’s a nice and somehow expected marketing move. But let’s look at the “real world”.

While I don’t think that I have misconceptions, I still haven’t found a way to use 2019r2 in a productive way to continue using a hughe project which currently obviously is API 1, and needs to be able to be built with <2019r2 for some time.

Let’s assume, we take the Blog’s approach “Not Upgrading”. Well, a ton of Deprecations which kind of aren’t - because one wants to continue using API 1 for a while. And the approach “Upgrade Incrementally”. Well - where to start…? It’s all mixed, not sorted in Deprecation-Types/Groups. There are no migration helpers available which would quickly and easily replace “safe renamings” (which don’t have a different code execution behavior).
So I understand that one is lost. And 2019r2 doesn’t offer much to help with that.

For that “Transitioning time” there are a couple of Feedback/Feature requests that would help a lot: <https://xojo.com/issue/56856>, <https://xojo.com/issue/57885>, <https://xojo.com/issue/57888>.

Which is also kind of your situation:

Depending on the project/size/resources, it will take months to migrate an existing project. During that time, productive build will be done with <2019r2. But testing/development also needs to use 2019r2+.
And for that situation we don’t really have a good solution. And hardly any “answers” from Xojo. While it kind of “would work”, it’s currently simply a pain to do so, and (from our point of view) quite unproductive.

There are many threads/questions about that already… but no reaction of Xojo until now.

What we are doing (our transition approach):

  • Develop and Save the project with 2018r4 (and do productive builds with 2018r4, 2019r1.1)
  • occasionally do Beta-builds with 2019r2+. do needed code modifications (e.g. using conditional compiling) in 2018r4. 2019r2+ is just to “open and debug-run / beta-build”.
  • there is only API 1 (API 2 just maybe for a couple of bugfixes when building using 2019r2+, using conditional compilation)
  • once there will be a time where beta-builds look good for all our BuildTargets with 2019r2+
  • only then will the project be saved in 2019r2+ (and: no more going back)
  • by then we hope to have a 2020rx, which will be much more useable to transition existing API 1 code… and much of the possible bugs with that “risky release 2019r2” have been uncovered and ironed out.
  • if Xojo is still of interest for our future, code might be transitioned piece by piece. but really: why…? API 1 will be around forever (thinking in a software lifespan). more likely is that maybe just new code/projects are going to use API 2.

So from my point of view: Is transition really necessary? A good question, depending on what you’re up to with your project. It may very well not make much sense to do so. And if you’re trying to do that with a hughe project, then 2019r2 is not quite up to the job. Again: just my point of view (looking at our projects). There is still the chance that Xojo listens to what their professional users would like to have (see feature requests above, and quite some more in Feedback). They could support transitioning much better. And by doing that, many more would be willing to start using API 2.

For now, we just have a “first shot” of API 2. That’s looking quite nice. But there is a lot not available that would help to get existing projects transitioned to that future. And again: especially the month-long time where both API 1/2 need to be used within the same code base. For brand new projects, all is looking quite nice. Not so for other situations. Xojo can deliver more - if only they want to.

#7

communities outside the forums exist on IRC, facebook discord and other messaging platforms
https://discord.gg/nNye8e

#8

for much people a simple converter build by xojo devs would help a lot.
because the analyse list everything with the replace suggestion
it should be possible to mark some messages and replace all this source code with a click.

#9

you cant do that correcly since some deprecations change from using a 1 based index to a zero based index and a single click replace would break tons of code where this was the case

#10

not all but most of them, example messagebox or new date or ubound and lastindex .Text is .Value …

#11

I wouldnt have the IDE rewrite code
Far to easy to get it REALLY wrong

#12

[quote=461031:@Norman Palardy]I wouldnt have the IDE rewrite code
Far to easy to get it REALLY wrong[/quote]
it can be a preview “from” “to” where you only hit replace.
and if something break do not save it.

#13

to do it right the IDE has to

  • read your line of code
    = parse it ALL apart 100% correctly (which in itself means the IDE needs a FULL parser for the entire Xojo grammar which it doesnt have)
  • replace the deprecated portion and reassemble all the parameters again

it seems trivial but having been the IDE engineer for more than a decade I can tell you its a lot more difficult than search and replace

#14

Would be nice if Xojo could do what Xcode does.
“Xyz has been replaced with ABC, do you want to change it?” … click, next

and even if the structure of the line has changed, Xcode does that to.
if would change

x=Left(s,1)
to 
x=s.left(1)

for example. it still took time, but it was just checking each msg and clicking confirm

#15

the change from 1 based to 0 based causes a need to parse the line and then rewrite the params as well :frowning:

#16

And there is pre code, and post code, relative to such code changed, math based code, undetectable and they are just doing unchanged math, and now all wrong, doing index math wrong, and maybe storing things wrongly too.

#17

the tool can’t be a human, something can be replaced easy other things not.
most of the conversion from api 1 to 2 was copy / paste.

#18

I wish
Wanna take care of 20,000 + deprecations for me ? :stuck_out_tongue:

#19

[quote=461064:@Norman Palardy]I wish
Wanna take care of 20,000 + deprecations for me ? :P[/quote]
what is the number of distinct(deprecations) ?

#20

never mind markus

There are a handful that are simple (array ubound , and array append)
a lot cant be that simple lke swapping s.mid for s.middle since the parameters are different and if you do just the search & destroy work you have a LOT of off by one errors now
And there are a lot more of those kind than there are the simple ones in this case and each one needs to be examined and corrected

And then I still have to fix the hundreds of compile errors that the event renaming caused
And that I cannot do reliably in 2019r2 - see https://www.great-white-software.com/blog/2019/10/09/xojo-2019r2-api-2-0/

#21

If you work in Xojo 2019 r2 you have to be careful not losing code. Especially when autocomplete does not work or stop working, be extremely careful. Save your open project under another name and do regular incremental saves adding a unique number or your date or time after your filename.

After autocomplete stopped working while I was in the Opening event and created private property, I lost all code in the opening event. Nevertheless, I think the API 2 move is worth the efforts.

Chris