LiveCode Forums.

On p46 in User Guide it says that there you can import eps file

Imports the Encapsulated PostScript file you choose as a new EPS object on the current card. This item is only available on Unix platforms with Display Postscript installed. For more information, see the section on the EPS object

.

Does this mean that it is not available on Mac? (It does not appear in the menu) Also I can't find any section on the EPS object in the User Guide.

uelandbob wrote:On p46 in User Guide it says that there you can import eps file

Imports the Encapsulated PostScript file you choose as a new EPS object on the current card. This item is only available on Unix platforms with Display Postscript installed. For more information, see the section on the EPS object

.

Does this mean that it is not available on Mac? (It does not appear in the menu) Also I can't find any section on the EPS object in the User Guide.

I believe Mac uses a different variant of NeXT's Display Postscript, so the old EPS import is not expected to work on Mac systems.

EPS is not as widely used these days anyway. The more modern SVG is likely to appear in a future version of LiveCode, given the broad availability of source for that and LiveCode's use of the Skia vector engine. Not sure when; anyone have time to contribute that code to the code base?

Looking at

http://fourthworld.com/embassy/articles ... _path.html

and also at

http://lessons.runrev.com/m/4071/l/1178 ... her-object

It seems that the target of a system message is

1. a control.
2. a card.

No other objects are permitted (If we disregard send command), not stack, not group, not background, etc. Is that so?

Hi,

I believe you are correct.

Controls can be targets because, well, just because. A group will not be the target if you click outside any control in that group. So if you had, say, a "mouseUp" handler in a group script, you still have to click on a control in that group to send the message. (I think this is true).

Going up the hierarchy, other messages, if appropriate outside a control, are always sent to the card. Never directly to the stack, and it would make no sense for the engine to generate a message that it sent to itself.

Craig

uelandbob wrote:It seems that the target of a system message is
1. a control.
2. a card.
No other objects are permitted (If we disregard send command), not stack, not group, not background, etc. Is that so?

Not entirely. Diagrams can be helpful for visualizing some aspects of systems, but are rarely complete representations of all aspects of a system. This is true with both of the LC message path diagrams you've found. If they attempted to represent all possible features of the language they'd have to be so complex as to lose their communicative value.

In general, messages are send to the object to which they're most relevant. Mouse and keyboard actions make sense as starting at the control, but preOpenCard or openCard make sense to send to the card, since they involve no specific control.

Also, in LC backgrounds are groups, which can be used as custom controls, so they get messages like resizeControl, openControl, and others.

So while its true that most stack-related messages like preOpenStack and openStack are sent to the card so we have the option of handing them differently for each card if we choose, there are a few exceptions.

For example, the startup message is sent to a stack. There may be others; I'd have to look into it, and there's the key:

C has only 27 keywords, which may make it superficially appear to be a very easy language to learn. But in practice the range of things people do with it is much broader than just 27 keywords can deliver, so most need to learn at least stdLib, and often some framework like Cocoa, and each new layer multiplies the number of things that must be learned.

To varying degrees this is equally true with Python, R, and most other languages, including LiveCode, in which core principles attempt to make the language learnable yet the needs of application developers require the designers of the language to extend it in ways that often go beyond the ability to explain everything useful about the language in a single diagram or single-page summary.

So when we get started building an application in a language that's new to us, it's helpful to review general principles guiding how it works, like chapters 3 and 5 in the LC User Guide. As we get into the details of our application, we'll want to keep the API reference handy; in LiveCode this is the Dictionary.

What do you want to build?

FourthWorld wrote: Not entirely. Diagrams can be helpful for visualizing some aspects of systems, but are rarely complete representations of all aspects of a system. This is true with both of the LC message path diagrams you've found. If they attempted to represent all possible features of the language they'd have to be so complex as to lose their communicative value.

I with you Richard To have a model of what is going on in a complex system is of vital importance. A model is simply a simplified picture of an existing or imagined reality, so that you can make prediction of what is going to happen in this complex reality by studying the model. In fact we humans can only think in terms of models. The reality is to complex to comprehend by our limited brain, so we make models of reality. Some models are good and useful, for instance Newtons model of gravity, other models are less useful, like thinking that star positions or gods run our lives in mysterious ways. Why is Newtons gravity model more useful then the astrology model or god model. It is not because gravity model is more true (I mean gravity is just a concept it's not out there where you can see it or touch it) then god model. Instead it is more useful since you can predict better what will happen in the reality by using gravity model then the god model. Once again, models are not true, they are just more useful, more convenient. If two models predict the same thing, you should choose the simpler one. Because simpler is more convenient. Hence Kepler's model did not predict better then Ptolemios', but it was simpler, hece more convinient, hence more useful.

So while its true that most stack-related messages like preOpenStack and openStack are sent to the card so we have the option of handing them differently for each card if we choose, there are a few exceptions.
For example, the startup message is sent to a stack. There may be others;

I went to Dictionary, clicked on Stack and the clicked on the Type column. That sorted all the keywords so I could see all messages sent to Stack on the bottom. That can be done for Cards, Groups and all the others, and gives a nice overview. For me those messages are the true key for getting most out of LC.

What do you want to build?

I have a lot of ideas, but that will come later. Now, I'm just playing with LC, building toy projects to explore the structure and boundaries of LC.

Thanks again for your help Richard.

In other words, you are grokking how to grok it.

Just to disrupt the common model: preOpenStack and startup messages are sent to the first card, though it's convenient to think of them as stack messages. I've placed startup handlers on card 1 and they trigger.

jacque wrote:...startup messages are sent to the first card....

I don't believe I've ever tested this, but the Dictionary entry for "startup" says:

Sent to the first stack opened when the application starts up.

Should I file a bug on that dictionary entry?

Well, it is sent to the first stack -- via the card. But we should re-test it before filing anything, and technically it isn't wrong. The distinction is pretty minor.

It's minor, but having the option of handling it at the card level can be very useful, so erring on the side of completion I filed a bug report: http://quality.runrev.com/show_bug.cgi?id=14363

Jacque, as usual, knows better.

So can it be said that there is no "stack" at all without a card in existence, a card to provide the actual substance of the stack object? The question may not be sound or pertinent, but does it make sense at all? One thing is certain, a "preOpenStack" handler in the card script, from a new session with the stack in question opened from the finder. catches that message.

I am not sure which way I want this to go. You can always place the handler in the stack script, so it probably is merely superfluous if it can be trapped in the card. Or is it? Is there a downside to NOT being able to trap this in the card?

Craig

All these years I used to think that the message order was always the "pre" command followed by the "open" command, in this order:

startup
preOpenStack
openStack
preOpenCard
openCard
preOpenBackground
openBackground

That model still works most of the time, but Mark Waddingham corrected me the one time it caused my script to fail. All the "pre"s come together at once, followed by all the "opens". This is what he said, "...preOpen messages happen before open messages - this is because 'open' handlers happen after the stack has been displayed. If preopenCard happened after openStack, then the card would already be visible on screen before its preOpenCard handler ran which would be wrong."