FR: Revert changes to events to pre-2019r2

General
1

See <https://xojo.com/issue/58078>

2

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.

3

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

4

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…

5

10 years of work though ?
thats one clients conundrum with API 2

7

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.

-Karen

8

I just confirmed that changing the RBProjectVersion value to:

RBProjectVersion=2019.011

And replacing Opening events definitions with:

#tag Event Sub Open()

Allows a project to load and run properly in 2019R1.1

9

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.
10

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

11

[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 ?

[/quote]
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.