Search the Forum for answers or post your questions to the
Quantum Leaps community
 |
 |
|
| Home | | | Products | | | Services | | | Downloads | | | Licensing | | | Developer Zone | | | Resources |
 |
| Overview | | | Discussion | | | Cookbook | | | Design Patterns | | | Bugs | | | Contributions | | | Credits |
Quantum Leaps Discussion Forum
Search the Forum for answers or post your questions to the |
||
| Return to Website | ||
 First |
 Prev |
 Reply |
 Forum |
Next  |
Last  |
| Viewing Page 1 of 1 (Total Posts: 2) |
| Author | Comment |
bill edmondson
Sep 7, 07 - 4:19 PM |
providing data to the new state and retaining 'instance' data
imagine i have a source of events that carries an 'instance' with it (the data portion of the event). processing of this event requires some background processing, etc, so i transition to another state to handle it. the new state needs to know the 'instance' to process the event appropriately. what is considered the correct way to do this? 1. save it as a class member available to both states 2. fire another event to the new state containing the instance data 3. some other way ... |
Miro Samek
 Sep 9th, 2007 - 6:05 PM |
Re: providing data to the new state and retaining 'instance' data
You are correct to notice that an event is only available during the run-to-completion (RTC) step, and is gone after the step. I see your problem coming up quite often in the designs. Quite often this type of problem has to do with confusing statecharts with flowcharts, but I'm not sure that this is the case here. If the information provided by the event is relevant for future processing, you should save it in an extended-state variable (state machine class member). For example, the QCalc state machine saves the arriving digits in the operand1 or operand2 extended state variables, depending on the state. One case is that you actually don't want to process the event in the current state, because it comes at an awkward time. Then you want to defer the event and recall later, at a more convenient time. This is the "Deferred Event" state pattern and the new version of QP supports this pattern much better (see the QActive::defer() and QActive::recall()). Finally, you might want to spread the processing of the event over multiple RTC steps. For instance, when you want to shorten a lengthy RTC processing for better processing. In this case you might post the same event to self and transition to a new state that "knows" that the event is posted again. Here you use a variant of the "Reminder" state pattern. The point is that the framework will handle correctly posting to self and will not recycle the event. I would not recommend juggling the same event too many times, though. Miro |
| First |
Prev |
Reply |
Forum |
Next |
Last |
bravenet.com| Privacy Statement | About Us | Contact Us | © 2004-2005 quantum Leaps. All rights reserved. |