Design best practises - libraries, sub-stacks

[Tukcedo]

LiveCoders,

Now that my try-outs with initial applications is advancing a little bit, I'm beginning to wonder about a couple of design questions and perhaps others have similar questions too?

Where would I put commands/functions/handlers that are common to a number of cards? In the stack script? I suppose these are the stack's "private libraries"
How about "libraries" that I want to share between different applications?

How and why would I use sub-stacks? Can the top stack access sub-stack functions and vice versa?

[JackieBlue]

Yeah, I had the same questions. To me, it is kind of funky since I have been a programmer in other, more structured, languages. In any case, check out this thread:

http://forums.livecode.com/viewtopic.php?f=7&t=21289

You may find it helpful. Jack

[jmburnod]

hi Tukcedo,
Your question works in my head for long time. What is the BEST way to do that.

Where would I put commands/functions/handlers that are common to a number of cards? In the stack script?

Yes, you can put them in the stack script but LiveCode offers many capacities.
I think you can have a look to "start using", "insert script" in the LC dictionary.
You can even import a text file like script and insert it into back or front

Can the top stack access sub-stack functions and vice versa?

No,
Substack access to main stack function and command but not inversed

Best regards
Jean-Marc

[Tukcedo]

Thanks for that reference Jack, that seems to answer my questions!

Coming from C and Perl, I really have to get used to the stack concept, but we're getting there slowly

[Klaus]

A MUST READ (and understand) in this respect is the LC message hierarchie,
check this great article: http://www.fourthworld.com/embassy/arti ... _path.html

[sefrojones]

I really like how in Richard's diagrams the messages get sent down the message path, as opposed to up as it is visualized in the official docs. For me, it was much easier to figure out what was going on by imagining that all my controls are on the "surface" of the stack, and as messages are sent, they fall down through the message path until/if they are "caught" by an object/card/stack script. This is obviously a simplified explanation, but I have always preferred the top down representation.


--Sefro

[Tukcedo]

Got a couple more design-related quessies which I've been playing with for a few days.

Firstly, what I'd like to do is go to a certain card and pass that card 1 or more variables. I've read up on send and dispatch but I'm not sure whether this actually opens the card. And if it does, how do I access that variable's value?

The other thing I've been trying to work out is how to structure a list of data with a button in one of the fields that jumps to a card with an argument as in the 1st question. Is there a simpler solution than the datagrid/form object (possibly way beyond my level of LC knowledge)?

Thanks for your advice!

Mich.

[Klaus]

Hi Mich,

Firstly, what I'd like to do is go to a certain card and pass that card 1 or more variables. I've read up on send and dispatch but I'm not sure whether this actually opens the card. And if it does, how do I access that variable's value?

not sure I understand, but you can use custom properties for this!
Set some cps for the card like:
...
set the cValue1 of cd "your targetcard here..." to 42
set the cValue2 of cd "your targetcard here..." to "What is the ultimate answer?"
## of course you can use you own names for the custom props!
go cd "your targetcard here..."
...
Then in the script of cd "your targetcard here...":
on opencard
put the cValue1 of me into tValue1
put the cValue2 of me into tValue2
ask tValue2 with tValue1
## Just an example...
...
Hint: Unlike variables, custom properties will get saved with the stack!
So maybe you need to initialize them when the stack opens.

The other thing I've been trying to work out is how to structure a list of data with a button in one of the fields that jumps to a card with an argument as in the 1st question. Is there a simpler solution than the datagrid/form object (possibly way beyond my level of LC knowledge)?

Sorry, dont get this really!?


Best

Klaus

[dunbarx]

Mitch.

Know that the "natural" path of the message hierarchy is "up", regardless of which way you perceive that. A stack is "higher" than a card, which is higher than a control.

But LC allows any message to be sent in any direction. I think you alluded to the "dispatch" command. Check out also my favorite, "send" which has different features. Both of these permit one to shoot a message up, down or sideways. So if a stack handler can send a message to a button on another stack or substack, then of course a stack handler can send a message to a substack directly.

Craig Newman

[FourthWorld]

Mitch.

Know that the "natural" path of the message hierarchy is "up", regardless of which way you perceive that. A stack is "higher" than a card, which is higher than a control.

Mitch, it's time for a revelation, without which you may not fully understand what you've stepped into. This is an ancient war fought by two tribes, each passionate in their beliefs but bitterly opposed on the issue of hierarchy diagramming.

