Is there a way to immediately stop an activity?

I’ve got an activity going which is buried layers deep in menus and such. So even abiding by ‘rule succeeds’ just moves back up a layer in the activity. I’d like to just be able to say ‘stop the whole activity right now’. Is this possible?

  • Wade

There is an abandon the X activity phrase, but it can only be used if you manually start and end the activity. See section 17.7.

You could also convert it into an action, which would be easier to get out of. Kerkerkruip has many actions which are really just glorified activities.

Is this a case of rules invoking rules invoking rules, or are the menus stacked up in an array somewhere?

If you’re really down in the call stack, there’s no way out except to do “rule succeeds” at each nested layer.

Specifically, I’m modifying Emily Short’s Menus. I’ve come to admire its cleverness in the process. It still does my head in slightly but I think I follow it.

[code]Displaying is an activity.

Rule for displaying (this is the basic menu contents rule):
now current menu selection is 1;
show menu contents.[/code]

Its main action is ‘show menu contents’.

When you’ve got a menu in front of you and press a key, one of various rules is considered, meaning you

  • might go up a level (rule succeeds - exit if at top level)
  • stay at the same level and print the choice text, or
  • go a level deeper by in turn calling ‘show menu contents’ again.

So I think it’s recursive. If you’re deep, to get back to the previous iteration of ‘show menu contents’, you have to issue a rule succeeds.

What I wanted to do was just exit the activity when you may be 3 layers in. From what Zarf said, it sounds like I manually need to back out of each layer?

  • Wade

I’ve decided to rewrite the whole thing in a way that eliminates the recursion.

  • Wade

If you can rewrite it in a way that keeps the API the seem (or very close to it), let me know. I’ve started working on Menus by Emily Short too, and I’ve put my new version at … /Menus.i7x

I looked up API so now I know what it stands for, but I don’t know exactly which things you’re saying you are interesteed in having be the same as in the original version. However with the sledghammer renovations up I’m doing, I doubt it will satisfy that requirement :slight_smile: I dare to hope you may like it better than the original extension. I will put up a new topic about what I’m doing.

  • Wade

Wade, the common practice I have seen is to try to make APIs backwards compatible by preserving the same legacy function calls so no code will have to be rewritten, and adding optional parameters or alternate functions for the more complex added features. In LambdaMOO this is very easy, because I can give the same function multiple names and a function can detect which of its names was used to call it. Frequently I keep the legacy name of a MOO verb but add a ‘more advanced’ name you can call it with for extra features. I also tend to add new input parameters to functions only on the end, even when it produces an illogical order – because that way the older function calls (with the new parameters omitted) won’t have their inputs jumbled. I don’t know how to do any of this in Inform yet, but I would hope there would be counterparts to both methods.

Right, thanks. Menus doesn’t have too many calls or parameters, so I’ll try and leave their names alone, and give any parts that I add all the same name prefix that just belongs to the new extension.

  • Wade