Removing an lldialog

I am using an llDialog and I have a timeout set. However, I see no way to remove the llDialog when I time out. I take off the listen so it doesn't do anything, but it would be nice to remove the llDialog.

There is no way to do that.

You could bring up another dialog saying, "Nevermind. Please ignore the dialog below," but I doubt that's quite what you want. Heh heh.

When I stop listening for responses to the dialog, I usually send an IM to the person who touched the object (shows up in chat) saying that the menu has timed out.

Note that, if they push the "Ignore" button that SL puts automatically on the dialog, your script is not notified.
.

I usually automatically start some listens when using a llDialog menu. If you store the listens as integers then you can use llRemoveListen later on. Basically I do something with functions looking like these basic examples:

integer menuChannel = 234; // for dialog and listening
key user; // stored on touch or on rez or however is best for the particular script
integer listen0; // used to store the menu options
integer listen1;
integer listen2;

menu(string description, list options)
{
listen0 = llListen(menuChannel, "", user, llList2String(options, 0));
listen1 = llListen(menuChannel, "", user, llList2String(options, 1));
listen2 = llListen(menuChannel, "", user, llList2String(options, 2));
llDialog(user, description, options, menuChannel);
}

then on a timer or after an option is chosen I remove the listens with a function similar to this:

stopmenu()
{
llListenRemove(listen0);
llListenRemove(listen1);
llListenRemove(listen2);
}

As far as removing the actual blue dialog window (which I think is your original question) then there is no way to do that with LSL.

I've just had the object InstantMessage the DetectedKey saying the menu has timed out, please try again.

test

I usually keep dialog listens open so that someone can choose an answer any time they like. The number of applications in which an immediate response is required and a timeout must be implemented is pretty small, and can be handled well with script state in any case. I've always thought it a little silly to timeout dialog listens out of a paranoia of having one more listen open on some obscure never-used channel.

While some conscientious thought is appropriate for keeping the lag low, when it starts interfering drastically with usability, functionality, readability, and maintainability--making a very simple listen script become a confusing jumble and reducing its concurrency for multiple simultaneous users, I think it best to assume the system can handle the extra listen, and will do so even more gracefully in the future as performance increases. If a user wants to touch my creation (or whatever), get a dialog, ponder the matter, go to lunch, come back, and then make his/her choice, why not let them? Computers are patient machines.

hmm many of the Dialogs I use open individual listens for each touching user, and close them all on a timeout after the last frequent touch.... I'll have to think about a method to warn users that the listen is closed (perhaps keep the keys in a list)....