This thread reminds me of something I would like to understand better.
I currently have several custom handlers and 2 or three system message
handlers that I use in multiple applications. At the moment, I keep them in
a library stack and insert them all as front scripts in my startup
processing f
Send has an "in time" clause that allows you to delay the sending of the
message - dispatch doesn't have that. In some circumstances, datagrid
messages need to be sent with "in zero seconds" (more info in the Datagrid
Tutorial at
http://lessons.runrev.com/spaces/lessons/manuals/datagrid/lessons/73
Todd Geist wrote:
For example, I am reasonably certain that I will never need to write code
that is compatible with HyperCard, So does that mean that I never need to
use Send, and I can always use Dispatch?
The "send" command has one feature unique to it: the ability to delay
its triggering
This last little post by Richard makes me think of JavaScript, The Good
Parts, by Douglas Crawford.
Crawford lays out a case for which parts of JavScript should be used and
which are to be avoided at all cost. I wonder if something similar could be
done with LiveCode. Or perhaps just a guide to
Thanks for that clarification Richard - and your message path article that
helped me get underway with LiveCode.
Backward compatibility is always challenging, though perhaps slightly easier
than predicting future compatibility!
Best,
Keith..
On 23 May 2011, at 19:03, Richard Gaskin wrote:
>
Keith Clarke wrote:
> It's clear now that my question, which sought factual clarification,
> has raised questions of LiveCode philosophy, developer perspective
> and architecture. There is clearly no single correct answer, no
> 'unified theory'.
There is a sense of theory about LiveCode's langua
Thanks for clarifying the library and front/back script order - more
'LIFO-type' behaviour http://en.wikipedia.org/wiki/LIFO_(computing) than just
random chunks of code in a bucket!
I think this thread has underpinned George Box's warning to “Remember that all
models are wrong; the practical qu
I agree with your assesment that the message path is so versatile and complex,
that it doesn't lead to a single ruleset, but to a dozen different valid usage
scenarios. But only if one chooses to use all these advanced capabilities. 90%
of my works is within the 'default' path, not using librari
Ken, thanks for the clarification on what can/can't be achieved with send - and
how.
I like the use of the value function to wrap a remote function, which produces
a kind of 'call, with (slightly fussy syntax) parameters' function -
reminiscent of some Excel cross-referencing functions.
Intere
> don't address a person directly, maybe someone else would have helped, but
> now you scared them away :P
Perhaps they're just enjoying the spectacle of yet another poor naïve fool
trying to boil the ocean! ;-)
It's clear now that my question, which sought factual clarification, has raised
que
On 5/22/11 6:50 PM, "Björnke von Gierke" wrote:
> wow that's f*** up. some things in this language makes me doubt that there's
> intelligent life out there :(
Well, I'm sure that's part of the reason why "dispatch" was added - which is
easier:
send "ShowName tNameA' to me
or
dispatch "
wow that's fucked up. some things in this language makes me doubt that there's
intelligent life out there :(
On 23 May 2011, at 01:19, Ken Ray wrote:
> Actually, "send" *does* accept arrays... it's just that you have to
> structure the send a little differently:
>
> on mouseUp
> put "Ken" into
> don't address a person directly, maybe someone else would have helped, but now
> you scared them away :P
Not all of them.. ;-)
> You where right on the send part not accepting arrays, i never realised that,
> funny.
Actually, "send" *does* accept arrays... it's just that you have to
structu
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 messag
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 refe
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 the
Ah, thanks, Björnke - you have successfully reset my frame of reference for
this now. The message flow passes through ALL the various set containers
whether or not there is a handler to catch (and optionally, pass) the specific
message.
I had the wrong model in my head from my initial research
On 20 May 2011, at 15:45, Keith Clarke wrote:
> 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 ap
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'
Thanks Trevor - that's very clear. I'll update my map accordingly.
Best,
Keith..
On 20 May 2011, at 13:38, Trevor DeVore wrote:
> On Fri, May 20, 2011 at 6:59 AM, Keith Clarke <
> keith.cla...@clarkeandclarke.co.uk> wrote:
>
>> In attempt to get my head around behaviors, I have revisited Trevor
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
On Fri, May 20, 2011 at 6:59 AM, Keith Clarke <
keith.cla...@clarkeandclarke.co.uk> wrote:
> 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
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-
23 matches
Mail list logo
