How can I get user input when they run a script and store there inputted value as a variable?
Sounds like you want to use the Set Variable script step for starters.
You can use Jeff's suggestion, and use a global FIELD as an input field. After the user selects "OK", then use a Set Variable script step to set the variable equal to whatever that global field was. It kind of depends on what you need to do with the variable after you gather the information.
Well... These are input fields, not variables!
Is there a way to do this?
My problem is that at the time I execute the "Custom dialog", the table to which I'm pointing is empty, no records. FM just hangs at that instruction...
Is there a solution to this??? FM Pro 11, BTW.
I would personally have a GLOBALS table. In it, I'd create whatever fields I needed. I'd make sure they used global storage. Global fields, because they are global, are available from any context and any table. So, the global input field you're creating can be set from anywhere, including a custom dialog. example: you have a firstname_g field in the GLOBALS table. Custom dialog: "Enter your first name", input field GLOBALS::firstname_g. The user enters a value. Clicks ok. And there you have a value that you can instantly save into a global variable.
Hope that helps.
Storage on the field you use needs to be set to global. Make sure that is set.
global fields can be used and entered with no records, IFRC.
Try it! put a global field on the layout and remove all records. Try to enter data into it. The global may need to be in a part other than Body (I just don't remember for FMP11). Then also try to remove the global field from the layout, but set the field by script. Go to another layout and try to set the field by layout.
Global fields don't have layout or table occurrence context.
You are working with older version, so may need to test.
I tested it in FM14, not "hangs" if there is "cancel" button, but "ok" button does nothing. It is not mentioned in help, how it works when "can't commit", but seems simply ignoring
There is no way to input variables without using field.
You can use any field in some cases.
Enter Find Mode 
Show Custom Dialog [ use any field in the table to input ]
Set Variable [ $var ; field ]
Enter Browse Mode 
Thank you Beverly and dtcgnet! This is even better than sliced bread!
Is there any downside at all to using a "Globals table" with never any records in it? (I just confirmed that even after quitting FM Pro, the last value stored in the global field is still there!)
With this facility, why use global variables at all?
Thanks a million to both of you!
You are working with older version, so may need to test.
Would you believe I have FM Pro 13, just never got around to installing it! And now, 14 is out! Life is pushing too hard on me, I can't run any faster!
There really isn't anything wrong with using a Globals table without any records. You can use the concept for whatever utility fields you might need. It has its places, for sure. In some places, I prefer global variables, and in some I prefer global fields. Global variables can't be used in relationships. Global fields can (with certain exceptions). I hope Beverly weighs in on why she prefers which, and when. I learn a lot from her posts.
Couple of things to remember. In a LOCAL file, the last value stored in a global field will persist. In a SHARED file, that's not necessarily the case. In a SHARED file, if a global field had a value when the file was uploaded to the server, then the value will persist. If a global field is empty when the file is uploaded, it will always be empty when a user first opens the file. If you have 3 globals you'd like to "always load", make sure to provide a record and fill those 3 fields with the value when the file is NOT on the server, then upload it. Usually that's not particulalry practical, so think it through ahead of time when possible. Another alternative is to load the global fields or variables in a startup script.
dtcgnet, you said it well! They both have advantages and disadvantages and I try to use them correctly. I would like the ability to use Variables for dialog input. I don't hope they will be used for relationships as we can with global fields. But that input would be sweet.
I think of global fields as variables before we had variables and plan accordingly to set and unset as needed. I don't like to rely on them being set when I open a file/database, for example, or run a script. I'm pretty explicit on the set/unset process (for both variables and global fields).
One thing I should have added...global fields are parts of tables. Global variables are not. When I set a global variable, or call one, it doesn't cause any records from any tables to be retrieved from or sent to the server. When I use a global FIELD from a table, all the fields in the table are sent from the host to the client.
Beverly can correct me on this if I'm wrong (Hopefully):
If a client requests any field from a table, the entire record is sent. If you have a global field in a table with 300 fields, and you make a call to that global field, then data from 300 fields will be sent from the host to your machine. If a layout is using Form View, records are sent in blocks of 25 records. In the case of List or Table view, as many records as will fit on the screen are sent.
So in that instance, if you reference BIGFatTable::GlobalFieldName, the host will send records from the table called BIGFatTable. On the other hand, if you reference $$GlobalVariableName, the host will not send records from BIGFatTable.
Example of a real-world example: I use global VARIABLES if I want to filter portals instead of global FIELDS. Because the variable is kept in memory, it doesn't need to be re-evaluated as data changes.
Thought of another reason to use one over the other: Once you set a $$ variable, it is kept in memory. When you refer to it again, it's pulled from memory, it doesn't need to be re-evaluated. With a field, FM will evaluate the call every time you call it.
Real world example for Conditional Formatting:
Turn Field A blue if $$Color = "Blue". [FM evaluates Field A and instantly compares it to $$Color.]
Turn Field A blue if global::Color = "Blue". [FM evaluates Field A and globalfieldColor and then compares the two.]
A Variable would provide better performance (VERY small difference, but it's a difference).
Real world example for a complicated calculation example:
Let ( [
calcvalue_1 = global::SomeNumber * 1 ;
calcvalue_2 = global::SomeNumber * 10 ;
calcvalue_3 = global::SomeNumber * 100 ;
calcvalue_4 = global::SomeNumber * 1000
"Times 1: " & calcvalue_1 & "Times 10: " & calcvalue_2 & "Times 100: " & calcvalue_3 & "Times 1000: " & calcvalue 4
FM would have to evaluate the value of global::SomeNumber 4 separate times because that field is called 4 times. If "global::SomeNumber" was replaced with "$$SomeNumber" in the above example, then $$SomeNumber would only have to be evaluated once. Set $$SomeNumber to what you want, then use it in the calculation.
In both those examples, global variables would provide better performance than global fields would.