how to manage data in LiveCode when working with multiple cards?

[mallwrithing]

Hello forum members,
I am new to LiveCode and am currently having a bit of difficulty. I would like to ask about how to manage and transfer data between multiple cards in a stack. Specifically, I need to store user input in one card and display it in another card in the same stack. So in LiveCode, what is the optimal way to do this? Should I use a global variable, a custom property or is there a better solution? I look forward to receiving support and experience from you guys on the forum. Thank you everyone for your help!

[Klaus]

Hi mallwrithing,

welcome to the forum!

Well, it depends on how you want to save user input resp. how your users will input their erm. input?
If it is a "simple" text field on the (first) card, you can simply script:

Code: Select all

...
put fld "user input on card 1" OF CD 1 into fld "big display of user data on another card" OF CD 42
## The trick is ... OF CARD X
...

As long as we provide the exact "address" of an object, like "fld xyz of cd XXX", we can access everything from everyhere in LC.

Best

Klaus

[dunbarx]

Hi.

What Klaus said.

The important thing he mentioned is to clearly define the destination of the data to which you want to transmit.

Know that this can be extended to stacks as well, which is a "larger", but very similar idea;

Code: Select all

put fld 1 of cd 3 of stack "XYZ" into fld 3 of cd 2 of stack "ABC"

You could execute this from another stack entirely (or even the message box) since you have identified exactly both the origin and target stacks.

Simple, and very powerful.

Craig

[stam]

Hello forum members,
I am new to LiveCode and am currently having a bit of difficulty. I would like to ask about how to manage and transfer data between multiple cards in a stack. Specifically, I need to store user input in one card and display it in another card in the same stack. So in LiveCode, what is the optimal way to do this? Should I use a global variable, a custom property or is there a better solution? I look forward to receiving support and experience from you guys on the forum. Thank you everyone for your help!

You can, as suggested, just refer to data entered in other cards, but my preferred approach would be to divorce the data from the interface.
For example you may have a global array or a database to store data. Or in some cases it's better to store the data in the stack that contains the cards.

An example of storing data in the stack would be to use a 'local script variable' which is a kind of global but only for the handlers in the same script (in this case the stack script). No storage as such would be needed, just store responses in local script variables (declared at the top of the script outside any handler) and you can use them with abandon with all handlers in the stack script, which you then can directly call from any of its cards.

But all methods are good if they work for you.

[dunbarx]

@Stam.

Rereading, I suspect the OP has his user type data into a field or enter it from a dialog, and simply wants to transfer that data to another card.

@mailwrithing. Interesting name.

But is this correct? If so, then as Klaus mentioned, you simply need to identify the target container and the user entry method needs to be properly handled. All this can be done in just a few lines of code. How does the user input the data?

Craig

[stam]

@Stam.

Rereading, I suspect the OP has his user type data into a field or enter it from a dialog, and simply wants to transfer that data to another card.

And?

Is it not simpler to have variable in the stack script with a set and get function?

An example: to get the user name when the user types into a field "username" of card "login". With a stack script you can always get this by calling it's getter function - eg getUser()

Simple to set up:
- in the stack script at the top of the script define a variable that hold the data (typically prefixed with lower case s):

Code: Select all

local sCurrentUser

- a setter function

Code: Select all

 command setUser userName
    put userName into sCurrentUser
 end setUser

Call this on exiting field "username" for example

- getter function

Code: Select all

function getUser
   return sCurrentUser
end getUser

call getUser() from anywhere in the stack to get the username


Makes for simpler working instead of getting field "username" of card "login" or some such. And if you have complex layout with lots of complex pages that may not be simple - but as I said this is my preference... anything that works for others is absolutely fine.
Just offering a different point of view view.

[SparkOut]

There's a lot of options available depending on the use case and user interface. Not necessarily, but another possible solution could be a "placed group" with the behave as a background option selected. We really need more info from the OP as to what is the goal.

[dunbarx]

@Stam.

I only meant that perhaps the issue is less complicated. If the user fills in an "ask" dialog, for example:

Code: Select all

...ask "Enter data"
put it into fld 3 of card 7

And if the user types into a field:

Code: Select all

put fld "entryField"  into fld 3 of card 7

The need to store the data may not be an issue at all, only a direct method of moving it to a field on another card.

The details of either of these are not at issue. But only the OP really know what process he wants.

mailWrithing? Any comment?

Craig

[richmond62]

mailWrithing?

Sorry, at 63 I am not sufficiently flexible any more to indulge in writhing.

[Lance]

Hi mallwrithing,

So I suspect their are folks that will say this is a bad practice, but I have been using a "$" global variable for years and it works great and I do not have to do anything special. It is available anywhere in my app I am working on. I call my global "$X".

I put data into the global like this:

put "JoeSmith" into $X["UserName"]
put "x#453209abc" into $X["UserPassword"]
put "4569.45" into $X["InventoryValue"]


Then from anywhere to get the data out

put $X["InventoryValue"] into field "InventoryValue"


To clear out completely

put empty into $X

It is very simple and works well for me.

[stam]

So I suspect their are folks that will say this is a bad practice, but I have been using a "$" global variable for years and it works great and I do not have to do anything special. It is available anywhere in my app I am working on. I call my global "$X".
<snip>
put $X["InventoryValue"] into field "InventoryValue"

Yeah, as you predicted, someone was bound to point out that using global variables for everything is bad practice - if you have complex code that manipulates a global at multiple points it can be a nightmare to debug. Of course globals have their place - just need to be used sensibly. Very useful for apps with multiple mainstacks for example.

But what's worse, you're not using global variables. You've been using the $ token.

The character $ (dollar sign) is used to indicate an environment variable on Unix systems and a command-line parameter on Unix or Windows systems.

This suggests you've been skirting potential disaster - if you have a variable name that happens to be the same as environmental variable you could end up in a world of pain. You may be getting away with this, but this does not seem sensible advice to new users...

FWIW, the correct use of global variables is using the 'global' key word, usually a the top of a script, outside of handlers, to make it available to all handlers (if used within a handler, the global will only be visible to that one handler). You've just been a bit lazy and not including the 1 line global <variableName> at the top of your script. The only change to your code above would be:

Code: Select all

global X
...
put X["InventoryValue"] into field "InventoryValue"

The usual convention is to start a global variable name with 'g' so you know what you're dealing with when you come back to your code 2 years later - in other words the variable above would usually be called gX, not X.

[Lance]

Stam,

Understood, I retract my suggestion.

Thanks.

[dunbarx]

@mailWrithing.

I made the "W" uppercase to conform to good LC practice.

The thing about globals is spot on. I recommend you play with custom properties instead. They are far easier to manage, and even survive sessions.

Craig