OpenCard to control?

[Zax]

Hello,

When a card is opened, it receives the "openCard" message.
Is it possible that different controls of this card also automatically receive the "openCard" message when opening this card?
Of course, I could send "openCard" to the desired controls by "send" or "dispatch" but I don't know which controls should receive this message.

Well, maybe that's not very clear. In summary, how do I place a control in the Message Path so that it receives the "openCard" message, without modifying the card script - I would like these controls to be independent and can be easily copied to different stacks without modifying the scripts of cards or stacks.

[Klaus]

Hi Zax,

unfortunaltely there is no such message.

However we have a "opencontrol" message, but that is only sent to GROUPS.
But maybe you can use this somehow by just grouping one or more of your controls.

Best

Klaus

[richmond62]

Of course, I could send "openCard" to the desired controls by "send" or "dispatch" but I don't know which controls should receive this message.

Well . . .

Code: Select all

on OpenCard
      send "mouseUp" to button "myButton"
end openCard

[Zax]

However we have a "opencontrol" message, but that is only sent to GROUPS.
But maybe you can use this somehow by just grouping one or more of your controls.

Great!
Thanks a lot Klaus, it's just perfect


This picture, found at https://lessons.livecode.com/m/4603/l/5 ... ssage-path needs to be updated.

[dunbarx]

Zax. You should inform Jacque that the "direction" of that diagram is upside down. She will appreciate the news.

Craig

[Zax]

Zax. You should inform Jacque that the "direction" of that diagram is upside down. She will appreciate the news.

Is she a Diana Ross fan?

[jacque]

A long time ago one member referred to us as either sky worshippers or earth somethings. Wish I could remember the exact labels, it was clever. I am firmly bound to the earth but over the years I have learned to flip the vision the sky worshippers cling to. If that fails I use Google translate.

[Zax]

I found a more accurate diagram (but I don't know if the earth and the sky are rightly placed )

[stam]

The obvious omission in that graph is behaviors.
it's especially useful to know that the a handler will be executed first in the object carrying the behavior and then only executed in the behavior if not handled or passed in the carrying object.

I'm not sure double the graph like the one you show helps actually - the right handed graph basically interjects the substack, but actually the way I think of it is that it goes to stack (regardless if substack or not) so you can illustrate the path as card > substack > stack, a single graph.

The other omissions are front- and backscripts, both are essential.

Richard has written a very nice piece on the message path you can find here: http://www.fourthworld.com/embassy/arti ... _path.html

This figure below from his write-up probably illustrates most detail, but not quite everything (eg that cards, backgrounds & scripts can have behaviors too). I'm not sure if cards have precedents to background groups as this graph suggests (may be an older version where such a thing as 'background' existed), in my mind, group scripts (whether background or not) occur earlier in the message path than card - but happy to be corrected...

The other good thing to know is that backscripts intercept the message path from multiple mainstacks.

[stam]

Thinking about this more, here's a proposal for a more complete message path - happy to be corrected if I got something wrong or missed something...

Where a path component is missing, go to next component, seems to ring true to me.
I assume widgets/script widgets are included in "Control" but not sure.
I'm also unsure as to if "background group" is higher up the message path than "card" which many graphs indicate. Seems odd to me, but haven't got the time to experiment right now...

I guess the obvious caveat is startup is sent to the 1st card of the stack, but not sure how that would be represented...
Also now sure how to represent linked behaviors... maybe I'll change the word "Behavior" to "Behavior(s)".

[Zax]

I do not have sufficient knowledge to correct the validity of the information in this diagram but if it is correct, I suggest using the color code from the previous diagrams (notably yellow for optional elements).
And if it is correct, this diagram should appear on the official LC help, replacing the very incomplete diagram that I posted first.

[stam]

I do not have sufficient knowledge to correct the validity of the information in this diagram but if it is correct, I suggest using the color code from the previous diagrams (notably yellow for optional elements).
And if it is correct, this diagram should appear on the official LC help, replacing the very incomplete diagram that I posted first.

yeah I posted this as a proposal for people who know more than me to feed back.
Certainly, it's how I use LiveCode and it seems to work

As to the notion of colouring 'optional' steps - the only 'non-optional' elements of this is the starting point, the stack and the engine , so I'd probably colour those instead
(you don't need any of the other elements, but if present will follow the message path)

One thing that is not clearly represented is that scripts in the backscripts will affect any stack running on a given engine, so it accepts multiple inputs (I've used this when having multiple script only library stacks and not wanting to create a web of connected libraries with 'start using' - just ensure handlers are namespaced and it works a charm).

[FourthWorld]

Behaviors can also be nested.

The most complete representation is a vast spiderweb of connections, less instructive than a simplified model designed for learning core concepts.

[jacque]

@stam: Cards receive messages before backgrounds if the group has background behavior set. If not then they behave like other controls and get messages before the card but after the controls the group contains.

I am delighted to see that you and Richard are earth lovers.

Edit: I don't think opencard is sent to card groups, it's sent to the card. If a background group has an opencard handler then it will catch the message if the card doesn't. Richard's diagram shows both types of groups and seems accurate.

[stam]

Behaviors can also be nested.

The most complete representation is a vast spiderweb of connections, less instructive than a simplified model designed for learning core concepts.

Agreed, which is why I didn't add anything, and the multiple behavior boxes seem annoying as well, but also seem necessary. I think many users, especially new users, miss the opportunity to use these.

In an effort to at least imply possibility of nested behaviors, I think changing Behavior to Behavior(s) can help flag this.

You can set a custom property at the card level and then check for it in the controls' script. If it's there, they'll respond accordingly to the "openCard" message.

Thanks Anthony - that is of course correct, but it's not part of the normal message path. As it happens, groups are sent the 'openControl' message at openCard, which is why this is included.

The idea is to show the hierarchy of objects that messages pass through when dispatched.

@stam: Cards receive messages before backgrounds if the group has background behavior set. If not then they behave like other controls and get messages before the card but after the controls the group contains.

Noted - thank you. I'll add a further 'background group' level after the card. I see also that backgrounds have the equivalent of openControl (openBackground). Learn something new every day


So here's a revised version of the message path.
Yellow are the 'less commonly used elements', as the only required elements are stack and engine really...

Is this closer to accurate?