Both sides acknowledge that messages flow from one place to another, and do so in a fixed, reliable way. But where they disagree, sometimes to the point of fisticuffs after too many pints, is how to illustrate this message passing in a diagram.

The Bottom-Upper tribe (sometimes called Sky Worshipers) portray the message path as moving from the ground up, with the sky being the ultimate destination, where the engine resides in the heavens.

The Top-Downers (also called Earth Worshipers) depict the message path as beginning in the sky, and descending downward to an engine that resides in the Earth.

Brave souls each, yet firm in their own beliefs.

Then there is a splinter group, which some call the Rationalists, who prefer to describe the message path as moving from front to back. Some say this tribe earned their name because their portrayal of the message path merely reflects what we see when looking at a screen. But others say it's because they're rationalizing their way out of having to pick a side, suggesting a view that may sound well and good in conversation but is difficult to render in two dimensions, thus ultimately achieving nothing.

I was born among the Bottom-Uppers, and for many ages accepted their diagrams without question. But later I was seduced by the Top-Downers into believing their way better, a view of the message path being as natural as gravity, with messages falling accordingly.

Which side will you choose among these timeless tribes? And are you prepared to devote sufficient blogging time to defending your beliefs? Anything less may be heresy!

[Tukcedo]

Which side will you choose among these timeless tribes? And are you prepared to devote sufficient blogging time to defending your beliefs? Anything less may be heresy!

Cor blimey! Well, for the time being I will just take in the arguments from both sides if you don't mind I think I'm grasping the concept of sending messages left right or centre, but I'm not quite sure what they do, i.e. as in "go card" it's obvious and the user is presented with a card, but with "send" to a button for the moment I'm assuming this is exactly as if the user pressed it him/herself.

...
set the cValue1 of cd "your targetcard here..." to 42
set the cValue2 of cd "your targetcard here..." to "What is the ultimate answer?"
## of course you can use you own names for the custom props!
go cd "your targetcard here..."
...
Then in the script of cd "your targetcard here...":
on opencard
put the cValue1 of me into tValue1
put the cValue2 of me into tValue2
ask tValue2 with tValue1
## Just an example...
...

That answers the question I think Klaus, vielen Dank!

The other thing I've been trying to work out is how to structure a list of data with a button in one of the fields that jumps to a card with an argument as in the 1st question. Is there a simpler solution than the datagrid/form object (possibly way beyond my level of LC knowledge)?

Sorry, dont get this really!?

Can's say I blame you Well, what I'd like is a list (array) of a label and a button side by side with the button displaying a text. When the user presses the button he/she will go to a card with a variable included (as per your solution above). I do think that the datagrid form will do that, but I'm afraid it may be a bit over the top for something relatively simple as the datagrid is a complex beastie for an LC newcomer such as myself. (I'm working through the datagrid PDF though). Does that make it a bit clearer?

[dunbarx]

Richard.

Gravity is an illusion.

I am reminded of the scene in Monty Python's "Life of Brian", where Brian is running from his ever growing band of followers, and loses a sandal. Half that crowd deemed the sandal sacred, a sign from Brian to follow it. There was another, similar artifact, that was embraced by the other half. I forget what that was, but the point is that both were comically arbitrary.

That said, I will proclaim jihad on anyone who does not think that controls are on the bottom of a hierarchal pyramid, with the engine at the top.

Craig

[jacque]

I avoid the whole issue by referring to messages as "before" and "after". My path is horizontal.

For the question about the list, do you really need a button? A list field can capture the selection and call a card handler that processes it. That handler can set up all the parameters and then go to a card. I do this frequently but I'm not sure if it fits your situation.

[Tukcedo]

That said, I will proclaim jihad on anyone who does not think that controls are on the bottom of a hierarchal pyramid, with the engine at the top.
Craig

Not in my topic you're not! Go open your own jihad topic Having said that, this type of jihad is of course the best there is ...

I avoid the whole issue by referring to messages as "before" and "after".

Sensible move! Think I'll join the horizontal lot then. Well in about an hour or so anyway

For the question about the list, do you really need a button? A list field can capture the selection and call a card handler that processes it. That handler can set up all the parameters and then go to a card. I do this frequently but I'm not sure if it fits your situation.

Interesting thought. How would the user make his choice though? I can see the use of text fields catching and handling events, but how would the user make a choice from the list?

[dunbarx]

Hi again from the Levant.

Make a new list field. It comes with a few lines already filled, so simply place this into its script:

Code: Select all

on mouseup
   put  word 2 of the selectedLine && the selectedText  
end mouseup

I bet you can see the possibilities...

Craig