messages path

[Mark]

Hi Bernd,

I'd call that a bug.

Best regards,

Mark

[jacque]

Hi Bernd,

If you want to mimic the HyperCard behaviour, the button that's part of the group should return

card
background

I don't believe background buttons in HC ever passed through the card. The messages went directly to the background, then to the stack. So the current behavior looks correct to me.

[Mark]

Jacque,

You don't see what the problem is. In HyperCard, once a message is sent to the background, it never goes back to the card before continuing to the stack. LiveCode's current behaviour breaks HyperCard stacks. This is incorrect. This is a bug.

Kind regards,

Mark

[jacque]

Jacque,

You don't see what the problem is. In HyperCard, once a message is sent to the background, it never goes back to the card before continuing to the stack.

Agreed. That isn't what you said in the part I quoted, which is why I commented.

[FourthWorld]

This may sound sacrilegious, but maybe HyperCard was wrong.

The notion of inserting or remove the script of one object (the card) from the message path of an object based on whether that object is a member of a different object (the background) seems an unnecessary ambiguity, and a particularly odd and disjointed one. Why would we not want a single message path for all objects on a given card?

So it breaks a few HC stacks. In mid-2011, what practical impact will that make?

Given that Apple killed HC more than a decade ago, anyone with HC stacks worth porting has probably already ported them to LiveCode, or SuperCard, or the web, or Flash. or something else. Apple hasn't even make a machine capable of natively running the OS HC requires for several years. It was a great tool in its day, but it's day has come and gone a very long time ago. How many stacks worth porting haven't been in all these years?

I would wager the material impact in LiveCode scripts for introducing this anomalous ambiguity from HC's legacy would be far greater than any material cost to what few remaining HC stacks there may be which depend on this oddity and haven't yet been ported to LC or something else.

[jacque]

This may sound sacrilegious, but maybe HyperCard was wrong.

The notion of inserting or remove the script of one object (the card) from the message path of an object based on whether that object is a member of a different object (the background) seems an unnecessary ambiguity, and a particularly odd and disjointed one. Why would we not want a single message path for all objects on a given card?

In HC the message path was pretty rigid, and there was a distinct difference between card and background objects. If an object was on a background, it was already behind the card layer, and it made sense that the card should not get any messages related to it. The message path was like this:

card control
card
background control
background
stack

Wherever you entered the message path, the flow went from there to the engine, and never circled back again. In LC, where the distinction between card and background objects isn't as rigid (and we don't even need to specify) the path can be more circuitous. In either case, the background/group will always get the message after the control does.

So it breaks a few HC stacks. In mid-2011, what practical impact will that make?

I have to agree with you here. As probably one of the few remaining people who still gets HC conversion work, I know that there are already enough tweaks required that having one more is hardly likely to matter. The first thing I do with a converted stack is to turn off HCAddressing, so the path issue is pretty much moot for me. I wouldn't ask the RR team to spend any time on this at all, the audience for it is so tiny and those of us who still do the occasional conversion can deal with it easily.