Page 1 of 3
OpenCard to control?
Posted: Sat May 04, 2024 11:01 am
by 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.
Re: OpenCard to control?
Posted: Sat May 04, 2024 11:04 am
by 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
Re: OpenCard to control?
Posted: Sat May 04, 2024 11:20 am
by 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
Re: OpenCard to control?
Posted: Sat May 04, 2024 12:41 pm
by Zax
Klaus wrote: ↑Sat May 04, 2024 11:04 am
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.
Re: OpenCard to control?
Posted: Sun May 05, 2024 11:18 pm
by dunbarx
Zax. You should inform Jacque that the "direction" of that diagram is upside down. She will appreciate the news.
Craig
Re: OpenCard to control?
Posted: Mon May 06, 2024 6:59 am
by Zax
dunbarx wrote: ↑Sun May 05, 2024 11:18 pm
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?
Re: OpenCard to control?
Posted: Mon May 06, 2024 6:39 pm
by 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.
Re: OpenCard to control?
Posted: Tue May 07, 2024 9:03 am
by Zax
I found a more accurate diagram (but I don't know if the earth and the sky are rightly placed
)
Re: OpenCard to control?
Posted: Tue May 07, 2024 9:44 am
by 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.
Re: OpenCard to control?
Posted: Tue May 07, 2024 10:33 am
by 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)".
Re: OpenCard to control?
Posted: Tue May 07, 2024 11:55 am
by 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.
Re: OpenCard to control?
Posted: Tue May 07, 2024 12:02 pm
by stam
Zax wrote: ↑Tue May 07, 2024 11:55 am
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).
Re: OpenCard to control?
Posted: Tue May 07, 2024 2:54 pm
by 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.
Re: OpenCard to control?
Posted: Tue May 07, 2024 5:45 pm
by 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.
Re: OpenCard to control?
Posted: Tue May 07, 2024 6:34 pm
by stam
FourthWorld wrote: ↑Tue May 07, 2024 2:54 pm
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.
AnthonyKoor wrote: ↑Tue May 07, 2024 3:46 pm
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.
jacque wrote: ↑Tue May 07, 2024 5:45 pm
@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?
