Some fundamental concepts

[uelandbob]

Right now, Command and On are synonyms of each other, but the manual encourages you to use On for system defined events and command for your own custom handlers.

Thanks Vanceone,
Yes I've seen the command used instead of on, and I've wondered why, but your explanation makes it clear

[jacque]

Commands can be pushed into the message path without any object/target at all.

Don't know exactly what you are referring to here. Do you mean something like "pass mouseUp"

Mostly I was thinking of a handler that just issues a command without any target specified. Like this:

Code: Select all

on myHandler
  doSomething
end myHandler

The "doSomething" message is sent through the message hierarchy from wherever it originates. It isn't targeted to any object, it just gets put into the queue and if there is a "doSomething" handler later in the message path it will be caught and executed.

I love when you are picky

Finally someone who doesn't get mad when I do that. Please come and talk to my husband.

Could you explain how the engines pushes the mouseUp message on the stack and what makes the handlers on the card and mainStack to be executed.

I should have said it better; the engine does send messages to specific objects sometimes but it varies. If a control receives a user event (like clicking on something or typing text) then the appropriate messages are sent directly to that control as you said, and then proceed through the hierarchy until they are handled or discarded. If there are no user events then typically the messages are sent to the current card, and proceed along the message path from there.There's at least one exception with players, where callbacks are sent to the player object even though the user didn't do anything. There are also a few differences when working with native controls on mobile, where event messages are sent to the object containing the script that created the control, which makes sense since native mobile controls aren't in the normal message path.

[uelandbob]

check this: http://www.fourthworld.com/embassy/arti ... _path.html

Hi Klaus ,

I've read that article before and read it now again. That article is worth reading many times

But I'm not sure that it answers Jacqueline's statement. She wrote

the engine does not send its messages to objects specifically. It pushes them into the message path

If the engine does not send its messages to the objects but pushes on the stack, then I would like know where and how the connection between the object script and what's on the stack happens.

[magice]

If the engine does not send its messages to the objects but pushes on the stack, then I would like know where and how the connection between the object script and what's on the stack happens.

I don't know if this will add to the conversation or not. When I try to understand abstract concepts I try to create a visual. In the case of the message path, I look at the diagram at the beginning of fourthworld's artical and I see a river. Th arrows are the flow of the current. the boxes are waterfalls. A turtle jumps into the river, and he becomes a message. At any of the waterfalls we can put up a turtle trap. by using "on turtle".

[uelandbob]

bold new uncharted territory with Version 8.0 - for a glimpse of what's coming see this video Kevin put together on the company blog:
http://livecode.com/blog/2014/07/08/the ... ts-themes/

Thanks for the link , I really enjoyed watching the video, and for what I could judge the wrapping is the right thing to do. For the last 4 years I have been working with iOS and Cocoa in Xcode. I saw firsthand how difficult it was program with Apple's frameworks. My original idea for turning to LiveCode was to use LiveCode for prototyping and then to make externals for adding the speed and other things that LiveCode didn't have, but the Apple's frameworks had. In that way I could reap the benefits of both worlds, I figured. Now if I understand it correctly it will be even more easy to integrate those two worlds, and that is great news.

[uelandbob]

At any of the waterfalls we can put up a turtle trap. by using "on turtle".

Thanks Magice. That's a great visual

But in this case what I would like to know is the gory low level details of how it is implemented. What is actually making the connection. Do we have some kind of message queue, and a process that picks the message together with the target(in this case the button) and then goes and reads the targets handler, and if nothing there goes to the card finds a handler then executes it. Meeting the pass command adds another message to the message queue and this time the target is mainStack, and so on.

[jacque]

Magice's visual is spot on. And wonderful. I like it.

Yes, there's a message queue and messages are flowing through it constantly. Where they begin depends on what triggered them (see my post above) but once they get put into the stream they flow along a pre-determined path which Richard's diagram specifies. They continue along the path until there's a handler that traps the message. It stops there, unless there is a "pass" command, at which point the message continues along the same route. I don't know if the original message is removed and a new one generated internally, but it doesn't really matter. It acts like a single message as it travels along the stream.

If there are no handlers to trap the message anywhere along the way, it eventually makes its way to the engine and is deleted.

Do we have some kind of message queue, and a process that picks the message together with the target(in this case the button) and then goes and reads the targets handler, and if nothing there goes to the card finds a handler then executes it.

Pretty much. And if there is no card handler for the message, it proceeds to the background groups, and if nothing is there it goes on to the stack, and so forth.

[magice]

Thanks Magice. That's a great visual

But in this case what I would like to know is the gory low level details of how it is implemented. What is actually making the connection. Do we have some kind of message queue, and a process that picks the message together with the target(in this case the button) and then goes and reads the targets handler, and if nothing there goes to the card finds a handler then executes it. Meeting the pass command adds another message to the message queue and this time the target is mainStack, and so on.

