Or if Xojo absolutely wants to go to events 2.0, allow for Events 1.0 to run with API 1.0 and 2.0 projects
That is split the evolution of the events and the rest of the API.
cant go backward with things are as they are now and that cripples many third parties - those who develop custom controls for other users and for people writing apps that need to be used on old version of macOS Windows etc which reqire old versions of Xojo
thats THE single biggest pain point with renamed events
Please do not revert em. Find a solution that works for all of us. Those of us who invested now countless of hours to adapt, would loose so much work
10 years of work though ?
thats one clients conundrum with API 2
We are only talking about the event names, not all of API 2 here. The IDE could safely change Opening back to Open so you lose nothing if you have changed already.
While i think a lot of API 2 changes were not needed and create unnecessary work, and while I am not happy about that, I can live with it as long as the events names are reverted.
It would be a bigger headache of Xojo Inc then for us because of need to change Docs back for event names … but there are a lot more of us.
I just confirmed that changing the RBProjectVersion value to:
And replacing Opening events definitions with:
Allows a project to load and run properly in 2019R1.1
What about this:
- Xojo 2019R2 and later store keywords using the API1.0 names, e.g. “open” instead of “opening”, and “dim” instead of “var” etc. This makes projects backwards compatible
- The new IDE auto-translates keywords on the fly, showing “opening” instead of “open” to the user, but storing the API1 keyword internally.
- In other words, API2 is not really a new API for file format, rather it’s just a set of aliases that are shown/hidden while editing.
- Longer term - if the IDE has really good alias ability, this could allow other features, such as mutliingual programming (programs could be stored in English, but edited in $Language)
- truly new API2 features (new classes, or new method signatures) which could not be backwards compatible would be stored in API2 format on disk.
and what about “raise event” in code ?
if I subclass push button and in some code in my custom subclass raise event using any one of the legal syntaxes )which may just be the event name with or without params or following a “raiseevent”
its not JUST the storage on disk
properties present issues going back & forth as well
[quote=461201:@Emile Schwarz]if it is still possibe to export a project to XML, is it possible to change Opening (whatever this API2 Event name is) to Open in the XML file, then open back the saved XML and get an API1 type project ?
If you’ve used “Save-As” then all inspector properties that have an API2 replacement, have lost their API1 values. Once you open the modified project in a pre 2019r2 Xojo, you’ll find that fonts, colors and more are reverted to default values.