Shell Problem: 2019r2 -> r2.1

  1. 3 weeks ago

    Robert L

    Nov 26 Federal Way, WA (Seattle Area)

    Mac : Mojave

    I have code that has been running fine in 2019r2 but now throws an error with 2019r2.1.
    I have a Shell controller (MyShell) placed in a window (winMain). I have written code for the ResultReturned event of that controller.

    Now I get an error:

    MyShell on winMain implements the event "ResultReturned," but its superclass Shell has already implemented the event. Sub ResultReturned()

    When I look at the release Notes for r2.1 and all the changes that it has made, I cannot see anything that I can connect to this problem.

    Nor can I understand what this error message is trying to tell me. Can someone clue me in about this?

    Thanks.

    you need to use the .DataAvailable event again. Xojo dropped the newer event names ... Yeah i know, they don't know what way they wanna go ...:)

    From the 2019 R2.1 release notes:

    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. You will need to adjust code that is moved from Toolbar.Pressed and Toolbar.MenuSelected back to Action and DropDownMenuAction due to different event parameter names.

  2. Derk J

    Nov 26 Pre-Release Testers, Xojo Pro Answer
    Edited 3 weeks ago

    you need to use the .DataAvailable event again. Xojo dropped the newer event names ... Yeah i know, they don't know what way they wanna go ...:)

    From the 2019 R2.1 release notes:

    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. You will need to adjust code that is moved from Toolbar.Pressed and Toolbar.MenuSelected back to Action and DropDownMenuAction due to different event parameter names.

  3. Robert L

    Nov 26 Federal Way, WA (Seattle Area)

    There are some strange things here:
    When I run 2019r2 and place a Shell Controller in a window and try to add an event handler, I am given a choice of two events:

    1. Completed
    2. ResultReturned

    When I run 2019r2.1 and place a Shell Controller in a window and try to add an event handler, I am given a choice of two events:

    1. Completed
    2. DataAvailable

    Now the documentation that I have with 2019r2 for Shell speaks of TWO events: Completed and ResultReturned.

    ResultReturned is described as being

    New in 2019r2

    . I believe that it was supposed to be the replacement for DataAvailable and the name is, IMO, more "accurate"

    Now when I look up Shell in the Documentation on-line I see TWO events: Completed and DataAvailable. It is as if ResultReturned never existed.

  4. Robert L

    Nov 26 Federal Way, WA (Seattle Area)

    Thanks Derk,

    you need to use the .DataAvailable event again. Xojo dropped the newer event names ...

    Finally I am irritated. I liked the new event names (Opening vs Open) and am sad that they have been pulled. I did read inputs from all those folks on the forum who thought this change was the apocalypse, but I was happy with it.

    The IDE will automatically change any API 2.0 events back to the prior names when a project is loaded.

    Well, using 2019r2.1, I noticed that all the events like Open that I had gone and renamed Opening had reverted to Open automatically so that was a waste of time. I liked the more accurate names and embraced the change, but my enthusiasm is being punished.

    However, I had not realized that ResultReturned was also caught open in this regression.

    I would just note that this was not automatically changed back to DataAvailable so it ended up costing me more confusion and time when I got the error I described that I could not decipher.

  5. Greg O

    Nov 26 Xojo Inc scout.galaxy.barn

    Please report this in Feedback so we can get this fixed.

  6. Norman P

    Nov 26 Pre-Release Testers, Xojo Pro under THE bus

    @RobertLivingston When I run 2019r2

    Stop right there
    Xojo has update with 2.1 and withdrawn 2019r2 for download
    I would suggest moving to 2019r2.1 immediately and discontinuing using 2019r2

  7. Robert L

    Nov 26 Federal Way, WA (Seattle Area)

    Thanks Norm. I certainly will move forward. I generally do promptly. When my code stopped working, I was mystified. I had upgraded to 2.1 on my Desktop and now I had an error that I was (sure?) I had not had before. But I am never completely sure. I thought I might have done something stupid somewhere along the way. For example, inadvertently removed some code with an errant hit on a Delete key. I do this kind of thing occasionally.
    It just so happened that I had a recent version of the project on my laptop which I had not yet upgraded to 2.1. It was still running on 2.0. So that way I could move an identical version of my project to the 2.1 environment and confirm that indeed the error occurred only in 2.1.
    Confused, I finally decided to post to this forum. Derk knew the answer. On my own, I was stumbling toward figuring it out by myself being able to test projects in both environments. I was writing the results on my trials at the same time that Derk was writing his "solution".
    Again, I appreciate this forum.
    Again, I am disappointed in the reversion. And annoyed that I saw no notification, before it actually came out, that 2.1 was going to reverse all the event renaming. So I was spending time "cleaning up" my code while Xojo had already decided to abandon the thing.
    I do not understand why the new verbiage could not be retained since the deprecated verbiage still worked in 2.0. But they have completely killed the new verbiage. For myself, I feel that Xojo had sort of done the mini-equivalent of moving toward the metric system despite all the wailing that accompanies such changes. I embraced it, training my mind for the new system. And then the rug was pulled out. The stuck in the mud crowd won.

  8. Norman P

    Nov 26 Pre-Release Testers, Xojo Pro under THE bus

    For many it was the reverse feeling of having had their years of work suddenly tossed out for the sake of the renamed events and such. And it also hurt their businesses and their ability to provide software to their clients.

    I might have been a good idea for Xojo to tell people beforehand about this course of action but thats something you'd have to take up with them

  9. Peter G

    Nov 26 Boston, MA

    I liked the new event names, as well. Thought it was a big improvement. But, OTOH, breaking 3rd party apps/plugins was a non-starter. They had no choice but to revert. Too bad there wasn't a more clever way to do it. e.g. Use an "alias" name for display, but use the legacy name in the actual code. But what do I know? I haven't even committed to using Xojo as a development environment yet, but I'm getting closer ;)

  10. Robert L

    Nov 26 Federal Way, WA (Seattle Area)
    Edited 3 weeks ago

    Use an "alias" name for display, but use the legacy name in the actual code. But what do I know?

    I also "don't know" the intricacies of the question. As the storm about the event name changes hit, I was hoping it was going to be possible simply to remove the warnings about the "deprecated" old names (unless the user actually wanted to see them them) and simply allow the user to use the old name (Action) or the newer name (Pressed). Legacy code would continue to work (as I understood it to do in r2.0 anyway) and then new code could use the newer, and IMO better, names if the developer wished.

    But developers of old code would not be inundated with all the warnings and alerts about the "old" event names if they did not want to hear them. The documentation would simply refer to them as "synonyms" explaining that one of the synonyms was that which had been used historically and the other was the one thought more linguistically informative. The user could use whichever he/she preferred. They could be color-coded in the completion tab suggestions and the documentation etc. so they were readily distinguishable.

    I am sad that the forces for change were completely routed rather than accommodated. I am not sure why this was not possible. I do not completely understand the needs of the "third-party developers", i.e. why this sort of solution was impossible for them.

or Sign Up to reply!