LiveCode Forums.

I have found it impossible to make a Field "Variablethingy" Global. It will not compile. To get around it I have put the contents into another VariableThingy that is Global in the different cards, then tranferred it back at the destination. This is far from desireable in my application.

I might use the following:-
==========================================
--Card in a stack
On mouseup
Global field "Variablethingy"

--Calculate or evaluate and put the answer into field "Variablethingy"

end Mouseup
==============================================

Another and different card, same stack

On mouseup
Global field "Variablethingy"

--The result carried over into this card which has the actual displayed
Field "Variablethingy"

end Mouseup
++++++++++++++++++++++++++++++++++++++++++


So why does it fail to compile because it is a field?

Hi user#666,

sorry, no way, only variables can be local or global!
You will have to put your field(s) manually into a global or local variable.


Best

Klaus

FileMaker user? I know of no other system that uses fields for globals.

Welcome aboard. Here in Rev, there are four main types of containers:

- local variables
- global variables
- custom properties
- fields

As discrete objects physically represented on screen, fields are best for displaying information. But because of the overhead needed for display, they aren't the most efficient choice for storing or programmatically manipulating information.

For information that doesn't need to be displayed for the user, you can use a global variable.

See the "global" keyword in the Rev Dictionary for details on using global variables.

Thank you Klaus and Fourthworld,

It does not say you cannot have Global fields in the Rev Docs. so what is a chap to think.
A field is still a variable.
Anyway, Thank you for the confirmation I can move on now to the next secret.

You know, so much time is wasted trying to make this sort of thing work before you give up.

user#606 wrote:Thank you Klaus and Fourthworld,

It does not say you cannot have Global fields in the Rev Docs. so what is a chap to think.
A field is still a variable.
Anyway, Thank you for the confirmation I can move on now to the next secret.

You know, so much time is wasted trying to make this sort of thing work before you give up.

It is global in the sence that you can get/put it from any handler, you just need to specify where the field is if it is in a different stack or card.

Its just not a variable, so you don't declare it anything. its a field.

Thank you Keyless, I am clear on that now.

user#606 wrote:A field is still a variable.

That's an interesting idea, one I've not seen before. May I ask what other programming languages you've learned which may have contributed to this notion?

More to the point, why doesnt Rev make it clear in its documentation. A field IS a variable, it is not a constant or just text holder like a lable.
Well, isnt it?
Anyway, I am satisfied I am wrong, my mistake! I am used to Basic and a case tool called Layout. I know neither had the term Field, but they both had the same "box to put input into" and they were variables.

There's a few ways to work with data in rev, and they're roughly put into these categories (I hope I don't forget any):

variables & constants
stuff that only exists within scripts

fields (note that labels are just fields with lockText set to true)
text entry areas on cards

custom properties
part of any object but not visible anywhere on a card

outside
stuff like text files, databases, ftp, posting to urls etc.

there's of course other places where you can store text, like the name or label of buttons and stacks, but these are not really intended for data handling (although sometimes it's advantageous to be "misuse" them as such).

Every Language of course is different, but in Rev terms, calling a field a variable (or saying that a label is something else then a field) makes no sense whatsoever. Knowing all this is just one of the many steps to fully understand a new programming language.

user#606 wrote:More to the point, why doesnt Rev make it clear in its documentation. A field IS a variable, it is not a constant or just text holder like a lable.
Well, isnt it?

Interesting idea. I'd never thought about it that way, that anything that wasn't fixed was a "variable".

To be variable and to be *a* variable are different things, in any language. It's been a few decades since I worked with BASIC, but as I recall any form of BASIC that supports GUI objects maintains a distinction between objects and variables.

I am used to Basic and a case tool called Layout. I know neither had the term Field, but they both had the same "box to put input into" and they were variables.

I'm not familiar with CASE tools for BASIC, but the concept of variables is so fundamental to all languages that I would be surprised if any BASIC dialect or CASE tool dared to confuse matters by suggesting that any container object that may have editable text was synonymous with a variable per se.

That's not to suggest such a thing may not exist, but simply that it would be so very unusual in the programming world that the language designers would have quite a challenge justifying such a departure in language design.

To hit the subject over the head with an analogy...

Because fields have many properties over and above the displayed value, and can have unlimited additional custom properties, a field is more like a forest... And a variable in a script is like a tree.

When the language syntax expects a tree, it probably can't handle a whole forest.

But you can point out a particular tree in a forest for some operations, like "put myVar into the text of fld 1" for example. You can say the same thing with "put myVar into fld 1" in which case the syntax guesses you mean "the text of". (One particular tree out of many in the field... Ooh, really mixing metaphors now!)

The global keyword lets you access a variable from multiple scripts, but you already can access the contents of a field from multiple scripts. The following snippet: ...Will let you access the field's contents from ANYWHERE in Revolution. Global indeed.

Mr. Innanen, that was quite good. When you write a book on Rev I'll buy a copy. Well done.

But certainly one would be haunted by a 1000 CSE professors if they were to use a variable as wide as a forest. That would be very poor scope and memory allocation indeed.