On Wed Jun 21 12:22:14 2023 +0000, Connor McAdams wrote:
The idea of storing it in a VARIANT is that we can use one generic structure/variable for both clientside and serverside events - a serverside event posts a VARIANT containing an HUIANODE pointer, and a clientside event posts a VARIANT containing an lresult that can be converted into an HUIANODE. I spent time thinking about this when I designed it, there's a possibility of a delay when converting the lresult into a node. This could cause events to be put into the queue out of sequence, e.g:
- Event 1 arrives, calls `uia_node_from_lresult()`
- Event 2 arrives, calls `uia_node_from_lresult()`
- `uia_node_from_lresult()` returns for event 2, it gets posted to the queue.
- `uia_node_from_lresult()` returns for event 1, it gets posted to the queue.
So IMO, it's best to just post the lresult for the node to the queue quickly and let the event thread do the conversion. We could also add different structures for each, or a union depending on the type of event in the queue.
I thought about this a bit yesterday before pushing this branch, it would be nice to have a corresponding node AddRef inside of `uia_event_queue_post_event()`, but that'd add a bit of ugliness here IMO. We'd have to check the event type, get the node out of the variant, and then addref it. I guess if we had separate functions/structures for posting serverside vs clientside events to the queue it would be cleaner to do.