Dialog Menu timeouts

[Domitan Redenblack]

Since Linden in their wisdom have left us no way to close the Blue dialog menus, we are left with hacking complext timeouts for the different menus and submenus and states etc of the object.

My problem is that the blue Dialog stays on screen if the user does not hit Ignore, and may much later decided to click buttons or become confused etc. If my object has timed out and changed states etc, then clicking buttons can be a mess.

And yes, I have a complex object now that is going to need a complete re-write simply because I can't close the blue dialog, yuck.

So, question: For blue dialog menus, and their associated listeners, should I always go to a new state? Or is there a better way to handle timed-out menus, or menus left on screen and then used later?

 

[Innula Zenovka]

Menus in V3 behave very differently from the way they used to behave in V1; you can now dismiss stale menus simply by having another menu pop up saying "Sorry, the menu has timed out," with just an OK button.    

For what it's worth, I don't normally bother with new states simply to close listeners; usually it's simpler, I think, just to close the listener in the timer event, using a variable like menuOpen if I want to distinguish between various things that might happen in the timer.

[PeterCanessa Oh]

You may want to take advantage of another hack - the button-text length.  Since only the first 10 characters or so are shown but the text can be up to 24-ish (http://wiki.secondlife.com/wiki/LlDialog#Appearance) you can use the excess to pad the text with mode-specific information.  That may help you in determining whether a menu response is still relevant.

Another option is simply to use different (eg; random) channels on each menu call/listen.  That way, once the script has timed-out the menu and closed the listener it is very unlikely to even hear an irrelevant choice.

[Domitan Redenblack]

---

PeterCanessa Oh wrote:

You may want to take advantage of another hack - the button-text length.  Since only the first 10 characters or so are shown but the text can be up to 24-ish (

http://wiki.secondlife.com/wiki/LlDialog#Appearance

) you can use the excess to pad the text with mode-specific information.  That may help you in determining whether a menu response is still relevant.

Another option is simply to use different (eg; random) channels on each menu call/listen.  That way, once the script has timed-out the menu and closed the listener it is very unlikely to even hear an irrelevant choice.

---

Hmmm, an interesting idea wold be to append the Unix time as the last word of the button name, etc. Then you would need no timer at all, just check the time of the button etc

 

[Qie Niangao]

This is a tangent, but you mentioned going to a new state.  One reason to do this is to disable touch-related events while processing a touch the script has already received, to avoid the housekeeping needed to safely handle multiple inputs, perhaps from multiple users, simultaneously.

For many "real" applications, of course, it's simply necessary to handle multiple users' inputs asynchronously; for simple cases it may be no problem anyway, but if you find yourself tempted to use a global variable to record the "toucher", you should ask yourself what happens if somebody else touches the object before you've finished with the first one.

(This is actually more general than just the touch-related events, but it's only a tangent to the thread topic anyway.)

[Ela Talaj]

There is no reason to badmouth Lindens. They follow the basic principles of real-time programming and you either don't know them or try to deny. "Ignore" is not "Cancel".  "Cancel" button would've signified an event (interrupt), but the "Ignore" button signifies no event. It is the same as if user takes no action at all (for instance user opened the menu and then crashed). Therefore there is nothing to deliver to the program (no interrupt). Any real-time system takes care of such situation by timing the expected event (in the menu case, user's response) and on timeout blocks further processing of same. In the menu case that would be removing the listen on menu timeout. In a simple script timing the menu response is trivial even if the timer also times something else. In a complex system one might separate menu system processing in a dedicated user interface module.