Confusing AND illegible - that's more over-complication than I had hoped to achieve first time around! ;-)
Thanks for the message path breakdown - and good point well made regarding 'send in time' It's very interesting that your list, like Richard's diagrams takes a more abstract 'class-level' logical model of the message flow - through the various containers (whether the developer has instantiated anything in them or not). It's probably about differences in 'brain-wiring' but I find that level of abstraction too difficult, when learning new concepts, training others or (the real purpose for my map) deciding where to hang the various lumps of code for my MVC application architecture. So, my map is based on a slightly more concrete 'object-level' model, where the message flows involve only those classes that have been instantiated. I will update the map to show message flows through both 'container classes' and 'instantiated objects'. That way, I should be able to confuse all of the people, all of the time! Maybe a Saturday evening presentation - now there's a threat ;-) Best, Keith.. On 20 May 2011, at 13:39, Björnke von Gierke wrote: > I think your example is confusing and unlegible :) > > generally, nothing ever is skipped, but the arrows in your graph seem to > indicate that a lot of things go past controls? Basically you can write the > message path as a single line. It is an example where the message goes to the > object. Of course messages could also go directly to cards, groups or stacks > > message goes trough: > front scripts, if passed or unhandled goes on to > target object script, if passed or unhandled goes on to > behaviour script, (if existent) if passed or unhandled goes on to > group scripts, (if existent) if passed or unhandled goes on to > card script, if passed or unhandled goes on to > stack script, if passed or unhandled goes on to > background scripts, (only if hcaddressing is on) if passed or unhandled goes > on to > mainstack script, (if existent) if passed or unhandled goes on to > stacks in use scripts, (if existent) if passed or unhandled goes on to > back scripts, (if existent) if passed or unhandled goes on to > engine, (if handled by it, otherwise error) > > your "breaking the path" part seems to be correct, but you missed the single > most advantage of "send", which is the "in <time>" addition. > > > On 20 May 2011, at 12:59, Keith Clarke wrote: > >> Hi folks, >> In attempt to get my head around behaviors, I have revisited Trevor DeVore's >> Live 09 presentation on Behaviors and Custom Controls and put together my >> own map of (my understanding of) the 4.6.1 message path with standard and >> optional objects http://db.tt/dUrt0nL (Having seen great top-down and >> bottom-up examples, I thought I'd go left-to-right!) >> >> Is my map correct concerning the behavior feedback loops? Trevor spoke of >> the calling object 'getting first dibs' on the behavior's script, but Figure >> 3 of Richard Gaskin's excellent resource on the message path >> http://www.fourthworld.com/embassy/articles/revolution_message_path.html >> shows only flow towards the engine (maybe feedback loops were omitted for >> clarity?). >> Best, >> Keith.. >> _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
