Looking for an example stack of a address book, etc.

[bogs]

@Jacque. I am misunderstanding something. Or did you intend that the handlers for both the field and the "Cancel" button both live in the card or stack scripts? In that case, script locals would indeed do. I assumed that the "Cancel" button has its own handlers; it is just the way I normally see such a pivotal gadget.

Not Jacque for sure, she is lots smarter than I, but that is how I tend to set these types of situations up.

If there is something that I need to code specifically to one control of type x, and a few general things for all controls of type x, the one specific thing goes into control x's script with a pass event, everything else that is as general as I can make it goes at the card level if I am only running one stack, the stack level if there are substacks.

I also follow her reasoning on the script local variables, although I am not as stringent on custProps (but then, I don't use them a lot in any case). I believe that there is a lesson that outlines that same logic, and although new around here, I haven't seen fault with it yet.

BTW, just to be clear, I am not maligning globals, obviously they have a place, else the great an benevolent creators wouldn't have created them. Either that, or the g.a.b.c. were drinking way too much at the time...

[jacque]

Used sparingly, I see a role for globals.

In the cases you describe globals would work fine and are probably easier for beginners. It's a matter of style but for these situations I prefer getter and setter handlers and functions.

[jacque]

@ Sri

Used sparingly, I see a role for globals.

I agree, sometimes they are just the right sort of gadget. But I still say that custom properties are the way to go. That they survive sessions is among their most powerful attributes.

In this case the data should not be saved across sessions, which is why I think custom properties aren't the best choice here.

@Jacque. I am misunderstanding something. Or did you intend that the handlers for both the field and the "Cancel" button both live in the card or stack scripts? In that case, script locals would indeed do. I assumed that the "Cancel" button has its own handlers; it is just the way I normally see such a pivotal gadget

I did assume the script would be primarily in one place, I tend to use that method more. Buttons are just containers for handler calls unless they are completely self-contained. Again, it's a matter of style. Also, keeping everything in one place lets me avoid globals...

[jacque]

BTW, just to be clear, I am not maligning globals, obviously they have a place, else the great an benevolent creators wouldn't have created them

The benevolent creators created them 30 years ago and it was all we had back then. Now there are better ways. They have their place, as you say, but even if I need to carry a variable across stacks I'll use a backscript before I'll use a global. But that's just me (and a few others.)

The problem is namespace interference, and a messy debugger. If you don't mind that and you can keep close track of what you're naming your variables (and what anyone else might name them if you're running other people's stacks) then they work. It's more than I want to mess with though. Script locals are safe and private to only a single script.

And now I suppose we've completely befuddled the OP.

[bogs]

The problem is namespace interference, and a messy debugger. If you don't mind that and you can keep close track of what you're naming your variables (and what anyone else might name them if you're running other people's stacks) then they work. It's more than I want to mess with though. Script locals are safe and private to only a single script.

Yes, pretty much the advice of every other rad languages manual I've worked with as well. Interestingly enough, wikipedia has a pretty good explanation that is language generic.

They are usually considered bad practice precisely because of their non-locality: a global variable can potentially be modified from anywhere (unless they reside in protected memory or are otherwise rendered read-only), and any part of the program may depend on it.[1] A global variable therefore has an unlimited potential for creating mutual dependencies, and adding mutual dependencies increases complexity. See action at a distance. Global variables also make it difficult to integrate modules because software written by others may use the same global names unless names are reserved by agreement, or by naming convention.

It also goes on to suggest times where they are good for use, but I didn't want to further add to ->

And now I suppose we've completely befuddled the OP.

I certainly hope not. Please pardon our rambling chuck, certainly do come back as Craig suggested if the aftermath introduced ambiguity for you

@Chuck. Do you see what this all means? Write back if not.
Craig

[chuckm]

@ Sri

Used sparingly, I see a role for globals.

I agree, sometimes they are just the right sort of gadget. But I still say that custom properties are the way to go. That they survive sessions is among their most powerful attributes.

@Jacque. I am misunderstanding something. Or did you intend that the handlers for both the field and the "Cancel" button both live in the card or stack scripts? In that case, script locals would indeed do. I assumed that the "Cancel" button has its own handlers; it is just the way I normally see such a pivotal gadget.

@Chuck. Do you see what this all means? Write back if not.

Craig

Hmm, what I *think* I'm getting is:

1. Group the controls and use them as a background so that their handlers are written and held on the stack rather than on a per-card basis.
2. Avoid globals where possible.
3. Prefer custom properties when you need data to survive a session.
4. Use temporary variables for data that does not (or should not) survive a session.

My only confusion at this point is whether or not the data on the card itself is held on the card, in a custom property on the card, or somewhere else. I *thought* the data was held on the card, but now I'm not so sure that is correct.

For this first iteration, I want to end with a standalone app that keeps its data internally (which means I'll need a splash screen launcher and the actual address book will need to be a substack if I am reading things correctly).

After the first iteration, I'll persist the data into a separate file, first in a JSON-formatted text file and finally in a sqlite database.

I have managed to get the controls grouped on a background and from the project viewer I seem to be adding a card and correctly changing the name of the card to match the user. What I'm not seeing is whether or not the card is storing the data so that's what I'm trying to verify before I start trying to add things to the list control (which is in its own group as a background).

[bogs]

1. Well, I think thats the best way to do it, I think I mentioned earlier that not only will it present a consistent interface, but ultimately you only have to write the code specific to each control once and it will work across all the cards it sits on.
2. Here is a lesson that goes into the subject pretty well. The thinking applies not just to livecode, but most languages in general.
...btw, that lessons page has a lot of things that would apply to an address book program, and it gives the lessons in short shots that don't require a lot of time to digest. If you haven't perused the links on it, I'd certainly recommend at least skimming them.
3. I believe that is spot on.
4. Absolutely, as Jacque mentioned there are reams of benefits to it.

In my own code, most of my handlers/routines/functions that use and set variables reside in the lowest necessary part of the path before the engine, either the card or stack. Writing one local line with the variables needed puts it all in one place, although that isn't strictly necessary, for me it works out.

On occasions where I have a lot of handlers, I might split the local variables to be closer to the routines that will call them.

My only confusion at this point is whether or not the data on the card itself is held on the card, in a custom property on the card, or somewhere else. I *thought* the data was held on the card, but now I'm not so sure that is correct.

Not sure I follow what your asking, data is kept where you assign it.
Lets say you have a card with a field. The field holds the contents of the field, the card just holds the control.
...if you want to set a custom property, you will have to determine the object holding it, control, card, or stack. Any object can be assigned custom properties.

If I misunderstood what your asking, or goofed in my explanations, I am sure someone else will chime in

[chuckm]

My only confusion at this point is whether or not the data on the card itself is held on the card, in a custom property on the card, or somewhere else. I *thought* the data was held on the card, but now I'm not so sure that is correct.

Not sure I follow what your asking, data is kept where you assign it.
Lets say you have a card with a field. The field holds the contents of the field, the card just holds the control.
...if you want to set a custom property, you will have to determine the object holding it, control, card, or stack. Any object can be assigned custom properties.

If I misunderstood what your asking, or goofed in my explanations, I am sure someone else will chime in

No worries, I'm trying to word the statement in terms of terminology that I'm striving to become familiar with (and may well be failing).

Let me reword the question:

If I put all of the controls in groups and have the groups behave as a background,are the fields still on the cards or do I need to set up properties to hold the data in the controls? (Still not sure that I'm saying that properly). I understand the gains by putting the controls on a background. Based on the earlier part of the discussion around variables, custom properties, and fields, I'm not grasping whether or not the controls automatically link to the fields on the cards for display and input/editing. I'm going to be working on trying to better understand that today because something is not clicking for me.

[jacque]

The text of a field is a property of the field, just like its height or location. A background group acts as a sort of template, there's only one actual group stored in the stack file and it is drawn on every card where it is placed. LC keeps track of what text belongs to each iteration of the template, so you don't have to worry about it. You can refer to the field like any other and LC will also treat it as though it existed only on that card (in this case at least.)

Since you plan to use the splash stack method, you won't have to save the text outside the stack or restore it, LC will take care of that. The text the user enters will become part of the binary file.

Do note that "substack" does not refer to any stack that is opened as part of the app, it is a specific term meaning a second stack that is included in the same binary file with the mainstack. If you use a substack to store the user data it will not be saved because it will be part of the app. Instead you need to use a second mainstack as the data file, which is independent and can be saved normally.

[chuckm]

The text of a field is a property of the field, just like its height or location. A background group acts as a sort of template, there's only one actual group stored in the stack file and it is drawn on every card where it is placed. LC keeps track of what text belongs to each iteration of the template, so you don't have to worry about it. You can refer to the field like any other and LC will also treat it as though it existed only on that card (in this case at least.)

Since you plan to use the splash stack method, you won't have to save the text outside the stack or restore it, LC will take care of that. The text the user enters will become part of the binary file.

Do note that "substack" does not refer to any stack that is opened as part of the app, it is a specific term meaning a second stack that is included in the same binary file with the mainstack. If you use a substack to store the user data it will not be saved because it will be part of the app. Instead you need to use a second mainstack as the data file, which is independent and can be saved normally.

I'm not sure that I am understanding what you've said (on me, not on you). I thought that data entered into a substack that is attached to a main stack is stored when the application is saved, hence the splash screen technique that I've read about. What I got from your comment is that, in the case of the address book, I would need to have the address book be a main stack that is somehow invoked from the splash screen which would have to be a main stack. Can you elaborate a bit more because I don't think that I have understood you.

[dunbarx]

Jacque.

Do note that "substack" does not refer to any stack that is opened as part of the app, it is a specific term meaning a second stack that is included in the same binary file with the mainstack. If you use a substack to store the user data it will not be saved because it will be part of the app.

If I make a stack and a substack of that stack, and include both in the stack files of a splash stack, all data in both included stacks are saved between sessions. Always were, no? I know you know this; I think you were just not clear in explaining the terminology of apps and stacks...

Craig

[dunbarx]

Chuck.

Jacque wrote:

A background group acts as a sort of template, there's only one actual group stored in the stack file and it is drawn on every card where it is placed.

This is quite correct.

But since you are still getting used to backGround groups, simply think of them as a special gadget that can exist on multiple cards, can contain within it any number of other controls, and will automatically clone itself onto any new card created at any time. Note that a group can contain a single control, say a button, and can be used in the same way, to place that button on every card. But only a group has the background behavior property, so there is no way to make a naked button with those features.

Read up on the "place" command, when you develop your stack and did not realize that you needed to place background groups on already created cards.

Craig

[jacque]

Jacque.

Do note that "substack" does not refer to any stack that is opened as part of the app, it is a specific term meaning a second stack that is included in the same binary file with the mainstack. If you use a substack to store the user data it will not be saved because it will be part of the app.

If I make a stack and a substack of that stack, and include both in the stack files of a splash stack, all data in both included stacks are saved between sessions. Always were, no? I know you know this; I think you were just not clear in explaining the terminology of apps and stacks...

Craig

Yes, if your mainstack and its substacks are not compiled into the finished app, everything will save correctly. In fact, you can't save a mainstack without also saving all its substacks -- they are the same binary file on disk.

When a standalone (an app) is created, LC attaches the engine and some other components to the mainstack. This is what can't be saved. If the mainstack contains substacks (they are the same file) then none of it will save. The splash stack method involves making a minimal, usually one-card, mainstack that does nothing but open a separate, unattached mainstack; basically it is an app that opens a document. The document stack has no engine attached, so it is allowed to save itself.

The splash stack/mainstack/standalone stack should typically include only enough scripting to get that document stack opened. All the working code and stack data goes into the document stack.

[jacque]

Oh, and one more thing to consider when creating a splash stack. Usually the document stack is included in the Copy Files pane of the standalone builder. That causes the builder to include those stacks as part of the distribution (but does not embed them into the standalone, they remain independent stacks.)

On a Mac, included files are placed inside the app bundle. On other operating systems, they are placed inside the app's containing folder. On Mac at least, you can't save the content of any file inside the app bundle; the same restrictions apply there as to the app itself. So the first time the app is launched, the splash stack needs to copy the document stack to a writeable location such as the Documents folder. After that, it opens the document stack. Typically on startup the app checks for the existence of the document in the new location and if it doesn't exist, copies the one in the app bundle over to the writeable location.

[bogs]

Oh dear, now my eyes have crossed completely to opposite sides of my head ! (Just kidding).