Jump to content

Can you call llTextBox from a dialog menu?


Ciaran Laval
 Share

You are about to reply to a thread that has been inactive for 4817 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I've been piddling about with a script for hours and started to go cross eyed, anyway I had the bright idea to call llTextBox from the listen section via a menu button, but nothing happens. I know the menu button works because I added a llOwnerSay message to check it, but the llTextBox command isn't being invoked at all.

So, can llTextBox be called this way?

Link to comment
Share on other sites


Monti Messmer wrote:

Isn´t this the same like calling a submenu ? You need to stop the listener start it new before call the textbox ?

Something like this gave me a headache long ago but i can´t remember the exact problem/solution.

I'll give that a whirl.

Link to comment
Share on other sites

     listen(integer CHANNEL, string name, key id, string message)
    {
        if (llListFindList(MENU_MAIN, [message]) != -1)  // verify dialog choice
        {

            if (message == "Reset")
            {
                llResetScript();
            }
   
            else if (message == "Update Price")
            {
                setVendorSettings();
                llOwnerSay("Price has been updated to " + (string)vPrice);
                llOwnerSay("Description 2 = " + description2);
            }
               
            else if (message == "Set Price")
            {

                llTextBox(llDetectedKey(0),"Write something here...",CHANNEL);
            llOwnerSay("The Price is Right");
            }
        }
    }     

Link to comment
Share on other sites


Darkie Minotaur wrote:

That was an obvious one: llDetectedKey does not work in the listen  event - use id

Thank you very much :matte-motes-grin:

I didn't realise llDetectedKey doesn't work in a listen event, I must never have tried to use it before in one, then again this is the first time I've tried to use llTextBox too.

Ah with you now, id isn't llDetectedKey.

Link to comment
Share on other sites

From the wiki: "llDetected* functions only work if called from within Detection events (collision, collision_start, collision_end, sensor, touch, touch_start, touch_end) or in functions called by Detection events."

Those events have a parameter of how many 'things' were detected so you use the ''Detected*" functions to choose the one you work on.  Listen fires for every message so it already has the ID as a parameter

Link to comment
Share on other sites

and unfortunately, while you can call llDetected* from a function, that limits the function to only running from events that support it... LSL will throw a compile error if you try the same with a variable name (like ID) so the only solution there is to have the function take a variable and explicitly pass it either llDetected* or your variable in the call to the function.

Link to comment
Share on other sites

Ok stuck again, llTextBox now appears, which is fine but I can't do anything with it:

 else if (message == "Set Price")
            {
                llTextBox(id,message,CHANNEL);
                // do something for goodness sake;
               
            }

No matter what I try and do, even if I make an if statement to do something with the message I type into llTextBox, nothing happens.

The only way I've been able to get it to work is to go to a new state and touch the prim again, which wasn't what I was hoping for.

I feel like I''m missing a trick here.

 

Link to comment
Share on other sites

text box works a lot like a dialog button... whatever is typed into the textbox gets said by the avatar that received it, on the channel that was specified (the only was for an avatar to effectively chat on a negative channel).... you then need to catch what is said in your listen event, just as you do for a dialog, only with this, the text could be anything the user typed....

Link to comment
Share on other sites

Found the problem:

if (llListFindList(MENU_MAIN, [message]) != -1)  // verify dialog choice

Moral of the story is to not set your dialog choices to the menu when you want input other than the dialog choices! Hours this has taken me! All good though, I won't make that mistake again and it's a good learning exercise.

On the other hand it exemplifies how well dialog limiting works, it worked an absolute treat.



Link to comment
Share on other sites

lol, it may help in the future to use a different channel for your textbox, then have the logic switch in the listen based on the channel. if you use a negative channel for the text box, you can probably even leave it open as long as it's filtered to the user.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4817 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...