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

[bogs]

I seem to remember the recommendation wasn't to hide them, but simply disable them, but I could be wrong.

There's no recommendation per se, it all depends on the stack and how you want the UI to work.

Sorry, I should have made it clearer that I wasn't speaking of Lc per se, but ui guidelines in general. Even then, my information is likely way out of date on the subject as the last time I was looking into it was around the Delphi 6 release time frame

I'm a bit hesitant to overload button handlers like that because it quickly turns into a bloated controller situation which can be quite hellish to debug. Small, modular handlers would seem to be a better approach but I'm new here. My Unix background also keeps popping up with the "keep each thing doing one thing" mantra.

Heh, I can well understand the 'nix philosophy, but I wasn't talking about sticking that in the buttons script. That kind of code would go much lower, card or, in the case of your address book where there are a LOT of cards, stack level script.

I would point out that you could easily use the method I posted and still compartmentalize or further break down the code to specific handlers, the reason my psuedo code and the example I pointed to are in one handler is that it is just too simple to break down a lot further.

As well, at this point, we're just talking about an address book, unless you wind up turning this single program into a multi-program, like some huge desktop replacement, I just don't see the number of lines that would make this unmanageable coming around. I could be wrong though

Even if you eventually did decide to make this into a desktop replacement sized program, you could consider this address book as a module in itself, called from a completely different mainstack that is part of the larger program. Once it is thoroughly debugged/built/running on its own, it would be similar to a module in pascal or even assembler (the good ol days, right kids?). In other words, its working, all thats left is maintenance.

If I tried to migrate as much as I could to the stack script, say, I do not think I would eliminate the work required to locate the appropriate handlers and functions.

I would never suggest migrating everything to the stack or card level, but as much as is common in function I do. IF a button requires specific handling, I find it easier to put that code in the button, then pass the event for the handlers of common functionality to take care of at the lower levels.

I agree, it is a matter of style, I'd never suggest that it is the only right way, or even possibly the best way, I was only trying to illustrate a possible solution to the posed question

[chuckm]

I also like to compartmentalize tasks. The upside is local control and smaller scripts. The downside is lots of places to look when debugging or embellishing, so I use "Find and Replace..." a lot to locate keywords when doing either.

Still, I like that methodology, only using the card or stack scripts for tasks that must be accessed in common among the various controls on the various cards. In the current stack I am developing for internal use, I have 400 or so lines in the main card script and another 400 in the stack script. But I have 7000 additional lines scattered among the gadgetry on a dozen cards.

If I tried to migrate as much as I could to the stack script, say, I do not think I would eliminate the work required to locate the appropriate handlers and functions. It would be true that no button might have a script, a giant "mouseUp" handler in the stack determining the target and reDirecting to a piece of code somewhere, but if I wanted to change anything, I would still have roughly the same effort to locate the code snippet as I would in locating the button itself.

In the end, it is a matter of style, assuming that one knows the basics of the message hierarchy and uses it to reasonable advantage.

Craig

If I am using, in effect, a "template card" for the controls (using the controls as "background") is it possible to have non-control scripts that are also in the "background"? I don't remember seeing anything about that but I'll go back and do some snooping. Ideally that would be possible because it would better support the notion of "The Law of Demeter" which essentially is that if I didn't create it and it wasn't passed to me then I don't know about it. It's been one of the best guiding principles for OOD/OOP that I've found and I try to use it whenever possible.

[chuckm]

Heh, I can well understand the 'nix philosophy, but I wasn't talking about sticking that in the buttons script. That kind of code would go much lower, card or, in the case of your address book where there are a LOT of cards, stack level script.

I would point out that you could easily use the method I posted and still compartmentalize or further break down the code to specific handlers, the reason my psuedo code and the example I pointed to are in one handler is that it is just too simple to break down a lot further.

I get your point, but I guess I'm thinking of buttons as objects so their "script" should contain any variables and methods that are related to them. The cards are another object, but I'm trying to determine how best to put scripts at the card level given that I've got the controls as a "background" so that the cards don't have to recreate the controls every time.

[dunbarx]

is it possible to have non-control scripts that are also in the "background"?

I think you are very close to getting this. Your template card, background groups and individual controls may either have their own handlers or allow messages to pass to higher (sorry, Jacque) "owners" of those objects. The message hierarchy rules, and should be the single guiding principle for all your planning and execution.

What this means, if I understand the quote above at all, is that a "mouseUp" handler in the card or stack script will react to a click in an area of the card where no control or group exists at all. This can be more than just an annoyance. Broadly, one would check the "target", and if that string contains the word "card", ignore the message.

