Using Global Variables

[sandybassett]

I have a data input screen with nine fields. Each one edits the raw input to uppercase, lowercase, titlecase etc and an answer command shows me its correct. Then in each handler I put the text into a global variable like gName, gAddress etc in order to store them until all nine are entered and then save them as an SQL record. The trouble I'm having is that each variable persists only until that handler completes,ie when you go to field 2 you cannot get the value of global 1 anymore. I've tried declaring the globals in each field, or in the card stack or in the main stack as the first line each way, but nothing works, the globals are very temporary, what are called local variables in other languages. How do I make a global that can be accessed from anywhere in the program? Also tried custom property but couldn't get that to work either. Thanks for any help you can give.

[dunbarx]

Well, there is something wrong.

If you have two buttons, "b1" and "b2", and this in b1:

Code: Select all

on mouseUp
global gGlob
put "25" into gGlob
end mouseUp

And this in b2:

Code: Select all

on mouseUp
global gGlob
answer gGlob
end mouseUp

and you click on b1 and then on b2, you will get an answer dialog with 25.

I don't suppose you are declaring them BELOW where they are populated or referenced? That would do it. Keep them at the top if so.

This does not address, at all, script globals. You say you are declaring them in each field handler. What handler is in those fields? Is it in fact being executed? This methodology, where the global is declared in each handler, is 26 years old.

Craig Newman

[Newbie4]

Unlike other languages where you only have to declare a global once, in LiveCode you have to redeclare it everywhere that you use it.

So if you have a global called "gName", you have to have a line "global gName" in every handler that uses it, not just where you first set it. (As the previous post did)

Is that the problem that you are having?

[dunbarx]

Newbie.

Not quite true. In Hypercard this was so, but in LiveCode, one can have script local variables, where the declaration may be made outside of any handler. All handlers in that script can then access it, (important, it must be declared above any handler that needs it) and in any other script anywhere at all, if similarly declared, all handlers there have the same privileges.

But is is true that a global, however it is declared, is not automatically available as a system-wide entity. It cannot be declared somewhere, however that is done, and yet be accessed everywhere else simply because of that action. It must at least be declared in the script of whatever controls, cards or stacks might need it. Of course, it can always be declared in individual handlers at any time.

This is not too onerous, and easy to get used to. It was a pleasure, coming from HC, to be able to use script variables, a veritable gift.

Craig

[shaosean]

Personally I would look at not using global variables for this, just call the data directly from the fields when you need to update the SQL database.. But, if you want to go with the globals just declare them at the top of the script before any handlers (as mentioned above)

Code: Select all

-- button 1
global pig
global cow

on mouseUp
  put "oink" into pig
  put "moo" into cow
end mouseUp

Code: Select all

-- button 2
global pig
global cow

on mouseUp
  answer pig & LF & cow
end mouseUp

[Newbie4]

I was addressing his problem without going into a lot of detail and confusing him.

As I read his problem, he was declaring each variable in its own handler (e.g. gName in field 1) but only there

I have a data input screen with nine fields. Each one edits the raw input to uppercase, lowercase, titlecase etc and an answer command shows me its correct. Then in each handler I put the text into a global variable like gName, gAddress etc in order to store them until all nine are entered and then save them as an SQL record. The trouble I'm having is that each variable persists only until that handler completes,ie when you go to field 2 you cannot get the value of global 1 anymore.

He needs to add a global for each variable that he uses in other handlers. In his example above, if he wants to access global 1 (gName) in field 2, he needs to add the statement "global 1" (or "global gName") to the field 2 handler also.

If you read the rest of his text, it sounds like he added the global everywhere (card, script) except where he needed to. That is why I phrased my answer as I did.

I did not want to get into local variables because of his statement

How do I make a global that can be accessed from anywhere in the program?

@Sandybassett
Look at the examples posted by the others: You need to put the statement "global gName" in every handler that references "gName". The same goes for the other global variables that you have defined.
The alternative is to put that statement "global gName" at the top of your script before all the handlers. That way, the "global" is in effect for all of them. But you have to do the same for every other script that has a handler in it that references that global variable (gName)

What Craig pointed out is that there are also "local" variables ("local gName") which:
if you put in a handler, gName exists only as long as that handler is active
if you put at the top of the script (before any handlers in that script), gName exists for every handler in that script automatically.

Once you leave that script, gName ceases to exist. So if you want gName to be available to other scripts (other cards, stacks, etc) you would use "global" instead of "local" variables.

Did you finally get your question answered and your screen working?

[sandybassett]

Thanks guys for all the suggestions. If I was unclear before, I did try declaring the globals, separately, at the top of the main stack, the top of the card, the top of each field handler and it never worked. It never occurred to me to re-declare it wherever it was later used. My background is in several other languages where globals are, ..well, global, available everywhere. So I tried Newbie4's suggestion, re-declaring global gName in the Address field also, and it still wouldn't show in an answer command. So I tried shaosean's suggestion to just use the field contents with "answer text of field Name" That works, for which I'm glad and grateful. But if that's the only way, it is going to seriously limit how I can use LC because my business programs typically gather several items of entered data, sometimes from different cards in order to store them in the database. Maybe something else will crop up. But thanks for the help.

