Talk:LlTextBox

Channels and Listeners

The first example uses a constant negative channel for simplicity. One way to make the channel hard to guess (less prone to misuse / cross-talk) is to compute a negative channel based on the object UUID:- <lsl>

   integer channel = 0x80000000 | (integer) ( (string) llGetKey() );

</lsl>

The same example doesn't bother to remove the listener in the event that the user clicks the "ignore" button. Yes this will leave a rare-channel listener open (which will be almost lag-neutral) but the listener will be removed the next time a user DOES respond correctly to the text box. The fact that the llListen always uses the same channel, and the same set of filters, means that a subsequent llListen() call will utilise the same listener, if one is already open. There will be no accumulation of open listeners, and the script will not be open to eventual crashing due to such an eventuality.

Omei Qunhua 04:47, 30 December 2013 (PST)

Last I checked (do not ask when that was), you can open multiple listens on the same channel, so the example as it currently stands leaks listeners. I've added the requisite llListenRemove to the touch_start. -- Strife ^{(talk|contribs)} 11:52, 30 December 2013 (PST)

Yes, Strife, you can open multiple listeners on one channel, but ONLY if the filters change in some way. That's why I used no filters. Please read the notes under llListen(). I'm undoing your edit. Omei Qunhua 13:07, 30 December 2013 (PST)

Listeners did leak for most of SL's history, then LL fixed it out of nowhere. So Strife wasn't all wet there. --ObviousAltIsObvious Resident 13:49, 30 December 2013 (PST)

I missed that edit and I pretty much never read the Notes. Handle reuse is handy and scary. It has the potential to break stuff, it really doesn't belong in Notes, it should be in Spec or Caveats. I assume you did original research to find that out. Might have been done around this time. I think I'll go to the next Simulator User Group and asking Kelly and Andrew when this happened (more likely I'll have forgotten about it by next week).-- Strife ^{(talk|contribs)} 20:47, 30 December 2013 (PST)

I would imagine the change fixed far far more scripts than it broke. No? Omei Qunhua 03:54, 31 December 2013 (PST)

Yes. But. <read really fast> It rewards the people who don't bother to read or think and punishes the conscientious. Sure it fixes the scripts of the lazy masses and breaks the scripts of the intelligent few but <pause to breath> at least the intelligent folks are smart enough to work around the change<return to normal speed>. While I disapprove on principal, on usability grounds it's a good thing and it saves server resources; so I approve of the change. I just really really wish they had told someone. -- Strife ^{(talk|contribs)} 21:44, 31 December 2013 (PST)

---

---

Interesting enough, when I try to use this method on the main grid, I get a dialog with a button that says !!llTextBox!! - I wonder if it will be possible to combine buttons with a text box in the future on dialog controls. --Dedric Mauriac 01:34, 28 August 2008 (PDT)

(The reason for this was Dedric was using a client that didn't support llTextBox) -- Strife ^{(talk|contribs)} 20:47, 30 December 2013 (PST)

Has anybody ever seen this work properly?

I have looked back in at this function in the hope that I can use it a few times but to no avail. As I understand it with this function we can produce a kind of form to be filled out and returned by the key user. But all I have ever seen is the !!TextBox!! button. So I just wondered if anyone had ever seen the real text box and where? -- Eddy ^{(talk|contribs)} 05:34, 2 August 2009 (UTC)

And yes I can read. But in fact the pre-release warning reads to me like it does work somewhere and so would like to see it for my self. Ramzi Linden commented when he added the pre-release warning that it is literally pre-release. Surely the warning should read that way too. Anyway, if anyone does know where one might go to see it working could they leave the address? Thanks. -- Eddy ^{(talk|contribs)} 05:43, 2 August 2009 (UTC)

I remember seeing it mentioned in some branch of the viewer source but I couldn't tell you which. -- Strife ^{(talk|contribs)} 11:02, 2 August 2009 (UTC)

Oh god! Not source code again? I'm going to have to learn more stuff aren't I? (rhetorical) -- Eddy ^{(talk|contribs)} 17:55, 2 August 2009 (UTC)

nah, I just take a peak at the changes to see if there is anything interesting coming down the pipe... sometimes I catch errors. -- Strife ^{(talk|contribs)} 11:30, 3 August 2009 (UTC)

I second your "nah" but with the opposite intention. Baring in mind the whole jump jira thing I clearly do need to learn more about programming. What is interesting is that as I learn more about the finer points of lsl I realize that the wiki info I have had trouble understanding is hard because I didn't know any other language before I started lsl. Perhaps something to bare in mind when editing this wiki. When I was looking at scope in variables I found a few references to C and since I don't know C the references were useless. So not only must I learn C/C++ but ask that where possible this wiki can be written with non programmers in mind (a little more) since I now realize why some of it still reads like gibberish. -- Eddy ^{(talk|contribs)} 12:24, 3 August 2009 (UTC)

Live?

Using Emerald 1.32.5.1632 and Second Life Server 1.36.4.202355 this seems to function. Interesting note: the magic token TEXTBOX_MAGIC_TOKEN (aka "!!llTextBox!!") if sent as the first button in a dialog will cause the dialog to come up as a text box, just as llTextBox() sends, losing the rest of the buttons. If it is sent as any other button, it will act as a normal dialog box. Saddly this means no combo-boxes. WhiteFire Sondergaard 02:34, 1 April 2010 (UTC)

That sounds correct. -- Strife ^{(talk|contribs)} 05:39, 2 April 2010 (UTC)

Limitations

It appears the text box implementation of at least 2.6.3 only allows up to 250 characters to be entered into the text field. Sierra Janus 01:24, 16 May 2011 (PDT)