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)