LiveCode 4.6.1 message path and behaviors

Björnke von Gierke bvg at mac.com
Sun May 22 18:43:56 EDT 2011


new nitpicks:

don't address a person directly, maybe someone else would have helped, but now you scared them away :P

also, the message path is part of the whole visual app stack structure. You said you don't do that, but are creating websites. But if you are using revServer, there is no message path for that at all, and you actually can't use any of this?

You where right on the send part not accepting arrays, i never realised that, funny.

For passing variables to functions and commands, also look at the dictionary entry for @. Fancy stuff.

all things that have scripts can have a behaviour, even images. And behaviours run as the object they're set as behaviour in, not a referring one (maybe you mean the same thing. But I see referrer as the originator of a call. For example, when using send, there's a receiver and a caller, so to say.)

There's 2 types of handlers, functions and commands, both are interchangeable considering the message path, with the caveat that you can't send or call functions. handlers are run by just using their name, while functions behave like a container (sort of).

Both functions and commands can be "private", which means they ignore the message path, and are only available to the script of the object they're in themselves (caveat: behaviour are equivalent to being in the same script). If a command is not used outside of the single object, it makes sense to make it private, because that gives you speed benefits.

Note that these are very advanced parts of the message path, it's easies to ignore them, and just go with the singular flow idea (maybe add send for noncontinuous stuff ), because that'll get you into almost all tasks easily.


On 22 May 2011, at 20:49, Keith Clarke wrote:

> Björnke,
> Thanks for the feedback:
> 
> Libraries: I have tried to clarify the ambiguity here - between the Library Stack position in the message path and mechanisms for accessing library capabilities in stacks.
> 
> Behaviors: I have clarified the wording of how behaviors sit on buttons and can be referenced by several types of UI control or Group.  
> 
> Nested Groups: I've sorted nested Group recursion! ;-)
> 
> Send: Maybe I'm behind the times here, as I was quoting the send limitations cited at RunRev Live 09, (which are in line with the current dictionary definitions). Please point me to information on 'send with someArray' :-)
> 
> MVC = Model-View-Controller: It's a highly popular architecture/framework/pattern for web application design and integration. As web apps and web service integration are the primary focus areas for my LiveCode projects and products (and my limited coding background is with HTML, CSS and SaaS apps) - it makes sense for me to structure my code using this pattern. It's popular with quite a few others in the community from what I read (I won't cite Trevor Devore's RunRev Live 11 presentations yet again!) but it's perhaps less relevant for those building thick-client apps for desktop or mobile devices.
> 
> Here's the link to my revised map http://db.tt/HCgxmHk (if you haven't lost the will to live yet after reading all this ****!)
> 
> If it is anywhere near making sense by Saturday, I'd be happy to talk through it :-)
> Best,
> Keith..
> 
> 
> On 22 May 2011, at 14:56, Björnke von Gierke wrote:
> 
>> I'd say there's still lots of things wrong :)
>> 
>> --
>> you say that call and send only pass strings, but they can pass aynthing, including binary and arrays, so that seems to be wrong to me.
>> 
>> you say that you call librarystacks, but it's way easier to just let messages fall trough to them, because they're in every objects message path, for example: 
>> put functionInALibraryStack("parametertext",anArray) into theResult
>> 
>> Incidentally, librarystacks are missing in your messagepath (after mainstack, before backscripts)
>> 
>> In theory i like the "can be" connection between stacks and library stacks, but then mainstacks can be librarystacks too. also _everything_ that has a script can also be a front or backscript, so... dunnow.
>> 
>> you omitted behavior buttons.
>> 
>> where's parent of parent group ;)
>> --
>> 
>> i guess there's more that i didn't see, but the messagepath is really a beast, especially if one is not used to its way of thinking. Incidentally, what is a MVC, and why are you trying to create one?
>> 
>> you didn't say if you'd do a presentation next saturday, please confirm with a yes or no :)
>> 
>> 
>> cheers Björnke
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list