It sounds to me like you want to know what the water is. I appreciate your curiosity, but to me, it is enough to think of it as the clear flowing essence of life that pours out from the spring and tributary that is the LiveCode engine, taking with it the occasional turtle or snake that originates from within the springs depths. I think what makes LC more attractive than other languages to me, is the fact that I don't need to understand exactly what the water is.

[Vanceone]

But in this case what I would like to know is the gory low level details of how it is implemented. What is actually making the connection. Do we have some kind of message queue, and a process that picks the message together with the target(in this case the button) and then goes and reads the targets handler, and if nothing there goes to the card finds a handler then executes it. Meeting the pass command adds another message to the message queue and this time the target is mainStack, and so on.

If you know much about objective C then I'm pretty sure you won't be intimidated by the real answer. My guess is that it is an event loop; since Livecode started back before OS X and is a descendant of Hypercard, it's probably a variation of the old "waitNextEvent" call from Carbon. Put briefly, what I'm sure happens is that the engine gets an event off of the system event queue--implementing waitNextEvent or possibly creating a Foundation queue (Foundation is a c only language; available on multiple platforms.) Once an event is registered, it's probably added to an NSArray or something; the target is calculated and then something like objc_message is called, repeatedly for each control in the message path until handled or passed.

At least, that's my guess without examining the source code.

[FourthWorld]

At least, that's my guess without examining the source code.

If so inclined:
https://github.com/runrev/livecode/blob ... tqueue.cpp

[uelandbob]

It sounds to me like you want to know what the water is. ... I think what makes LC more attractive than other languages to me, is the fact that I don't need to understand exactly what the water is.

I'm with you Magice, I do not want to know more then necessary either

I mean there are a lot of abstraction layers, from LiveCode, down to C and C++, down to transistors, and further down to quantum mechanics. We keep on the highest level that we can afford, in order not to miss the forest for the trees. But sometimes there comes an anomaly, something that disturbs your picture (model) on the current abstraction level. That is what happened to me when Jacqueline wrote

To be picky, the engine does not send its messages to objects specifically. It pushes them into the message path according to a pre-defined hierarchy and they travel from there.

Since Jacqueline is a very smart person with a lot of expertise I take her words seriously, and I thought that my picture of how things work in LC were perhaps wrong. I thought that whenever the engine generates a message and you trap it somewhere (doesn't care where) you can always call the function "the target" and there would be something there. I thought that her statement suggested that there are messages put on the message path without anything in the variable "the target" and that did disturb me and I wanted to know more. And sometimes to get an answer, you don't find it on the abstraction level that you are on, but must dig deeper. That was the only reason I wanted to know what the water was.

I am still not sure if there are target-less messages, and if anyone knows the answer please let me know.

[uelandbob]

I'm now looking at MessagePath and have come to controls. In Dictionary I read

A control is any object that can be placed on a card: a button, field, scrollbar, image, graphic, player, EPS object, or group.

Then I go to the tools palette and drag out a pulldown menu. The Object inspector says it is a button. But when I compare with the object inspector of a normal button the properties are not the same. For instance the pulldown menu has menuMode, while the normal button does not have it, instead it has style. I thought that a button was a button and that all buttons had the same properties. If I look at the Object/Button in the Dictionary I see that a button has both menuMode and style listed as properties. So it seems that the properties in the Object inspector only show a fraction of all the properties, and that someone decides (who?) which properties should be shown. And what if I want to change the property menuMode of a normal button, how do I do that. Can I change it programmatically or/and can I do it in the inspector itself?

[jacque]

I am still not sure if there are target-less messages, and if anyone knows the answer please let me know.

All messages begin somewhere along the message path, and the first one to receive that message is considered the target. So in that sense yes, all messages have a target.

[jacque]

So it seems that the properties in the Object inspector only show a fraction of all the properties, and that someone decides (who?) which properties should be shown. And what if I want to change the property menuMode of a normal button. Must I change it programmatically or can I do it in the inspector itself?

I have mixed feelings about this behavior. The IDE decides which button properties to show in the inspector. The tool palette presents what appear to be different types of buttons and fields, which are really just shortcuts for pre-defined properties, but to a new user it looks like there are different kinds of buttons and fields. There aren't; there is only one button and one field, and how they appear and behave depends on the properties that are set. This confuses many new users.

You need to use the message box or a script to set any properties the IDE doesn't show you. Not only that, not all properties are available from the inspector anyway, even if they do apply to the control you are editing.

[uelandbob]

I have mixed feelings about this behavior. ... to a new user it looks like there are different kinds of buttons and fields. There aren't; there is only one button and one field, and how they appear and behave depends on the properties that are set. This confuses many new users.

Thanks Jacqueline, this answer is crystal clear