Can you call llTextBox from a dialog menu?

[Ciaran Laval]

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?

[Darkie Minotaur]

It should work - does your viewer support the text box?

[Monti Messmer]

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.

[Ciaran Laval]

---

Darkie Minotaur wrote:

It should work - does your viewer support the text box?

---

Yeah I can get a text box to appear from a basic script

[Ciaran Laval]

---

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.

[Darkie Minotaur]

Could you paste the code that doesn't work - I expect it's something else.

[Ciaran Laval]

     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");
            }
        }
    }     

[Darkie Minotaur]

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

[Ciaran Laval]

---

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.

[PeterCanessa Oh]

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

[Ciaran Laval]

Thanks again.

[Void Singer]

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.

[Ciaran Laval]

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.

 

[Void Singer]

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....

[Ciaran Laval]

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.



[Void Singer]

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.

[Ciaran Laval]

Thanks very much Void, you pointed me in the right direction without battering me about the face and made me work through it so I understood what was going on, that's much appreciated.

[Void Singer]

honestly I didn't think to double check the code you'd posted, as I was guessing you'd updated from that, but I do try to make people work for it a bit, for just that reason... once you change it, you own it so to speak