Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QStateMachine Order of Event Handling
Forum Updated to NodeBB v4.3 + New Features

QStateMachine Order of Event Handling

Scheduled Pinned Locked Moved Unsolved General and Desktop
3 Posts 2 Posters 680 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    AccWhid
    wrote on last edited by
    #1

    I had a question about the order of event handling in QStateMachine. I have noticed that it seems signals are always handled before events posted via postEvent. For example, if an event is posted while a state is in an onEntry handler that emits a signal the state machine processes, the state machine will always process the signal first before the posted event, even if the event is posted before the signal is fired.

    Is this behavior expected? Can I rely on it always being true?

    Thanks!

    VRoninV 1 Reply Last reply
    0
    • A AccWhid

      I had a question about the order of event handling in QStateMachine. I have noticed that it seems signals are always handled before events posted via postEvent. For example, if an event is posted while a state is in an onEntry handler that emits a signal the state machine processes, the state machine will always process the signal first before the posted event, even if the event is posted before the signal is fired.

      Is this behavior expected? Can I rely on it always being true?

      Thanks!

      VRoninV Offline
      VRoninV Offline
      VRonin
      wrote on last edited by
      #2

      @AccWhid said in QStateMachine Order of Event Handling:

      Is this behavior expected?

      Yes, if sender and receiver in signal/slot are on the same thread (Qt::DirectConnection), emitting a signal is equivalent to calling directly the slots in the order they where connected. Events are processed when the program handles control back to the event loop (or QCoreApplication::processEvents() is called).
      signal/slot connected in different threads or with Qt::QueuedConnection will be delayed at the same time as events are processed.

      Can I rely on it always being true?

      You can but it's not a super solid design choice

      "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
      ~Napoleon Bonaparte

      On a crusade to banish setIndexWidget() from the holy land of Qt

      1 Reply Last reply
      3
      • A Offline
        A Offline
        AccWhid
        wrote on last edited by
        #3

        That's what I thought, but I wasn't sure if the state machine might be re-posting signals as events on the state machine's event queue that would then be handled.

        1 Reply Last reply
        0

        • Login

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • Users
        • Groups
        • Search
        • Get Qt Extensions
        • Unsolved