Textbox

[davidk64]

 textbox #hndl.txt, 20, 10, 260, 25

 button #hndl, "OK", [titleGraph], LR, 5, 0

 WindowWidth = 350 : WindowHeight = 90

 open "What do you want to name this graph?" for window_nf as #hndl

 print #hndl.txt, "untitled"

 wait



[titleGraph]

 print #hndl.txt, "!contents?"

 input #hndl.txt, graphTitle$

 notice "The title for your graph is: "; graphTitle$

 close #hndl

 end




When I run this code from Textbox help file in debugger a variable is listed after stepping past textbox command:

nullName$ = ""

nothing gets assigned to it. Just wondering what it is?

[plus]

Don't recall using input to get contents from textbox usually for me it's like this:
 textbox #hndl.txt, 20, 10, 260, 25

 button #hndl, "OK", [titleGraph], LR, 5, 0

 WindowWidth = 350 : WindowHeight = 90

 open "What do you want to name this graph?" for window_nf as #hndl

 print #hndl.txt, "untitled"

 wait



[titleGraph]

 print #hndl.txt, "!contents? graphTitle$"

 'input #hndl.txt, graphTitle$

 notice "The title for your graph is: "; graphTitle$

 close #hndl

 end


Is that code from the Help files?

[davidk64]

Yes the code is from the Textbox command help page.

From the tutorial "Adding an Entry Field with TEXTBOX" you get:


Now look at how we changed the code after our [okClicked] branch label. Instead of just displaying the same message every time it displays the text in our textbox control. We accomplish this by printing a command to the textbox with the line:

   print #myFirst.field, "!contents? aString$"

This tells Just BASIC that we want to put the contents of that textbox control into the variable named aString$. We could also have written this as two separate PRINT and INPUT statements as follows, and you may see other Just BASIC programs which do it this way:

   print #myFirst.field, "!contents?"
   input #myFirst.field, aString$


[davidk64]

Actually I like the one line version better. I'm assuming the two line version is making use of a hidden variable that stores the content of the text box when the !contents? command is run and then that hidden variable is accessed when the second line executes. I haven't tried it but guessing you could change contents of textbox between first and second line and you would still see original contents in aString$

[honkytonk]

"input" is for dialogue with the program
"textbox" is for entering data (associate with "Ok" or "Valide" button)
"input" or "textbox", you have to choose.

[davidk64]

So just to clarify. My original question is about the nullName$ variable that appears when you step through the first line of the sample code. Nothing to do with the subsequent discussion about use of !contents? command (in 2 lines or 1) - at least I don't think so!

[plus]

print #hndl.txt, "!contents?"


Yes! nullName$ means you did not list a variable name to store the textBox contents into.

That is one weird sample out of Help files. BTW you don't have to print handle#, print is just extra typing!

[tsh73]

I think two lines variant is a remain of much older version of JB (actually LB)
And kept for compatibility sake
(and again, if it's aint't broken...)

Yes! nullName$ means you did not list a variable name to store the textBox contents into.

Looks like it.
Just details of realisation shine through ;)

[davidk64]

Sorry you haven't convinced me!

If I comment out the 3 lines in [titleGraph] (so the compiler isn't expecting me to use !contents? command) and then step through using debugger after the first line where textbox is declared the nullName$ still pops up in the variable list. Also there is no mention in Textbox command help topic about having to specify a variable name for use with !contents? when you declare the textbox.

My observation is it doesn't matter whether you use !contents? (in either form) or not at all. It makes no difference - you still see the nullName$ variable appear when stepping through the textbox command in the debugger and it is always stays set to "".

Maybe this is one only the developer can answer

[Rod]

In the past program flow was a little different. Then you had to have a “mop up” variable immediately after the “fetch” event. Now it is all seamless and the interpreter can fill any given variable in the statement line.

The variable itself is listed simply because the compiler finds it.

The help file has a lot of little quirks like this as Liberty has evolved over time and while key parts of the help file have been updated threads that run through the rest of it have not.

We did attempt to build a live help file where issues such as this could be corrected or at least commented but we lost that resource.