Talk:LlDialog

Telling an end user that the max length of a button label is 24 bytes ... well, not overly helpful. But there is the problem of what what characters translate to how many bytes. Still, is there any way we can give examples of characters?

Chaz Longstaff 05:18, 27 November 2009 (UTC)

Can you use a function like this to find long strings? Then the user will not have to guess what button is bad Somebody check my work please, I am sleepy as always.

<lsl>integer GetStringBytes(string s) {

   list chopped = llParseString2List(llEscapeURL("*" + s), ["%"], []);
   return llStringLength((string)chopped) - llGetListLength(chopped) - 1;

}</lsl>

--Cerise Sorbet 10:03, 27 November 2009 (UTC)

I was too sleepy. Maybe this time. --Cerise Sorbet 11:06, 27 November 2009 (UTC)

Maybe this one will be more nice to memory? --Cerise Sorbet 13:03, 27 November 2009 (UTC)

<lsl>integer GetStringBytes2(string s) {

   s = llEscapeURL(s);
   integer i = 0;
   integer j;
   for (j = llStringLength(s); j > -1; j--)
       i += (llGetSubString(s, j, j) == "%");
   return llStringLength(s) - i - i;

}</lsl>

---

Strife, Chaz here. Most ordinary users in SL, and most user documentation in SL, refer to dialog boxes in SL as menus. While that may be as technically inaccurate as referring to a tomato as a vegetable, people don't look for tomatoes in between the apples and bananas at their green grocer (grin), and they are going to come here looking for info on menus, not dialogue boxes. I think we need to at least acknowledge the word menu, even if we do correct them about its usage right away. (I also dislike how people use the word less when they should be using fewer, but that is also just the way it is, sadly :} )Chaz Longstaff 18:17, 15 July 2008 (PDT)

Very good point. I'll also keep a lookout for improper uses of "less". -- Strife Onizuka 18:32, 15 July 2008 (PDT)

The Wiki mentions that clicking on a button causes the value to be chatted on the specified channel, but doesn't clarify whether it's simply said(llSay) or shouted(llShout). It does mention that errors will be shouted on the Debug Channel, but I think it's important to clarify this within the Wiki. --Deimos Damone

I have reworded the applicable caveat to clarify the functionality. -- Strife ^{(talk|contribs)} 11:49, 15 October 2008 (PDT)

It may be worth including some explicit explanation of the difference between bytes and unicode characters, especially since the inworld error messages somewhat ambiguously talk about characters, when in fact referring to bytes. -- Tali Rosca 10:45, 15 October 2008 (PDT)

Many functions use byte limits and not character limits. I think it would be better to make the word "byte" a link to a (new?) subsection of the string article where that can be better addressed. It would be inappropriate to duplicate this information on multiple articles, it would end up clogging the articles. That said, I'll try to find the best method for presenting this information; as you point out the current caveat is inadequate and more information is needed. -- Strife ^{(talk|contribs)} 11:49, 15 October 2008 (PDT)

I agree that the actual explanation shouldn't be here, but a link should be fairly prominent, since this is the most likely place people will run into the difference. Tali Rosca 12:03, 15 October 2008 (PDT)

Multiple dialogs tips

It may worth mention in tips.

Sending multiple dialogs in a row to one avatar may be inappropriate. In old viewer it creates stack of messages in notification area, which complicates reading other things. In viewer version 2 (as of 16/Sep/2010) newer dialogs replace unanswered dialogs from the same object, so any information and chance to react is lost.

If you need to present more than 12 options, add buttons for browsing option pages (see SimpleDialogMenuSystem).

If dialogs are not requested by user, but rather are triggered by some events, you may want to either queue further events or discard them until the first dialog will be answered, or at least throttle them. In any case, if you are sending many dialogs, there should be an option to stop them. (Making user mute your object is bad because he may then forget to unmute it when he will want to interact with the object again).

