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 | ||
| Viewing Page 1 of 1 (Total Posts: 4) |
| Author | Comment |
Milos Cabel
Aug 22, 07 - 12:36 AM |
Recall more events at a time
Miro, I have a state machine which has to do something special in some cases, let's say goes to busy state. I don't want lost some events which can't be handled in busy state so I use defer(). But there is only one good place where to apply recall() method: in transition returning from busy. Is is safe to recall all stored events in recall method? In some do while loop until recall returns a valid pointer? |
Miro Samek
Aug 22nd, 2007 - 6:29 AM |
I guess the "massive recall" in a loop could work in that the internal reference counting inside QF should keep up no matter what (although I have not tested recalling of multiple events at a time). However, because the QActive::recall() method posts the recalled event using the LIFO policy, you will see reversal of the event order. But, I'd like to encourage you though to think a little harder on your design. You mention that you want to recall events on a "transition returning from busy". This is not the structure of the "Deferred Event" state pattern. The full structure of the "Deferred Event" state pattern is to defer the event in an internal transition of a high-level state, and recall the event in the *entry action* to the state which can conveniently handle that event. The main point is that you process the deferred events in exactly the same parts of the state machine as the events coming in the convenient time (when you're ready to handle them). This naturally establishes a "loop" for processing the deferred events, because after every such event you should eventually come back and recall some more events. I hope this makes sense to you. Miro |
Milos Cabel
Aug 22nd, 2007 - 7:18 AM |
Miro, thank you for immediate response. Problem was that the Busy state was something special and state machine usually sits in the "idle" state and it's substates without exiting it. Marketing forunately agreed with behaviour which don't need defer/recall mechanism any more. |
Miro Samek
Aug 22nd, 2007 - 2:59 PM |
Here you go Milos! I always thought that skillful negotiation with Marketing is the best way of solving any programming problems. Miro |
bravenet.com| Privacy Statement | About Us | Contact Us | © 2004-2005 quantum Leaps. All rights reserved. |