hello

my application consists of a mfc gui and some logic modeled in rhapsody as a reactive class.
the rhapsody model is compiled as static lib (.lib) and the mfc app links it.
i followed the provided rhapsody examples for making the gui and logic communicate using events.

my problem is that when the dialog generates events i witness serious delays in tasks that are performed
as a result of those events. but when i don't use events and instead call directly a method in the mentioned reactive class
there is no delay at all.
is the solution using triggered operations? if i use them instead of events the delay problems are solved but other problems arise,
for example disregarding completely a timeout ( tm(250) ) i have set in the statechart.

changing the concurrency of the reactive class from sequential to active didn't help either.

any special settings I should set, or guidelines to follow to make this work?

thanks

which VS Version are you using ?

2005

What dimensions of delays are you talking about?
Is it milliseconds, several 10 milliseconds, several 100 milliseconds or is it in the area of seconds?
What is the overall system load?
How many threads are involved and what are their priorities?


Triggered operations may be one possible solution, but are not neccessarily the only one.

If you want to use Triggered operations and Timeouts in parallel, then you have to set the property CG:Operation:Concurrency to guarded for all triggered operations in order to protect them against each other.

If you do not set this, then the Statechart code might be called from two threads in parallel - your Gui context for triggered operations on one hand and the OXF main thread for asynchronous timeout events on the other hand.
A second call will always be disregarded while the statemachine code is actively called from a different thread (if not guarded).
Overloading OMReactive::handleNotConsumed(...) may be used to identify such situations at runtime.


Did you assign an appropriate priority to that active class via properties in CG:Class:ActiveThreadPriority?
The behavior of that active/reactive class has be started properly using 'pObject->startBehavior()', I guess?

Hope those suggestions can help you to track this down.

Regards,
Luke.