FrontScript message path confusion

[trevix]

LC 9.6.0 Dp4
I am trying to find out why the message path in my stack (in the IDE) doesn't follow what I think it should.

As from the clear Fourth World explanation, this is the message path for FrontScripts:
https://www.fourthworld.com/embassy/art ... _path.html

mess_path2.gif (8.82 KiB) Viewed 6401 times

Now, in my stack, I had to implement the schema of below. The "ReceiveSomething" command is triggered by an external and the front script receive it fine.
The problem is that the "DoThis" command does not reach the Behaviour script of card B. On the debugger the instruction line of "DoThis pValue" of the FrontScript does not report any error, but won't trigger the command of the Behaviour script.

Can please someone clarify me what am I doing wrong? Thanks

[FourthWorld]

The problem is that the "DoThis" command does not reach the Behaviour script of card B.

What does that mean? Does card B use a behavior script, or is there an attempt to use it as the behavior script for the object receiving the message?

If the latter, the remedy is simple enough: buttons and stacks can be used as containers for behavior scripts, but not other object types like cards.

[trevix]

Hi
Card B use a behavior script: Button ID xxx of stack "Main Stack A"

[trevix]

So I guess the question is: can I, from a FrontScript, fire a message to a card, that has a behaviour, using the regular message path (without using send "...")?

[FourthWorld]

So I guess the question is: can I, from a FrontScript, fire a message to a card, that has a behaviour, using the regular message path (without using send "...")?

In that diagram card B is in a different stack from the one where the messages originate, so I'm not clear on how this is supposed to work.

Maybe for slowpokes like me you can start more simply: what do you want to do?

[SparkOut]

I think we need to see more of your code to understand what you are doing and what you have in mind compared to what is actually happening. I "think" the answer to your question is yes, but I don't know how you are using the message path to have put the handler in play. Ultimately "send" is not an undesirable if it's needed. But it's hard to tell whether it's needed with your setup.

[edit]As if the message path guru is a slowpoke, ha![/edit]

[trevix]

My App is to complex to be reduced to the point, so I've put together a test stack, that I hope will be self explaining.
Of course I could use "Send" or "Dispatch", but latency in my App is very important so I am trying to fasten thing as much as possible.

[trevix]

One more thing:
you have to imagine that the "ReceiveSomething" command, that has to be available all over the App, comes from a LC external (in my case a bluetooth external)

[LCMark]

@trevix: You have a frontscript which does:

Code: Select all

on ReceiveSomething
  doThis
end ReceiveSomething

Then doThis is implemented in a behavior which is attached to a button in another stack.

Unless the button with this behavior is the target of the 'ReceiveSomething' message, then 'DoThis' is not in the message path when the message fires - regardless of where it comes from (which is why your code doesn't work - but the 'send' form you have commented out does). FrontScripts sit at the front of the message path so they can intercept anything but they don't change what happens afterwards - that all depends on the target.

The target of the 'ReceiveSomething' message will depend on what is firing it - most LCB libraries will bind 'to something sensible'. For example the FLIC library (which I'm guessing is what are you using here) sends its messages to the object which called the 'initialize' method. So you don't necessarily need a frontscript - you just need to add a handler to that object's script which relays the message to where you want it to be handled.

[trevix]

Ah! I guess I misunderstood the message path of FourthWorld schema: "FrontScript" > "Card"
The card referring to, is the card of the object whose script is put to the front.
As you said

FrontScript...can intercept anything but they don't change what happens afterwards

Thanks