Ignore Button

Scripted dialog boxes include an IGNORE button that, according to Kelly, must close the box without signaling the script that the box has been closed. I suppose this is another instance of "we won't grant you a useable feature because it might be used to grief the cooommmuuuuunity."

Whatever, it leaves scripts hanging in the virtual air, waiting to continue execution based on a dialog chat, with no idea that the user has closed the box. There are two solutions for this.

One is to add a timer to the script so that it resets every thirty seconds or so. This can even be activated when a box is produced and deactivated after timeout to help avoid some of the lag initiating a timer necessarily forces on the sim.

The other option is to put the touch code in every state so that the user can essentially reset the script, whether they've processed the existing dialog box or not, by touching the object.

Both of these options place the odus squarely on the user. They have to understand that the script is timed and a dialog they are looking at will simply not work after a number of seconds. Or it's up to them to understand that layered dialog boxes may or may not operate properly depending on what state the script is in after pressing buttons on some and ignoring others.

This would of course be solved by the script simply knowing that the user had pressed IGNORE so that it could continue processing. But, since LL feel compelled to force scripters to push this responsibility onto the general public, I'm wondering what the general public prefers, timers that deactivate a box after a number of seconds, or touch states that allow the opening of layers of boxes without knowing which ones are and are not active?

I'm only putting the two options in the poll but of course feel free to comment other ideas.

I do agree with Kelly, that a ignore button should just close the box and act like i have ignored it.
What would be most helpfull would be a build in way to tell the user that there is a timout on the dialog. And even automaticly close after said time.
We also could do part of that ourselfs on the dialog description/text and add to the top, [This dialog stops working after 30s].
But the dialog text is already very limited, and don't like to put a extra line there.

I just wish LL update the menu dialog with some fancy features.

Hmm. Yes, I thought that Karen's response a bit... odd, also.

Apparantly Microsoft thinks a return value of 'ignored' is useful (just happened to have MSVC up and running, so I looked it up quickly):

-- snipped from MSDN docs for the Win32 'MessageBox' API --
MessageBox

The MessageBox function creates, displays, and operates a message box. The message box contains an application-defined message and title, plus any combination of predefined icons and push buttons.
:

Return Values
:
IDIGNORE Ignore button was selected.
:
-- end snippet --

I'm sure users of other widgetsets out there can dig up some similar retval descriptions.

Perhaps the real reason for not providing a return value is that LSL in its current state would make implementing feedback-on-ignore a bit difficult - but that's just my personal impression, of course.

Happy scripting!

That would work Frans. In fact, it would be great to include a timer parameter in the dialog call so that the client itself would close the box at the same time that the script continued processing knowing that the box was no longer visible.

HAHAHAHAHAHAHAHAHAHA!!!

Oh-- Oh-- Ha! I guess this is par for the course from a company that listens to house wives and 1337 g4m3r$ for advice on virtual communty building and IP rights. As if a user could understand. How politically correct of them.

Beat Kelly over the head with a VB.NET book until the definition of "event" sinks in? I dunno.

In my opinion, a program should *always* get a useful return code from the user. If it's solely because of the label "Ignore" then the button needs to be relabeled like "Decline" or "Cancel" or just removed entirely. A script of course *must* react on a dialog, whatever option the user chooses. If the user ignores a request, the dialog should send back a "was ignored" message, and the script should terminate or reset, whatever is appropriate.

There are a number of strange things defined in LSL, this is one of them, along with returning the button *Labels* of a dialog instead of the *Index* number. This renders the usage of lists based on the return code of a dialog next to impossible.

I heartily endorse this idea. Having a little timer counting down on the box itself and then automatically closing would be much better. I understand the function of the Ignore button is to prevent badly or maliciously scripted dialogs from being unstoppable, but we need more options.

The problem is, the Dialog is not tied to the script that issued it, and llDialog is not waiting for a reply.

Whatever function issues the llDialog does not wait. Very few things do wait in an event driven language - this is a part of what defines something as being 'event driven' - wannabe VB.NET programmers take note Instead, llDialog launches a wholly separate process that may, or may not, 'say' something. Just as the launching script may, or may not, 'listen' to what the Dialog says.

So, what should the ignore button do exactly? Its only real option would be to 'say' something that the launching script can only guess has having some meaning... bearing in mind that EVERY listening script would potentially 'hear' the same ignore message.

I also find the limitations of llDialog frustrating - it provides only a very basic user interface at best - but unfortunately I think its limitations are an inevitable product of its own design. I think tinkering with it would be pretty pointless. Give me something wholly new.

Having said that, I do in fact quite like Frans' timeout idea as this could be sychronised to removing the Listen Handle after that same amount of time. And touch_start can be used to redisplay the same Dialog that timed-out.

We can hardly expect LL to accomodate user-friendly interfacing, I mean, look at the client. You know what the answer to implementing a client API is? Goes something like this ... ... ... ...

Okay sorry that's not fair. Philip did once answer that concern by stating that we already have an API available to us.

Timer is winning by a landslide!