un-deprecating R2.1

I’m encountering issues in un-deprecating. I have spent hours trying to debug a program that I started in a pre-R2 version, mostly updated in R2 to the new API to a working version, then spent hours un-deprecating it to run in R2.1. It is that last step that I think should have been mostly automatic, but instead took hours of effort.

Quoting from 2.1 release notes: 2019r2.1 — Xojo documentation :
“Events have been reverted back to their pre-r2 names to make it easier to move between 2019r2.1 and prior versions. The IDE will automatically change any API 2.0 events back to the prior names when a project is loaded. If there are two events with the same purpose in a project (such as Open/Opening) they will be left alone so you can review the code and remove the now-unneeded additional event. “

Could someone please translate that statement, especially the last two sentences?

Here’s an example of a problem that I encountered where a project runs in R2, but if I open with R2.1, then I get this error message (and the project does not run):

Location: Window1.SelectColorButton.Pressed Declaration
Issue: SelectColorButton on Window1 implements the event “Pressed,” but its superclass PushButton has already implemented the event. Sub Pressed(index as Integer)

( In this example, "SelectColorButton” is a control (with super “Pushbutton” , the standard button used in desktop apps) and is a member of a control set and is instantiated in Window1 three times with indices 0,1,2).

By my reading of the 2nd sentence from the release notes (“The IDE will automatically change any API 2.0 events back to the prior names when a project is loaded.”), I would expect R2.1 to have automatically changed the API 2.0 event “pressed” back to the prior name “action” when the project was loaded, but it didn’t and kept the name “pressed”.

The 3rd sentence is also confusing ("If there are two events with the same purpose in a project (such as Open/Opening) they will be left alone so you can review the code and remove the now-unneeded additional event. " In this case, since the old pushbutton “action” event and the newer “pressed” would seem to have the same purpose, should we expect R2.1 to have left this alone? This seems to be the case.

In other words, by my reading, sentence 2 implies that R2.1 would change the event, while sentence 3 implies that it would leave it alone.

Thanks…

Hi Craig,

I’ve migrated most of my projects from R1.1 to R2 and then R2.1.

I don’t recall encountering the same error, but what I understood by the Release Note statement you quoted was that it applied to any Event Definitions that you may have added to sub-classed controls. Such as having the standard Action => Pressed event, and then implemented an Event Definition also called Pressed in R2.

When I opened my project in R2.1, the standard event names were automatically reverted back, but the Event Definitions where left alone - I guess for me to decide whether I wanted to rename them back to their standard names. Which I didn’t do, because I like the new Event names :slight_smile:

Maybe I’ve misunderstood what was happening here, and that statement applies to some other circumstances. But hopefully that helps(?)

Good luck.

You sublassed this Control and the Event (Pressed) is already used: you cannot have two times the same Event (one in the Control, one in the SubClass).

This is standard behavior, not specific to 19r2 or 19r2.1.

So unsubclass the Control, then you will be able to add it in the Control.

Scott, Thanks much… I think this makes more sense now.

Perhaps it would have been better for the release notes to say: “ Now, new event handlers added in R2.1 will use the pre-R2 naming convention, but will leave alone existing event handlers added with R2 so that you may decide which convention to use.”

In my case, I started a project in R1, converted to R2 and then to R2.1. Along the way, I had instantiated sub-classed controls at runtime as part of a control sets and that were within container controls. Prior to the new API I had defined a double-click(ed) event in a sub-classed canvas control, but later decided to remove it and move it to certain instances of the sub-class that were members of a control set. To do this, of course I had to delete the double-click event from the parent subclass.

One confusing error message from R2 was that the double-click event in the instances were duplicating a double-click event definition in the parent sub-class, though it clearly had been deleted.

I was relatively new to all of this… so it took a while to work this out and I attributed the errors to my lack of experience. However, I am now suspicious that some of these errors were not mine. I suspect that some API 1 to API 2 and back again conversions are failing in the context of control sets.

The error message I cited above was actually found in an Example file shipped with R2.1. You can check it out readily if you have R2 and R2.1 available. See: GradientExample.xojo_binary_project in the “Graphics and Multimedia” folder. On my computer, it runs with R2 but not with R2.1 that it shipped with. Maybe this is a better example of the “Oops!” paradigm?

[quote=465493:@Craig Hyde]Location: Window1.SelectColorButton.Pressed Declaration
Issue: SelectColorButton on Window1 implements the event “Pressed,” but its superclass PushButton has already implemented the event. Sub Pressed(index as Integer)[/quote]
You cannot do what you wnt to do, tha is what the sentence above said.
Once deleted, save the project and try again…

Now…

(Emile, thanks… my last responses landed at the same time as mine… )

The error message I cited above was actually found in an Example file shipped with R2.1. You can check it out readily if you have R2 and R2.1 available. See: GradientExample.xojo_binary_project in the “Graphics and Multimedia” folder. On my computer, it runs with R2 but not with R2.1 that it shipped with.

I found that I can fix this by copying the code in the “pressed” event handler, deleting that event handler, add a new event handler “Action” and pasting in the old code.

Is this what you meant by, or equivalent to, “unsubclassing” ?

I find the error message from XOJO R2.1 to be confusing… it seems that the event (either named “action” or “pressed”) was never defined in the parent control, but only defined in the subclass.

That’s what I did 424 times in my app and now I have no errors or deprecated warnings.

Tim- 424 times! Clearly I’m a lightweight with only a few dozen changes.

I suppose that on the plus side, thanks to API 2, we’ve learned that this website uses a modesty filter! Just wait until we see : !@#$% is deprecated, you should use !@#$%-ed instead.

Sometimes I really wonder about Xojo. During beta they said: all events should revert. I said: no, that doesn’t work. They said: can’t reproduce. I said: here is a project. Bug was fixed. I checked: from 130 locations 100 were fixed and 30 not. I didn’t bother with a new bug report and fixed the 30 remaining locations myself. Those were for control arrays.

That would have been inaccurate. They did not “leave alone” event handlers added with r2. At least if the situation was simple. Most of the new code that I wrote with the new terms had those terms reverted.

I suspect that the code to revert back to the old naming scheme could handle simple situations. Clearly, it was not perfect. They missed some “rare” events like (ResultReturned/DataAvailable) and I ran into that problem. In that situation, I got the same confusing error message. [quote]…but its superclass … has already implemented the event.[/quote] Ultimately the solution was to manually revert back to the old terminology DataAvailable.

If I understand Beatrix and Craig, control arrays were also not handled properly in the “reversion”.

Early adaptors got punished in all this r1 → r2 → r2.1. And people who liked the new terminology of r2 got double punished if they embraced it early and enthusiastically.

Firstly, they entered into a bunch of work that ultimately accomplished nothing and secondly, they ended up back with linguistic terms that they did not prefer.

You’re not wrong Robert, a lot of us ended up spending much more time and mental energy than anticipated with the transitions. I’m still doing some conversions with my few projects.

[quote=465533:@Robert Livingston]Early adaptors got punished in all this r1 → r2 → r2.1. And people who liked the new terminology of r2 got double punished if they embraced it early and enthusiastically.

Firstly, they entered into a bunch of work that ultimately accomplished nothing and secondly, they ended up back with linguistic terms that they did not prefer.[/quote]

But I wouldn’t say nothing was accomplished. Aside from some gains in functionality in API 2.0, e.g., Thread.AddUserInterfaceUpdate, and a better (albeit not perfect) conformity in property and method naming - we became familiarized with what the Event naming schema will be for future target platform additions and upgrades, i.e., Android, iOS and Web.

For myself, when I subclass a control now to customize it, I use the new names when adding Event Definitions. I keep a copy of 2019r2 around just to lookup those names.

and …

Why, oh why, would you go through that? I understand that you’re giving the Xojo players a chance to make things right, but you’re keeping a no longer available version on your system as a hedge? I’m being sarcastic here, but are you an hourly employee? :S

I’m in the same club as Craig and Trixi - except that after 40 hours or hair pulling frustration of “re-refactoring” one project that I’d already spent almost 90 hours on moving to 19r2, I just threw out the 19r2 conversion and I’m sticking with the 19r1.1 work as it sits. Thank goodness that 19r2.1 compiles 19r1.1 code and for version control.

Ah, no. At my day job we don’t use Xojo. I’m learning, using and building apps in Xojo in my own time and dime.

I know many here have a considerable investment in pre-2019r2 built projects, like yourself. I understand that. But I’m still relatively new to Xojo and I don’t see much reason for hanging on to pre-API 2.0 code for my few projects, so I’ve basically migrated (or nearly so) all my work to 2019r2.1. And I’ll keep upgrading as each version becomes available, when I can.

All I was trying to say earlier was that when it comes to adding an Event Definition, I like using the previously “proposed” Event names to keep my code as readable as possible (by using the local LR from 2019r2). After-all, an Event Definition name can be anything, right? Like LightSaberMoving(x As Integer, y As Integer).

I also plan to try and make use of the API Version checkboxes as much as possible with the next release <https://xojo.com/issue/58351>

This way I figure my Desktop app code will be more consistent with Android and other targets as they are introduced or upgraded with API 2.x in the future.

Maybe we’re just misunderstanding each other, but I hope this helps you to understand where I’m coming from.

All the best!

I may be wrong, but I don’t think the 2.0 event names will be used for Android or iOS… I would think they would want to keep things as consistent as makes sense between destktop and the other platforms going forward.

BTW the “usual” thing to do when implementing an event in a parent class that you also want in subclasses is to create a new event with the same name in the subclass, and raise it in the parent event to give a consistent API …

Of course if no one but you will ever see the code, and you always do that , it does not matter. But many of us have found using the same name as teh framework event is most intuitive way to do things as it stays consistent with Xojo docs.

-karen

All good points Karen, thank you.

But yes, I’m pretty much the only one who is gawking at my code right now, so I think I’m good in that regard :wink:

If I do share any code in the future, perhaps as an effort to potentially help others or maybe even provide a 3rd party control or open-source project of any kind (or anything of that nature), rest assured I’ll adhere to the most current Xojo docs at that time.

That’s good advice, thank you again.

[quote=465602:@Scott Cadillac]All good points Karen, thank you.

But yes, I’m pretty much the only one who is gawking at my code right now, so I think I’m good in that regard :wink:
[/quote]

I have provided a few controls over the years… While they worked, I hate to think what the people who saw the code (particularly the pros!) thought about my coding! :wink:

I get embarrassed when I look at my old code, even if I only wrote it last month!

  • karen

But if you are at least consistent in how you always write it, then there is no need to be embarrassed. Because once the reader understands your style, they can always read what you do.

I’m a Dev lead, with a team, and I tend be quite verbose with my syntax and very OCD about capitalization, tab counts, spacing, scoping rules, etc. And I make all on my team follow my style, so that new people assimilate much easier. It may be painful for them at first, but with over a half-a-million lines of code in our main project (12 years in the making), they learn to appreciate the consistency quickly.

And besides Karen, you have a superb reputation in the forum, as does Tim, Robert, Craig and many many others here.

I bow to your Xojo greatness, sincerely.

Quite well. And it does make a very big difference on how each of us deals with (and feels about) what a number of us feel are unnecessary changes to a stable platform.

I’ve found your code to be quite straight-ahead and “get it done” rather than trying to adhere to some Ph.D’s philosophy on writing code. After all, it’s the result that counts.

My team appreciate that in that we only have two “requirements” in coding style:

set et ts=4 autoindent nowrap :wink:

and comment the first use of any variable or function/method/class with a full description.

We don’t dictate even the language to be used - C, C++, Python, Java, PHP, ASM, and even Smalltalk for one project - only that your result must adhere to the Unix premise of Focused tools that do one thing well and play nicely with the other tools in our application portfolio.