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

[bogs]

I don't think I'd start with that book. While much of it is relevant, a lot of it is obsolete too.You just need to pick up a few main concepts, and the rest will fall into place. You might have better luck working through at least the first few stacks (in order) here : http://hyperactivesw.com/revscriptconf/ ... ences.html

I actually found both to be great help in learning more about Lc, the books linked do seem to put the concepts in a slightly more methodical order (for me).

As Jacque points out, some of the information is pretty obsolete, however you will eventually be able to spot the things that need re-working, and then you can apply what you've gained to correct for it almost in your head.

Another resource that I came across that doesn't take a long time to digest is this tips page. If you ask me, it should be included with the Lc download, and prominently displayed in the help menu.

[chuckm]

Which sections of the User Guide have you read?

All of them. Twice. Re-reading for the third time. While I've got the patience and tenacity (ok, stubbornness ) to stick to it, I can see how new users might be turned off. I've written lots of MVC apps in the past in other development tools, so I totally get how that works.

One of my motivations (besides my own side projects) comes from some kids who looked at LiveCode but just couldn't get their heads wrapped around it so I'm creating a series of app tutorials that starts with something relatively simple and works all the way through a application of medium complexity (the Personal Information Manager). From there I want to create tutorials that walk them through converting the application to use with mobile devices so that they have a solid foundation.

I'm not giving up, but it is really slow going.

[chuckm]

Hi!

I'd like to offer my thanks for your help. I'm struggling, but from experience I know that new things require patience and tenacity (e.g., stubbornness) and I've got lots of both.

I would create a group that contains all the controls in your diagram. Set the group to act like a background in the property inspector. That way it will appear on every card. Name it something, I'll call it "template".

When you say all of the controls, may I assume that you mean all of the buttons, labels, and textfields? Or is it some subset of those controls?

Thanks in advance!

Charles

[chuckm]

Address Book

This is the tutorial app I'm working on:

Controls

• Names (list control) - a list of all of the names in the address book sorted in last name / first name order
• ‘+’ Button - add a new contact
• ‘-‘ Button - delete the contact selected in the Name Listing
• First Name - First name of the contact
• Last Name - Last name of the contact
• Address - Each field under address contains the street/mailing address information
• City - City associated with the contact address
• State/Prov - State or Province associated with the contact address
• Postal Code - Postal Code associated with the contact address
• Close Button - Close the stack
• Cancel Button - Cancel any changes to the current card if in Edit mode
• Edit Button - Enter edit mode and allow changes to be made to contact information
• Save Button (not shown) - Appears when in Edit mode (hiding the Edit button) and allows the user to save changes.

Program Behaviors

Start Up

1. All of the controls should be displayed but the text controls should be empty.
2. The application should display a list of names sorted in last name/first name order. If it is the first time the application is opened the list should be empty.
3. The Edit button should be disabled
4. If there are no entries in the list, disable the Delete (‘-‘) button.

Create New Contact ('+' button)

1. Activate Edit mode (Hide Edit button, show Save button)
2. Clear the contents of all of the fields.
3. Move the cursor to the FirstName field
4. Enable the Save button when the user enters any data.
5. Save the new card when the user clicks the Save button.
6. Add the new contact to the list
7. Resort and refresh the list display
8. Enable the Delete (‘-‘) button if there is at least one entry in the list.

Delete Contact ('-' button)

1. Prompt the user to confirm the deletion.
2. If confirmed, delete the card
3. Remove associated entry from the list.
4. Resort and refresh the list display.
5. Disable the Delete (‘-‘) button if the list is now empty.

Edit Existing Contact (Edit button)

1. Activate Edit mode (Hide Edit button, display Save button)
   Move the cursor to the FirstName field.
   When finished editing, click the Save button to save changes.

Canceling Changes (Cancel button)

1. Revert any changes for the entire card.

Saving Changes (Save button)

• New contact
  1. Concatenate the last name and the first name.
  2. Set that string as the card name.
  3. Save contact data.
• Existing contact
  1. Save the changes.

Closing the Stack

1. Prompt the user to save any changes to the current card with a Yes/No dialog. If the user selects Yes, save the changes. Otherwise, discard the changes.
2. Close the stack.

[chuckm]

On reverting changes to a card, my thought is that I need to do the following process:

1. Save fields into a temporary array when the Edit button is clicked.
2. If the Cancel button is clicked during this process, iterate over the temporary array to restore the original field contents.

Is this the "standard" approach or is there something better/more efficient?

Thanks!

Chuck

[dunbarx]

Save fields into a temporary array when the Edit button is clicked.
If the Cancel button is clicked during this process, iterate over the temporary array to restore the original field contents.

In a sense, this is how the "ask" dialog works, in that it creates a small temporary workspace that only needs to make a hard change if the user affirms that it do so. So I am confused. Did you mean an actual "ask" dialog (you mentioned "Cancel") or some palette or substack that forms a more sophisticated "ask-like" gadget?

