Stacking llDialogs?

[Monica Balut]

I generate a list of note cards in an object that I want to allow the user to delete or keep by asking for a response via llDialog.  My code goes like this:

 while (NCList != [])
    {
        currentNC = llList2String(NCList,0);
        NCList = llDeleteSubList(NCList,0,0);
        llDialog(owner,"What do you want to do with this note card?  " + currentNC, ["Delete it","Keep it"],CHANNEL);
    }

 

I would have thought that a bunch of dialogs would have been stack on top of each other which would allow the user to process the stack and address each one.

However, instead only one current dialog appears and I can see the text updating for each note card as the code goes through the while loop but only the last one stays on screen for the user to process.

 

What I want is to go thru a list and force the user to address each note card on the list.  I thought of going to a separate state and only returining when one of the two options is clicked.  That damned "Ignore" button is the weak link in this.  I just know that someone will hit it and thereby hang the whole operation despite any warning against hitting it.  I thought of putting in a timer in the processing state but that has its own set of problems.

I'd appreciate any suggestions on how to go through a list like this while forcing a response from the user to each item in the list.

[Darrius Gothly]

Because you can only have one Listen open on a specific channel number, you will only ever get one llDialog to respond. But even if someone does hit ignore, whether the dialogs are stacked or presented sequentially, the result will be the same .. your code will hang.

If you are truly married to the stacked dialogs approach, make sure you use a separate channel number for each one .. perhaps by incrementing the base channel number for each new llDialog call. However I would recommend you use a sequential method where you present each card name, one at a time ... moving to the next only after the user has responded to the dialog or it has timed out.

And that's the critical saving grace here. You should set up a timer event to call llListenRemove and abort the Dialog input routine if the timer event triggers. That way even if they just get called away, your code won't be hung up in forever-never-land waiting for an input that won't come.

I would also recommend you abort the entire process and not just the current notecard in the event of a timeout. Usually a timeout means things are hopelessly out of synch anyway, and you run the risk of the user hitting "Delete" on something they meant to keep after all. (And people tend to get upset when your device deletes something they meant to keep .. never mind that they're the ones that didn't read properly.)

[Ron Khondji]

What you need to do is:

• pick a notecard
• open a dialog
• in the listen event do something with the notecard
• then pick the next notecard
• open a new dialog

This way the dialogs look like they´re stacked.

[Innula Zenovka]

Yeah, in V2, Dialog menus don't stack any more -- https://jira.secondlife.com/browse/STORM-522   -- which breaks some older content.   

I don't think you actually lose the menu; the ones that are overwritten seem to vanish down to the bottom right of the screen with all the IM notifications and so on, but if you're not expecting multiple menus (or even if you are) it's very easy to miss them.  

 

[Darkie Minotaur]

You actually address 2 things in your post which should be dealt with step by step:

Stacked dialogs and reference:

Actually, the dialogs get stacked up airight nicely by your code - but that won't help you to be able to delete single NCs since there is no traceable reference to the NC each dialog refers to.

This seems to be one of your problems that can be mended quite easily - either by:

• calling the dialogs one by one - each one after the preceeding one either has been dealt with or has timed out. Timing out would in effect be the same as one og the two options
• set a different channel for each dialog - this way you can stack them an tell, which one has been answered. This is pretty ugly, but possible in theory as long as you don't need more than 64 (I think) listeners

The Ignore Problem

What you can't do, however, is force the ava to choose from one of your options - Ignore is always an additional option. You just have to deal with it in a timer. What you could do - again ugly - would be to keep track of which one you haven't gotten a 'valid* response to and keep on popping it up until the ava either:

• Responds in the way you want
• Mutes the object
• Runs away

but that would still not insure you're getting what you want

 

[Monica Balut]

Thank you everyone for your suggestions.

I stuggled with this most of last night and ended up with a method that is most similar to what Darius, Ron and Darkie describe. 

I have a list of notecards which I've created elsewhere that are ones that have the same name as what another object (the installer) proposes to send.  The aim is to allow the user to first delete the existing one or to keep it and have the new one iinstalled with a numerical suffix.

I decided to avoid doing anything that involves state changes since I would lose listens that I count on being there later.

At the end of the function that creates my list of duplcate notecards, I call PocessDupNCList() which looks something like this:

ProcessDupNCList()
{
    if (dupNCList != [])
    {
        AlertABoutDialog(); // tells the user in chat to attend to the dialog
        currentDupNC = llList2String(dupNCList,0);
        dupNCList = llDeleteSubList(dupNCList,0,0);
        llDialog(owner,"The installer wants to install a notecard named " + currentDupNC + " but one by that name is already in the object.  What should we do with the notecard in the object?  (Clicking on Ignore will abort the installation.)",["Delete it","Keep it"],INSTALLCHANNEL);
    }
    else
    {
        currentDupNC = "";
        FinalReview();
    }
}

then in my listen event I have code that looks like this:

...

                if (message == "Delete it")
                {
                    delNCList = delNCList + currentDupNC;
                    ProcessDupNCList();
                }
                else if (message == "Keep it")
                {
                    keepNCList = keepNCList + currentDupNC;
                    ProcessDupNCList();
                }

So, it only goes on to the next item in the list if one of those two buttons is pressed.

To deal with the Ignore, I set up a timer.  When it times out, I just reset everything.

Hitting ignore effectively aborts the process and prevents the code from going to the final review and installation.  If the user were to restart this process, all the variables would be reset to their orighinal values.