[Newbie4]

The adding of "global gName" to the address field should have worked.

Did you put field "name" into gName? Then it should be there

Maybe if you include some code we could see what is happening.

Have you used the debugger yet? That will show you exactly what is happening.

[dunbarx]

Hmmm.

Globals in LC work as advertised. If they are declared at the top of every script (not the handlers in that script) then they are available for all those handlers. This applies to each script where the global is similarly declared.

I do understand the concept of declaring them system-wide, and see an advantage in terms of simple brevity. But I also feel that it is comforting to see the declaration in each script, so that one knows (is reminded?) of their presence, especially when debugging. I would opt to keep the LC paradigm for that reason alone.

As an example of a LC system-wide gizmo, a custom property may be declared anywhere, and one might say that its value is forever available ubiquitously. This is a wonderful thing. But it requires a bit of detective work to read that value casually, either by script or by direct means.

Craig Newman

[sandybassett]

Newbie4:
The adding of "global gName" to the address field should have worked. Right, but it didn't. So I followed shaosean's idea of just using 'the text of field X' for each of the 9; it worked in the answer command and also worked in the Save button handler putting those into local vars. ie "put text of field Address into tAddress" No problems. So I'm good with that. The reason I wanted to get the data to a var is that it's easier to construct the db INSERT line that way. So this just gets it there a little later in the process. Thanks for help.
Craig:
It's good that LC globals work as advertised in NY, but they don't in Florida.
But I'm good with my present way of doing it. Now just have to construct the db INSERT line so it works.
Actually, the only additional thing I have to master to do this project is what I call 'lookup files' which may be scrolling list fields in LC ese. Where, for example when you get to the zip code field a scrolling list field overlays and as you type in each digit of the zip, the list narrows down til there's one left, select it and the city and state fields automagically fill in. Hope I don't have to tear out much hair on that one. Thanks for the help.

[shaosean]

You could always just use local variables in the script to build the SQL..

Code: Select all

local tName
put the text of field "name" into tName

[sandybassett]

Shaosean:
That's exactly what I did. And it works great. I guess that I'm just confused by the lack of orderly documentation of some important steps, compared to the languages I've previously worked with. Frustrating! I'm going to take their LCUniv $50 course in my spare time (?) to see if that will help fill in the blanks. Thanks for the help.

[dunbarx]

Hi.

What is going on down in Florida is a mystery. You are doing something wrong.

But know also that, as an experienced programmer, you are mired in a not uncommon situation. LiveCode is very readable. In fact, it seems much more accessible than it is, and that leaves many new users frustrated because they get ahead of themselves right off the bat. There is a formal syntax and IDE structure, and it is easy at first to leave small loose ends dangling that break what appears as a straightforward process. This is certainly what is going on with your global travail.

The task you mentioned about narrowing a list based on increasing text entry is something I have used many times. You have a data set somewhere, and upon typing successive characters in a field, say, an ever shortened list of candidates appears in another field. You might not even start displaying those candidates until several characters are already present, so that the display does not start with too many choices. It is an easy and fun thing to write, and you will learn a great deal along the way. Read up on the "filter" command in the dictionary, as well as the "is among" operator. The "is among" is simpler, and speed should not be an issue. Also check out "keyDown". Write back if you get stuck in the Everglades.

Craig Newman

[jacque]

I'd like to see a code snippet that doesn't work too. I have never had properly placed global or local variable declarations fail. I'm pretty sure there must be a misplacement somewhere.

[sandybassett]

Craig:
Florida is a mysterious but wonderful place. I'm sure I did something wrong, but I'm learning to like LC and also finding some anomalies. There is a formal syntax to every language and loose ends dangling, not finding an orderly presentation of how to handle those is what's frustrating; but there's a way that does work. Since I'm not in this for kicks and giggles, but for profit, my goal is not the ever elusive 'perfect code' but instead producing a product that works well and sells well. So I'm good with this now. Thanks for the response on the scrolling list field, I like using them also. This app will use an SQL db as the source for zip, city, state; find on the first and pop the others into their fields. Since I know from experience that there are many things that must work just right to make it work, I'm sure you'll see several cries for help from the Everglades--its a really big swamp.
Jacque:
I would love to send you code snippets, but as I found something that would work I deleted the lines that didn't work, so I don't have them anymore. In sum, I put the declaration "global gname, gaddress, etc" at the top of the stack script, at the top of the card script, put text in the global in a field handler, finally re-declared them at the top of each field keydown handler. In all cases they worked fine while still in that field handler, but when going to any other field the var contents were gone. The answer command would return (depending on exactly the current syntax) either a blank, the name of the variable, or an error something like error in handler near char xx.