Second Life Forums Archive - llTextBoxDialog - llDialog with no buttons, but a text box

Jiminy Roo

Registered User

Join date: 25 Dec 2004

Posts: 42

01-04-2007 14:47

Hi There,
I was thinking about all of the dialog-driven interfaces out there, and I think this command would make these interfaces alot easier to navigate. Rather than the user having to manually enter data via chat on specified channels (hard to do for new people, and drastically makes the interface harder to use), a dialog would come up. On Clicking 'OK' the typed input would be said on the specified channel. ie-

llTextBoxDialog(key agent, string message, integer channel);

I would imagine this kind of interface would be very easy to implement (other kinds of dialog contain text boxes, and the method of simulating chat like llDialog does would be easily copyable.

Here is an example of what I mean:

Possible Additions:
A 'Default String' Which is Entered into the text box, but pre-highlighted so it is easy to type over

Any thoughts or comments, spew them out!

Thanks

Jacques Groshomme

Registered User

Join date: 16 Mar 2005

Posts: 355

01-04-2007 15:40

This has already been proposed and discussed. It currently has 81 votes. Please add more.

Proposal #2448:
http://secondlife.com/vote/vote.php?get_id=2448

Discussion Thread:
/13/3e/152183/1.html

Zi Ree

Mrrrew!

Join date: 25 Feb 2006

Posts: 723

01-04-2007 23:30

_____________________

Zi!

(SuSE Linux 10.2, Kernel 2.6.13-15, AMD64 3200+, 2GB RAM, NVidia GeForce 7800GS 512MB (AGP), KDE 3.5.5, Second Life 1.13.1 (6) alpha soon beta thingie)

Blog: http://ziree.wordpress.com/ - QAvimator: http://qavimator.org

Second Life Linux Users Group IRC Channel: irc.freenode.org #secondlifelug

Jacques Groshomme

Registered User

Join date: 16 Mar 2005

Posts: 355

01-05-2007 09:09

I think that adding text is a major enough departure from the current llDialog() function that it should qualify as its own function. This would also prevent accidental breakage of current scripts.

Argent Stonecutter

Emergency Mustelid

Join date: 20 Sep 2005

Posts: 20,263

llHTMLDialog

01-05-2007 09:41

At the very least it needs to be something like "llDialogExtended".

Given the way LL is pushing HTML, it occurred to me that it might be worthwhile to define an HTML dialog call. Making it HTML rather than XML would allow people to use existing HTML page creation tools to lay out their dialogs.

llHTMLDialog(integer channel,string title, string HTML,key agent,integer id);

HTML is either the name of a notecard containing the HTML, or a valid HTML body starting with "<BODY>", ending in "</BODY>", and containing at least one "<FORM>" tag. The leading "<" would distinguish the two cases.

When the user clicks on an <INPUT TYPE=SUBMIT> button in the dialog, then they chat on the specified channel a line containing the encoded "GET" response.

llHTMLRemove(integer id);

If a non-zero id was provided in llHTMLDialog, then the dialog window would remain for additional llHTMLDialog calls until llHTMLRemove was called or the user closed the window.

list llResponseToList(string response);

Converts "a=foo&b=bar" to a list ['a', 'foo', 'b', 'bar'].

string llList2Response(list l);

Reverses the above conversion.

The dialog should probably ignore explicit external URIs, javascript, multiple <form> sections, and more than minimal layout.

Haravikk Mistral

Registered User

Join date: 8 Oct 2005

Posts: 2,482

01-05-2007 09:59

Hmm, while HTML would be nice and all, I still don't see what the big deal would be in giving us constants to use as buttons, thereby allowing us to build simple rudimentary interfaces using llDialog as it is. These could even behave like llSetPrimitiveParams(), ie after a constant it expects X extra values, any excess strings after a constant are considered to be buttons (thus current dialogs are unaffected).

e.g:

CODE

llDialog(llGetOwner(), "Please enter the username and password you created for your object", [DIALOG_TEXTBOX, "Enter username", DIALOG_PASSWORD, "password", DIALOG_CHECKBOX, "Remember me in future", "Login"], -12345);

Results are returned as a comma seperated list in the message part of the listen. Possibly with the button that was pressed first, since this will be commonly used to determine what action is being performed and thus what data is expected.

I am however all in favour of just replacing llDialog with a new function (and having new scripts compile with this instead and a warning if you are saving changes to an existing script with llDialog in it). Removing the use of listens since they are redundant as the info goes direct to the object, and having a dialog() event, in which the results could be returned as a list instead, which would be much easier to work with than having the dialog converted into a string only to need to be broken apart again.

_____________________

Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon
10gb DDR2 800mhz FB-DIMMS
4 x 750gb, 32mb cache hard-drives (RAID-0/striped)
NVidia GeForce 8800GT (512mb)

llTextBoxDialog - llDialog with no buttons, but a text box
Jiminy Roo Registered User Join date: 25 Dec 2004 Posts: 42	01-04-2007 14:47 Hi There, I was thinking about all of the dialog-driven interfaces out there, and I think this command would make these interfaces alot easier to navigate. Rather than the user having to manually enter data via chat on specified channels (hard to do for new people, and drastically makes the interface harder to use), a dialog would come up. On Clicking 'OK' the typed input would be said on the specified channel. ie- llTextBoxDialog(key agent, string message, integer channel); I would imagine this kind of interface would be very easy to implement (other kinds of dialog contain text boxes, and the method of simulating chat like llDialog does would be easily copyable. Here is an example of what I mean: Possible Additions: A 'Default String' Which is Entered into the text box, but pre-highlighted so it is easy to type over Any thoughts or comments, spew them out! Thanks
Jacques Groshomme Registered User Join date: 16 Mar 2005 Posts: 355	01-04-2007 15:40 This has already been proposed and discussed. It currently has 81 votes. Please add more. Proposal #2448: http://secondlife.com/vote/vote.php?get_id=2448 Discussion Thread: /13/3e/152183/1.html
Zi Ree Mrrrew! Join date: 25 Feb 2006 Posts: 723	01-04-2007 23:30 See also here: http://secondlife.com/vote/vote.php?get_id=1385 http://secondlife.com/vote/vote.php?get_id=1019 /13/dd/106965/1.html _____________________ Zi! (SuSE Linux 10.2, Kernel 2.6.13-15, AMD64 3200+, 2GB RAM, NVidia GeForce 7800GS 512MB (AGP), KDE 3.5.5, Second Life 1.13.1 (6) alpha soon beta thingie) Blog: http://ziree.wordpress.com/ - QAvimator: http://qavimator.org Second Life Linux Users Group IRC Channel: irc.freenode.org #secondlifelug
Jacques Groshomme Registered User Join date: 16 Mar 2005 Posts: 355	01-05-2007 09:09 I think that adding text is a major enough departure from the current llDialog() function that it should qualify as its own function. This would also prevent accidental breakage of current scripts.
Argent Stonecutter Emergency Mustelid Join date: 20 Sep 2005 Posts: 20,263	llHTMLDialog 01-05-2007 09:41 At the very least it needs to be something like "llDialogExtended". Given the way LL is pushing HTML, it occurred to me that it might be worthwhile to define an HTML dialog call. Making it HTML rather than XML would allow people to use existing HTML page creation tools to lay out their dialogs. llHTMLDialog(integer channel,string title, string HTML,key agent,integer id); HTML is either the name of a notecard containing the HTML, or a valid HTML body starting with "<BODY>", ending in "</BODY>", and containing at least one "<FORM>" tag. The leading "<" would distinguish the two cases. When the user clicks on an <INPUT TYPE=SUBMIT> button in the dialog, then they chat on the specified channel a line containing the encoded "GET" response. llHTMLRemove(integer id); If a non-zero id was provided in llHTMLDialog, then the dialog window would remain for additional llHTMLDialog calls until llHTMLRemove was called or the user closed the window. list llResponseToList(string response); Converts "a=foo&b=bar" to a list ['a', 'foo', 'b', 'bar']. string llList2Response(list l); Reverses the above conversion. The dialog should probably ignore explicit external URIs, javascript, multiple <form> sections, and more than minimal layout.
Haravikk Mistral Registered User Join date: 8 Oct 2005 Posts: 2,482	01-05-2007 09:59 Hmm, while HTML would be nice and all, I still don't see what the big deal would be in giving us constants to use as buttons, thereby allowing us to build simple rudimentary interfaces using llDialog as it is. These could even behave like llSetPrimitiveParams(), ie after a constant it expects X extra values, any excess strings after a constant are considered to be buttons (thus current dialogs are unaffected). e.g: CODE llDialog(llGetOwner(), "Please enter the username and password you created for your object", [DIALOG_TEXTBOX, "Enter username", DIALOG_PASSWORD, "password", DIALOG_CHECKBOX, "Remember me in future", "Login"], -12345); Results are returned as a comma seperated list in the message part of the listen. Possibly with the button that was pressed first, since this will be commonly used to determine what action is being performed and thus what data is expected. I am however all in favour of just replacing llDialog with a new function (and having new scripts compile with this instead and a warning if you are saving changes to an existing script with llDialog in it). Removing the use of listens since they are redundant as the info goes direct to the object, and having a dialog() event, in which the results could be returned as a list instead, which would be much easier to work with than having the dialog converted into a string only to need to be broken apart again. _____________________ Computer (Mac Pro): 2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb)

Welcome to the Second Life Forums Archive

llTextBoxDialog - llDialog with no buttons, but a text box