Shell Problem: 2019r2 -> r2.1

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:

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 …:slight_smile:

From the 2019 R2.1 release notes:

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 [quote]New in 2019r2[/quote]. 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.

Thanks Derk,

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.

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.

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

[quote=464712:@Robert Livingston]
When I run 2019r2 [/quote]
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

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.

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

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 :wink:

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.