SendCardMessage questions

[pderocco]

1) Does this require a freshly allocated string as its first parameter, which Revolution takes ownership of and eventually deletes? Or does it copy the data out of it, in which case the caller would have to delete it if it was dynamically allocated?

2) What context can this be called from? I would assume you couldn't call it from inside a hardware interrupt handler, because it would probably do something (allocate memory perhaps?) that's not legal inside a hardware interrupt handler. But how about in the context of some device driver thread? In particular, on Windows I'd like to call it from inside a MIDI input callback function, which isn't called by the main application thread, but isn't called in an interrupt handler either, so I assume it's a called by some thread associated with the device, or some multimedia thread in Windows.

2) What card does the message get sent to? The main stack's first card? Or does it depend upon what card is visible? What about if a dialog box is open?

Thanks in advance.

[Janschenkel]

1. Excellent question, it is not clear from the external.h header who has ownership. Given that SetGlobel makes a copy, my bet is that the engine would also make a copy of the message in SendCardMessage - but if no one can answer the question here, you could file a documentation 'bug' in the Quality Center.

2. The SendCardMessage callback should only be called while executing an external command or function. The rev engine is single-threaded and has certain expectations. A new externals interface is in the works that does allow multiple threads to send messages to controls, in a thread-safe way; it was previewed at the RunRevLive'09 conference, but did not ship with rev 4.0 and has been postponed to a future release.

3. The SendCardMessage callback will send the message to the currentCard of the defaultStack. This means, among other things, that you're not necessarily running within the context of the target that originally got the event message which triggered the external command/function call - e.g. if your button has a 'go next' right before the call to your external command/function, the next card will receive the callback message, not the original card.

HTH,

Jan Schenkel.

[pderocco]

Excellent answer. I guess it means that I can't do what I had hoped. It suprises me, though, that you can't post a message to Rev's event queue from another thread, because it is so easy to make thread get/put operations thread safe with a simple mutex. Oh well, thanks for your clear explanation.

[mwieder]

I've used threads in rev external for MIDI note-out processing, and it works but I'm not really happy with the results. I find it's better to let rev do the note timing. So threading in an external can certainly be done, but all the threading has to be in the external itself.

As Jan points out, there's a new externals api on the way, and hopefully that will allow us more flexibility.