If you just need to report something that does not require an answer, consider using other means of communication. Though, you may still want to send one dialog to draw user's attention.

Wicked Winslet 12:25, 16 September 2010 (UTC)

Example

the first example is very likely to stop working over time with a "too many listens" error in a multi-user environment. Cause: any user that clicks on the object will generate a new listen handle, but only the last one is saved, so only the last one is closed. any user (including the current) that touches the prim before the current user has clicked on a dialog response (or within 60seconds if they do not, or click cancel on the dialog) will cause the current open listen handle to advance, and the previous one will never be closed.
-- Void ^{(talk|contribs)} 12:03, 13 January 2013 (PST)

I suspect the prim will have died long before that LOL. But you have a point Omei Qunhua 13:47, 13 January 2013 (PST)

In fact it would have to be clicked by 65 different users all choosing to ignore the dialog. A subsequent listen using the same filters as a previous is assigned to the same handle. (Thanks Pedro and Innula) Omei Qunhua 10:30, 14 January 2013 (PST)

Also in the first example, the call to llDialog() happens before the listen is created. In my experience it's possible for this to result in a situation where the dialog is shown to the user and, if they click fast enough, the reply is lost. Might it be a good idea to do it the other way round? Antony Fairport 05:29, 16 January 2013 (PST)

Wow, you type fast! I couldn't even move my mouse onto the dialog window that fast. Anyway I changed it. Example #2 had the same remote possibility of accumulating active listeners, I believe. Omei Qunhua 08:10, 16 January 2013 (PST)

Admittedly it's unlikely to be an issue with that actual example but it's possible that a dialog that spawns a dialog that spawns a dialog... (etc) will have someone camping on a button and a reply can get missed. So I was just thinking it might be an idea to encourage starting the listen fist. Antony Fairport 08:25, 16 January 2013 (PST)

Where's order_buttons?

Didn't there used to be an example of that very useful helper function, order_buttons(), on this page? Unless there was a particular reason for removing it, I think it would be good to have it back. Innula Zenovka 11:27, 18 February 2013 (PST)

It's back, a name collision hid it. --ObviousAltIsObvious Resident 12:11, 18 February 2013 (PST)

Fundamental flaw in first code sample (fails to remove multiple listeners)

The first code sample has the following fundamental problem (as can be easily demonstrated): at any point in time there can be multiple listeners attached because any number of users can click on the prim. But the script sample has only one global variable to keep track of it. Result: The last user to click on the prim "wins" in the sense that whoever closes the dialog first will remove his listener. All other listeners will remain active.

The obvious mediation is

1. either to introduce a more sophisticated listener tracking (and most likely some form of polling in a regular timer event)
2. or to keep it simple and introduce a single static listener, omitting the need for a timer event altogether.

I personally opt for the latter. If there are no objections I can make those changes. Proposal:

<lsl> // When the prim is touched, give the toucher the option of killing the prim.

integer gListener; // Identity of the listener associated with the dialog, so we can clean up when not needed

default {

   state_entry()
   {

// Set up a listener for potential llDialog() calls

       // it might seem like a waste at this stage, but overall it is way more efficient

// than trying to track listeners on a per-user basis

       gListener = llListen(-99, "", NULL_KEY, "");
   }

   touch_start(integer total_number)
   {
       // get the UUID of the person touching this prim
       key user = llDetectedKey(0);
       // Send a dialog to that person. We'll use a fixed negative channel number for simplicity
       llDialog(user, "\nDo you wish this prim to die?", ["Yes", "No" ] , -99);
   }
   listen(integer chan, string name, key id, string msg)
   {
       // If the user clicked the "Yes" button, kill this prim.
       if (msg == "Yes")
           llDie();
   }

} </lsl>

Btw, the same fundamental flaw is present in the tutorial https://wiki.secondlife.com/wiki/Dialog_Menus .

Edit: the second code sample contains the flaw, too

--LovingAndRejected Resident 05:37, 13 November 2013 (PST)