<snip>
I understand it's bad. All I can suggest you is: - do not create conflicts between an event and its base. I don't see how this could be a right design. - if you don't want event5 to come haunt you forever, stick to the UML conform deferring inside a state unless you really know you will get no transition conflict.
Ok if I use UML like definition for the event deferral than at least event 5 is not getting dispatched each time thanks for that. And actually I can leave with the situation that even1 is dispatched 2 times it only happens when no trans is taken in sub state machine so than it is not hurting. What I find disturbing that in this case the No Trans in not getting called ? Is it possible to fix at least this ?.
That no_transition is not called is actually normal as it's supposed to be an error, or at least a warning. The no_transition handler is never called on a submachine. Why? Because someone else might handle the event. To handle an event, msm follows the UML rule of "deeper first", so Inner1 gets first a chance to handle the event. If it doesn't, RunningStateMachine is tried. If it doesn't, SM1, and if it doesn't, then we get no_transition on SM1. An event is considered handled if a transition fires OR if a guard rejected it. no_transition only means "hey you made a programming error, nobody had even a chance to handle this". But you have a transition which handles event1 because of your baseEvent catch-all transition. Of course we are only a compile-time flag away from changing this but I don't think you'll be happy with getting tons of no_transition calls in Inner1 and RunningStateMachine for every event which was thought for SM1. The real issue is actually the double call. I need to think about it more, maybe there is a way for msm to handle this, I just didn't find it out yet. Regards, Christophe