My app has a container control with code in the Open event. There is an event definition and the code in the Open events contain
RaiseEvent Open
Then came along API 2.0. I changed the name of the event to Opening and the event definition to DoOpen so that the code now was
RaiseEvent doOpen
However, the event in the parent Window didn’t change. I still had the Open event there. As result I thought I was having strange problems in my app because the Open event didn’t fire. My clue was that the Open event of the container in the parent window didn’t have a “change name to opening”. I added the event doOpen and copied the code over. No everything works fine again.
Bug. Had similar issues. I just opened a new Tab with the same content and it worked again. I was to lazy to report and feared it will be closed anyway without an example project i can’t deliver…
Open as an event can still be implemented - it still exists
But because you implemented Openeing then the system wont call Open any more
This is the situation I ran into where you quite literally cant update your code 100% correctly in 2019r2 because both events exist and so you get this situation
why ?
open is still a legitimate event you can implement BUT because Open and Opening both exist the runtime now just calls opening and Open is extraneous
this is something I mentioned during betas about the problem with renaming events like they did but …
If you context-click “Open” the IDE should offer to replace it with “Opening”.
If there’s an “Opening” AND an “Open”, the IDE should report it to the User as an Issue. Not just ignore the “Open” Code.
If there’s none of both, the IDE should only offer to add an “Opening”.
This is what i would expect. There should be not way WITHIN the boundaries of the IDE, that the User can add both.
And yes, there may be cases where an "Opening and an “Open” at the same time are intended. But the IDE should just not allow it.
The IDE normally renames event definitions where I have used them. It didn’t do that for the change from Open to doOpen. I just check and other event definitions are renamed.
@Sascha S : the context menu item wasn’t there for my non-firing Open event. So the IDE sort of knew that something was wrong.
Sounds legit, but yesterday i also saw the same behaviour and just opening the same window in a new Tab “solved” it. After that the Analyzer gave weird issue messages and i had to reload the project and start over again. But that’s another story.
I am really carefull currently with updating my projects because we all know this will be a bumpy ride. GitHub is my “best friend” currently.
[quote=457343:@Beatrix Willius]The IDE normally renames event definitions where I have used them. It didn’t do that for the change from Open to doOpen. I just check and other event definitions are renamed.
[/quote]
right - it wont do that because OPEN still exists on the base class and so you CAN implement it - deprecated or not
So the IDE wont rename it
yeah … this is a nasty one and I’m sure it will bite others because its not obvious whats going on
and why in a large projects you cant do it well in 2019r2
[quote=457339:@Sascha S]And yes, there may be cases where an "Opening and an “Open” at the same time are intended. But the IDE should just not allow it.
[/quote]
The IDE should at least be smart enough to consider opening unavailable if open has already been implemented in the super. I’ve been complaining about that for months now.
I finally sort of gave up and will just wait for the forum to fill with “my project is broken! It was working and now it doesn’t. I don’t know why…” messages. sigh.
Sad. My License expired and i just wanted to ask you if you will adapt DataView to API 2.0. I downloaded 1.15.0.0 yesterday and already found it still throws deprecated warnings in the analyzer.
But i (thanks to @Norman Palardy) understand your challenges with API 2.0 and hope Xojo Inc. will find a way to fix this. (And will purchase your update soon anyway)
and already found it still throws deprecated warnings in the analyzer.