Or act on it, whatever.

Anyway, it is both quite possible and somewhat common that new users create significant working stacks without paying any respect to the hierarchy at all.However, you leave tremendous functionality on the table, and may drive yourself crazy with errors. Just takes a little time and patience. Oh, and practice.

Craig

[jacque]

I'm thinking of buttons as objects so their "script" should contain any variables and methods that are related to them. The cards are another object, but I'm trying to determine how best to put scripts at the card level given that I've got the controls as a "background" so that the cards don't have to recreate the controls every time.

A background group will receive messages after the card does. If there is no matching handler in the card to intercept, the message will pass through to the background group which in this case is what you want. Your cards shouldn't contain any scripts at all, unless their handlers pertain to that individual card only. Handlers that should respond on any card containing that background group should be placed into the script of the group itself.

Handlers in the current stack that need to respond to anything at any level should go into the stack script.

[dunbarx]

What Jacque said, however upside down her hierarchy thinking.

You must combine her comments with mine. The card holds everything you see, and a backGround is above the card in the hierarchy. But a background's rect is usually smaller than the card rect, so messages can "miss" a background and go only to the card script, and thence to the stack. Again, consider a click on the card that misses any background group.

In other words, we have an object higher in the hierarchy (a backGround) that may not react to messages in the overall hierarchy simply due to its physical size. This is not an issue when clicking inside the group, but your question

is it possible to have non-control scripts that are also in the "background"? I

led me to make the points I did.

I suspect that your issues are simpler than this discourse would suggest, and I bet you will "get" this rather quickly. But keep asking until you do.

Craig

[jacque]

What Jacque said, however upside down her hierarchy thinking.

You must combine her comments with mine. The card holds everything you see, and a backGround is above the card in the hierarchy. But a background's rect is usually smaller than the card rect, so messages can "miss" a background and go only to the card script, and thence to the stack.

No, actually, all background groups, regardless of size or click location, will receive messages after the card gets them. This applies whether you think of the hierarchy as "up" or "down" -- "after" refers to the sequence of the message path.

Here is an abbreviated message path for background groups:

Code: Select all

  card control -> card -> each background group in layer order -> stack

Here is an abbreviated message path for a shared card group:

Code: Select all

  card control -> shared parent group -> card -> all other background groups -> stack

You may be thinking of shared card groups. Those receive messages before they are forwarded to the card and only when directly clicked on. Card groups are in a different order in the hierarchy.

Edit: here's the best diagram I've found: http://livecode.byu.edu/stackwindows/stacks.php Scroll down about 2/3 of the page.

[dunbarx]

Jacque is exactly right about card groups.

Nonetheless, the engine is higher than the button.

Craig

[bogs]

I seem to remember the recommendation wasn't to hide them, but simply disable them, but I could be wrong.

Interestingly enough, I did find two topics on the byu site that are pertinent to two of the questions asked er, earlier, while trying to find something else entirely.

http://livecode.byu.edu/design/InterfaceDes.php It has many design suggestions and references, including links to various Os best practices. It touches on the 'hidden buttons' part of the discussion.

Also from the same site , http://revolution.byu.edu/design/bestpractices.html, which touches on where in the hierarchy handlers are best located a bit better than I was stating it.

[chuckm]

I seem to remember the recommendation wasn't to hide them, but simply disable them, but I could be wrong.

Interestingly enough, I did find two topics on the byu site that are pertinent to two of the questions asked er, earlier, while trying to find something else entirely.

http://livecode.byu.edu/design/InterfaceDes.php It has many design suggestions and references, including links to various Os best practices. It touches on the 'hidden buttons' part of the discussion.

Also from the same site , http://revolution.byu.edu/design/bestpractices.html, which touches on where in the hierarchy handlers are best located a bit better than I was stating it.

My "hidden" buttons are just overlaid by the "active" buttons so there is no chance for visual errors.

I have also chosen to simply disable the add/delete buttons under the scroll list to simplify things. If the user can't click on them, then there is less chance that they will try to do so. Sort of draconian perhaps, but that approach seems to work well from my experience.

By the way, the conversation has been very helpful so far, and I'd like to thank each of you for providing insights and opinions. The "gently nudges" have been very helpful and I appreciate everyone taking the time to help.

[jacque]

By the way, the conversation has been very helpful so far, and I'd like to thank each of you for providing insights and opinions. The "gently nudges" have been very helpful and I appreciate everyone taking the time to help.

We like new people, the more the merrier. Especially when they seem sincere and interested.