Talk:Dialog Menus

okay, get busy Strife :}

(p.s. this is aimed solidly at learners) Chaz Longstaff 18:56, 17 July 2008 (PDT)

It makes my skin crawl to see the dialog bog described as a menu and today I finally figured out why. Menus and dialog boxes have different user & programmer expectations. It will be better if I tell you what happened. This morning a friend who is a new scripter approached me asking for some scripting help, they were making a menuing system and it just wasn't working properly and they couldn't spot the problem. They were trying to make a menu system that looked like this tree:

• Base Menu
  • Left
    • One
    • Two
    • Three
    • Four
  • Right
    • One
    • Two
    • Three
    • Four

The base dialog had two buttons, Left and Right, each of those subsequently spawned dialogs had four buttons. The Left and Right dialog's buttons were the same. So their listen code looked something like this: <lsl>listen(integer chan, string user, key id, string msg){

   integer button;
   if(msg == "Left")
       SpawnLeft(id);
   else if(msg == "Right")
       SpawnRight(id);
   else if(~llListFindList(LeftButtons, [msg]))
       DoLeft(msg);
   else if(~llListFindList(RightButtons, [msg]))
       DoRight(msg);

}</lsl> Can you spot the problem my friend was having? If you guessed that when they went into the Right menu that it executed the actions as if they were in the Left menu, you guessed right. My friend hadn't kept track of the context and so it came back to bite her since the buttons of the Left and Right boxes were the same.

It is common in the Menu APIs that they handle the context tracking, it automatically avoids any collision problems that might arise. The expectation is that it handle this sort of thing.

I think that calling the SL dialog box a menu encourages the belief that the context will automatically be tracked. In SL tracking is left up to the user and for a multi-user menu script it can be quite difficult to get right. For a beginners there is going to be a steep learning curve, and if you call it a menu the first thing they will have to learn is that it behaves nothing like a menu, that it behaves exactly like a dialog box; if they treat it like a menu, they will just waste their time and patience trying to work out why it isn't working like a menu.

Given todays incite, I think it does more harm then good to call a dialog box a menu. The scripter needs to be aware of what they need to do to make the script work the way they want it to and I don't think this helps things.

P.S. This article will likely end up being rather long considering that the target audience is newbies; there is quite a bit of glue code that needs to be displayed and explained. Dialog menus I suspect may be a bit to complicated for the newest of scripters to easily master. I think of them as more of an Intermediate topic. -- Strife Onizuka 22:23, 17 July 2008 (PDT)

DialogMenus Tutorial Piece

(moved here from my talk page)

Hey Strife, you wrote: "I'm not sure it should (or should not) be in the base LSL category."

Given that I can't even figure out how to find where you wrote that and respond directly there (it's not showing up in that page's discussion when I open the discussion, thus responding here, hehe), can I leave it up to you where / how to categorize? You know your filing system best, and I say, stick with it. Bottom line is that wherever it is filed, we can link people to it, right? Chaz Longstaff 21:38, 17 July 2008 (PDT)

It's currently in Communications, my thought was that I didn't want to pollute the base category. But then I really don't want to pollute the function categories... so I really don't think my wants in this case are realistic. -- Strife Onizuka 22:26, 17 July 2008 (PDT)

I'm not really sure if Communications is the right place for it, will have to do until inspiration strikes. Maybe in the Dialog cat instead or too?