Problem with llTextBox

I used
llTextBox( key avatar, string message, integer chat_channel );
in a script and tested it and it was ok. Later I discovered that it only worked properly when I used Emerald, with the SL client I didnt get any box for input only a button with the text !!textbox!! and if I hit that button the same text is sent.

I tested with the script I found in LSL Wiki and it worked in the same way.

I know that this function is preliminary so I have maybe to accept this fact. But have anyone an idea of using some other functions doing some similar. Or do I have to use chat to get the input. No I good way I think.

Is chat the only way to get a message of a more free form into a script?

/Perl

Yes, until they finish support for llTextBox, chat is going to be your only option that I'm aware of. I guess I should never say "only", you could make a webpage interface outside of SL that would connect to your LSL script and send a text string that way, but this would probably be overkill for most applications.

Afraid so. We've been waiting for llTextBox for a long time. It's not likely to be implemented in the standard viewer for quite a while, although Emerald has it, as you discovered. When I've needed to get user input, I've used something like this..

integer handle;
default
{
     touch_start(integer num)
     {
          handle = llListen(0,"",llDetectedKey(0),"");
          llSay(0, "Please type your message in chat now.");
          llSetTimerEvent(30);
     }

     listen(integer channel, string name, key id, string msg)
     {
          llSay(0,llKey2Name(id) + ", you just said, \"" + msg + ".\" ");
          llSetTimerEvent(0);
          llListenRemove(handle);
     }

     timer()
     {
          llSay(0, "Sorry, I did not hear a message.");
          llListenRemove(handle);
          llSetTimerEvent(0);
     }
}

It's clunky, but it's all we can do without llTextBox.

Can you detect if a user is using Emerald?
if (client == "Emerald"LLTextBox()
else chatterbox

Emerald can detect it lol..but not the LL client I don't think. You could ask the question though, with the first llDialog, and then use llTextbox or the crappy chat way, depending on their answer.

emerald puts out quite a bit of chatter (some of which can be turned off) on some preset channels... like the sim radar function, so that might be one way. another possibility I haven't explored is checking via RLV commands, which may have something that will allow you to tell it from a plain RLV client.

Yes, this will work if it is enabled, Emerald uses RLVa rather than RLV and will report this if queried with an @version command.

Is RLV enabled by default?

No

Edit: Thinking about this I'm not sure it's of much use unless you are in an area where tyou would expect RLV to be used. RLV relys on llOwnerSay commands, but if you are the owner of the object you already know if your on Emerald. To find out if someone else is useing it they would not only have to have RLV enabled but would also have to be wearing a relay.

Yeah, RLV defaults off, all the Emerald chatter can be switched off, and there are viewer versions that send the same chat streams but don't do llTextBox.

would llDialog() be an alternative maybe? As long as llTextBox is not working properly?

good idea, use a positive channel, and instruct the user to type their input with the format: /< channel > input

But its not possible to input Messages only answers using disitnct buttons? So it will not help me at all.

But I have found a way to use a webpage instead. First I det an URL then I send a webpage with a form. The result from the form will be sent to the URL with a GET. And then its possible to read the requested parameters.

One thing that is anoying is that when I use the webpresentation in the client is rather slow and its a bit difficult to input thing to the form. It works but is slow and the cursor isnt shown properly in the fields for the parameters.

But if you use the external webbrowser then its working OK.

Do you know why the internal webbrowser is so slow handling forms? Can you improve that in some way?

Perl, I think you missed Void's solution. There's nothing you can do with llTextBox() that we can't already do.

In your case, you can send a regular llDialog() which prompts the user to type input into regular chat. If you'd like for them to use a private /# channel, then prompt them to type on that channel. Include an "Okay" button just so the user has something to click instead of "ignore".

In your script, don't listen to the llDialog() channel at all, focus your llListen() on the individual avatar and the channel you request for their text input.

llTextBox() does nearly the same thing as above, only the person has to type into the little text-field on the blue pop-up, rather than the regular chat-entry field.

the point was, that if you don't expect a preset response (otherwise you'd just be using a normal dialog) you can still achieve it outside of textbox by using normal chat function.

I used something similar for the setup of a project from a ways back... the dialog presented some preset choices and a "make your own" button that when pressed opened a listen for the next item typed by that av (it used public chat for ease, but it could just as easily have used a different channel)

it's not as pretty as a textbox, but it's cleaner than dealing with an outside web resource for data that doesn't need to be stored and transmited over the web.

Exactly. That was what I suggested in my post earlier in this thread. You don't need to use a Dialog box to initiate the chat input. Anything that triggers a prompt for the user to type something will do the trick. I suggested a touch_start event, but it could be anything. Typing in chat isn't as pretty as typing in a text box, maybe, but it gets the job done. You just have to take steps to assure that the listen event won't respond to anyone but the user and that the listen handle is closed once you're done with it, especially if you're using the public chat channel.

I have understood this and made an implementation based on the chat using channel 99. Its ok but not so nice.

Instead I have implemented a solution using an webpage. I request an URL. After that I send a llLoadURL to a php script and includes the URL I got as one of the parameters. The PHP script will open a form with fields for the desired inputs. At submit the parameters will be sent to the LSL script which can interprete the result.

When I have tested it, it works well both with internal and external web browser using a PC . But when I do the same with a MAC I have some problems with the internal web browser. It is slow and its not showing the cursor in the input fields in a proper way.

Any ideas of what the reason can be?

Yes I understood the way to use as you call it a normal dialog. I used that and channel 99. It works ok but not so nice..

That is why I as I said earlier instead developed a solution using a webpage with a form for input. Its a form with several fields. This solutions works well.

Except for internal browser when I am using Mac. Then its slow and you cant see the cusor in the fields of the form. Have you used web forms and have you seen the bad performance with the internal webbrowser for Mac. And in that case do you know any way to make the experience better.

something made for the general public doesn't work on a Mac properly... color me surprised ::wipes sarcasm off screen::

mac and linux support are always kinda iffy in SL (linux support being the worst). you can try recoding your web page, but failing that, a note to mac users is about the best you can do in that situation

The internal browser experience gets way better with the media API. It's anyone's guess when that will finally make its way into the standard viewer, or when there will be a new version of the standard viewer at all.

Yes I will give a hint to the Mac users. It they use the external webbrowser it works ok. And the internal is also working in the way that you can input parameters in the fields and submit the form and get the correct result.

The only thing that seems a bit odd is that you cant see any cursor in the fields when you tab or click in the field. And it is rather slow.

Its the same for both the SL browser and the Emerald browser.

As there's no way to distinguish the input from a dialog box and regular chat made by the same user the second listen isn't necessary. Just have the user input their message on the same channel specified by llDialog.

not always possible if you normally use negative channels (for various reasons)... avatars can't speak on negative channels except as a result of a dialog

Hmph. The problem here is not with the Mac per se, but with SL's implementation of the browser API in the SL client. I'm not sure what they're using (Safari is the most common) but it sounds like they have simply forgotten a focus instruction. Because it works in an external browser, the issue has got to be the SL integration code.

BTW, I've written an awful lot of web pages for the general public that work on any OS.

web pages are fairly easy to cross code... (I was taking a pot shot at Mac's general incompatibility with the larger software market, not your web page)