If you want to allow the user to edit a field directly, and restore to the original if the user bails. I would use a custom property.. You might (pseudo)

Code: Select all

set a custom property with the field contents on openField
allow the user to edit at will
if the user clicks the "cancel" button (wherever that might live) restore the contents

Craig

[chuckm]

Save fields into a temporary array when the Edit button is clicked.
If the Cancel button is clicked during this process, iterate over the temporary array to restore the original field contents.

In a sense, this is how the "ask" dialog works, in that it creates a small temporary workspace that only needs to make a hard change if the user affirms that it do so. So I am confused. Did you mean an actual "ask" dialog (you mentioned "Cancel") or some palette or substack that forms a more sophisticated "ask-like" gadget?

If you want to allow the user to edit a field directly, and restore to the original if the user bails. I would use a custom property.. You might (pseudo)

Code: Select all

set a custom property with the field contents on openField
allow the user to edit at will
if the user clicks the "cancel" button (wherever that might live) restore the contents

Craig

Essentially, the "cancel" operation would restore the original contents of all fields on the card, not just a single one. The "cancel" operation would be triggered by clicking the "Cancel" button on the card. I'm wondering if I need a custom property or just a temporary array because I'll trap any event that would leave the card in an "unsaved" state and use an "ask" dialog to query whether the changes need to be saved or discarded. I'm wondering if we are saying the same thing but that I'm tripping over terminology.

[jacque]

When you say all of the controls, may I assume that you mean all of the buttons, labels, and textfields? Or is it some subset of those controls?

"Control" is a generic term for all the items in the tool palette. Fields, buttons, scrollbars, widgets, images, etc. are all controls.

[jacque]

On reverting changes to a card, my thought is that I need to do the following process:

1. Save fields into a temporary array when the Edit button is clicked.
2. If the Cancel button is clicked during this process, iterate over the temporary array to restore the original field contents.

Is this the "standard" approach or is there something better/more efficient?

That's what I'd do. Arrays are efficient and fast.

[dunbarx]

Ah.

So you have a dedicated "Cancel" button. Then the pseudoCode I gave above should be fine. Store the contents of the field in a custom property, triggered by, say, "openField", and if the user hits the "Cancel" button, restore.

Craig

[jacque]

So you have a dedicated "Cancel" button. Then the pseudoCode I gave above should be fine. Store the contents of the field in a custom property, triggered by, say, "openField", and if the user hits the "Cancel" button, restore.

That's another valid approach, but I avoid custom properties for values that are not persistent across sessions. There's too much risk of saving the stack with existing values and having those appear unexpectedly on next launch (I got into trouble with a client when that happened.) Script local variables are more reliable in those situations and require less maintenance. You don't have to worry about them showing up after a relaunch and you don't have to worry about deleting their values before saving or reloading.

As a general rule: custom properties for persistent values, script locals for session-temporary ones.

[dunbarx]

Jacque makes a point about lingering data in a custom property, their very persistence a possible source of error. This is also the case with fields.

I do not find as a matter of style that this is a source of worry.

In the example I suggested, the content of the recently opened field are loaded in full upon openField, and it matters not whether last weeks contents are already present, or whether that property has been initialized and emptied just for good houseKeeping. Jacques point is that last weeks data, if simply reloaded without being refreshed, might be stale.

@ Jacque. How would you use a script local variable to do what the OP wants? It is desired that a copy of the field contents be stored somewhere, so that a full-field"undo" can be invoked as a last resort. Surely a global variable would do, in that the starting contents can be stored upon openField, and a separate "Cancel" button can access that data. And for your purposes, the global would not survive sessions.

Craig

[jacque]

How would you use a script local variable to do what the OP wants? It is desired that a copy of the field contents be stored somewhere, so that a full-field"undo" can be invoked as a last resort

I'd use an array with the field ID as the key and the text as the element content. If every field has a unique name, that would work as the keys too though the ID is marginally safer.

I try to avoid global variables whenever possible. They clutter up things. Script locals are neater and less prone to conflicts.

[sritcp]

As a general rule: custom properties for persistent values, script locals for session-temporary ones.

I try to avoid global variables whenever possible. They clutter up things.

What if I need a variable that is accessible across scripts but not persistent across sessions? Wouldn't globals fit the bill?
If a button is clicked and the handler is running, you may not want the user clicking certain other buttons (as children are wont to); and, say, you don't want to disable the buttons for programmatic reasons. In such cases, I find a global flag to be the simplest solution. I can think of many such instances. When a whole bunch of audio need to interact, for example.

I know we have had this discussion many times before on this forum. The veterans always seem to come down against the hapless globals!

Used sparingly, I see a role for globals.

Regards,
Sri

[dunbarx]

@ 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