Controls not supported

Hi… I have a large long-term commercial app, which I primarily work with in one version of Xojo, but occasionally I use another version to locate a specific type of exception. Occasionally I get this:

Would it be too much to ask Xojo (in a future release) to actually identify what the objects are, or at least the offending classes ? The project is large, really large, and it’s like looking for a needle in a haystack.

Whats even more weird is that the project saves, builds and runs fine regardless - and whatever causes this is not actually deleted when it is saved - which suggests whatever causes this was not used.

Which version was originally used to compile the app ?

Which version gives you that error ?

Then when do you get this error message ?

Ok… I’ll be specific.

  1. Open the project in 2022 R4, then save. No error detected, project builds but crashes the IDE and MacOS gives a lengthy debug message which is less than helpful.

  2. Launch Xojo 2021 R3.1 Open the project saved from R4, it reports the error. Project builds and runs fine, no issues.

I primarily use 2021 R3.1 to do stuff as it builds successfully and the built app works stably - no issue from users.

I use R4 or 4.1 to find specific exceptions that 3.1 wont find, but the IDE can’t run the app it crashes the IDE.

NB project is about 50MB. not trivial.

Just so we’re all n the same page, when you say “crashes the IDE,” are you:

A. Getting an error saying that your project can’t be compiled
B. Getting an exception dialog in the IDE which then takes you to Issues to report a bug
C. You see the IDE just disappear from your screen with no error message at all?

I ask because different users have different definitions of “crash”.

In R4… I can analyse the project, save the project, select RUN, and KABLOOIE the IDE is gone, back to MacOS Finder. (system is Ventura 13.1) MacOS then displays a crash log, and reports the Xojo crashed, with the usual dialog to launch it again or report bug to Apple.

Aah what the hell. I’ll start a new project using R4, and copy and paste class one at a time from the old project, stub out the bits that wont run without the rest, build and test one at a time till I find the mongrel that causes the crash. February is quiet and If I find this by Easter I’ll be happy - I have had worse.

And what is in the crash log? How do you expect the older version of Xojo to cope with the information from the newer version?

1 Like

You could look through release notes for versions between your R3.1 and R4 (actually R4.1) and see which items actually had their support removed as opposed to “mere” deprecations.

Beatrix I appreciate that, and have been puzzled all along that R3.1 still opened the project, runs and builds OK - but when re-saving as a new project (using R3.1) this doesn’t clear the issue, it is copied over to the newly saved version.

I’ve had to rebuild this thing from the ground up a few times before over the past 10 years to refactor it. Looks like I have to do it again, just not something I’m looking forward to.

And this was certainly done with good reasons.

But Beatrix is right; an old version (22r3.1) does know nothing to something added in a future version (22r4).

I use R4 or 4.1 to find specific exceptions that 3.1 wont find, but the IDE can’t run the app it crashes the IDE.
I do not think it is a good idea. Use a version and stay with it until you’re done (or update to a new version and do the job done with it).

NB project is about 50MB. not trivial.
Especially if you have images and icons (macOS Icons are 1024 x 1024, they are really large… vs 256 x 256 from Windows).

At last, the error message really miss the important information, but maybe that trouble comes from many different Controls (I have not tested, but if you use Controls added in 2022r4 that does not exists in 21r3.1, reporting them all could be a large task.).

And since Xojo will not modify 22r3.1…

Check what is new from after 21r3.1 until 22r4.1 in all release notes and change these for 21r3.1…
Or simply use 22r4.1 and forget the whole (if you can).

Nope nothing added or changed using R4, all I did was open the project, save and attempt to run.

I was using R4 to locate a nilObjectException which for some reason R3.1 didn’t find. All the coding etc is done in R3.1. But made the mistake of saving it in R4 at one point.

Silly me… forgot I have daily backups only main desktop Mac (it’s late here and am using laptop). Will revert to a version from R3.1 from earlier in January before this issue started, will take a couple hours to find.

Easy peasy lemon squeezy job for tomorrow.

Here’s an example of what happens saving a project with a newer Xojo and read it with a later version:

image
This appears when Layout (Design window Editor) is selected.

Release Notes for 2022r4:
https://documentation.xojo.com/resources/release_notes/2022r4.html

Release Notes for Xojo 2022r4:
Bugs fixed: 109
Features added: 18 → Look here (*)
Documentation changes: 123
Examples changed: 1

(*) Set the seach text to “Feature Request” to get the changes lines…
Do you use SQLite ?

OK I’ve sorted this from an earlier backup.

But I’ll suggest something: Make sure Xojo version X cannot open a file saved from version Y, where version Y > X.

Including hierarchical dot-point revisions.

SQLite ?

No… my product is pure Xojo, it uses no plugins, and the database engine is written in Xojo from the ground up. No issues with licences, no royalties. It is also subject to the US DOD ITAR constraints so sorry cannot release source code.

It does warn you that there may be issues which allows you to cancel the operation.

This problem doesn’t happen every cycle, but sometimes when you make a version jump like you did, there are things that just don’t translate well.

My general rule (as an ex-Xojo engineer) is that if you’re working in an older version for some reason and need to compile in a newer one, either:

  • never save
  • save in text format and be careful about the changes you keep. Anything new or changed that a newer IDE adds is suspect.

Generally I just tell people to keep moving forward because like other software, it’s just easier on you that way.