Transitioning to Xojo 2019r2

  1. 5 months ago

    Ron B

    Oct 30 Pre-Release Testers

    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. Beatrix W

    Oct 30 Pre-Release Testers, Third Party Store Europe (Germany)
    Edited 5 months ago

    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. Markus R

    Oct 30 Pre-Release Testers, Xojo Pro Europe / Germany / Lower Saxon...
    Edited 5 months ago

    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. :(

  4. Tim S

    Oct 30 Pre-Release Testers Canterbury, UK

    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.

  5. Jürg O

    Oct 30 Pre-Release Testers, Xojo Pro
    Edited 5 months ago

    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.

    @Ron B I get thousands of messages about deprecated items and really am lost

    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: Feedback Case #56856, Feedback Case #57885, Feedback Case #57888.

    Which is also kind of your situation:

    @Ron B 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.

    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.

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

    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.

  6. Norman P

    Oct 30 Pre-Release Testers, Xojo Pro outside avoiding snowflake
    Edited 5 months ago

    @Ron B 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?

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

  7. Markus R

    Oct 30 Pre-Release Testers, Xojo Pro Europe / Germany / Lower Saxon...

    @Tim S Global replace works fine

    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.

  8. Norman P

    Oct 30 Pre-Release Testers, Xojo Pro outside avoiding snowflake

    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

  9. Markus R

    Oct 30 Pre-Release Testers, Xojo Pro Europe / Germany / Lower Saxon...

    @Norman P 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

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

  10. Norman P

    Oct 30 Pre-Release Testers, Xojo Pro outside avoiding snowflake

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

  11. Markus R

    Oct 30 Pre-Release Testers, Xojo Pro Europe / Germany / Lower Saxon...

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

    it can be a preview "from" "to" where you only hit replace.
    and if something break do not save it.

  12. Norman P

    Oct 30 Pre-Release Testers, Xojo Pro outside avoiding snowflake

    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

  13. Dave S

    Oct 30 San Diego, California USA

    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

  14. Norman P

    Oct 30 Pre-Release Testers, Xojo Pro outside avoiding snowflake

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

  15. Rick A

    Oct 30 Pre-Release Testers (Brazil. UTC-3:00)

    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.

  16. Markus R

    Oct 30 Pre-Release Testers, Xojo Pro Europe / Germany / Lower Saxon...

    @Norman P the change from 1 based to 0 based causes a need to parse the line and then rewrite the params as well :(

    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.

  17. Norman P

    Oct 30 Pre-Release Testers, Xojo Pro outside avoiding snowflake

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

  18. Markus R

    Oct 30 Pre-Release Testers, Xojo Pro Europe / Germany / Lower Saxon...

    @Norman P I wish
    Wanna take care of 20,000 + deprecations for me ? :P

    what is the number of distinct(deprecations) ?

  19. Norman P

    Oct 30 Pre-Release Testers, Xojo Pro outside avoiding snowflake

    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/

  20. Newer ›

or Sign Up to reply!