What are eventData actual types for LWEVNT_{TIME,SELECT} "MasterHandler" events?

jwiede

Electron wrangler
What are eventData actual types for LWEVNT_{TIME,SELECT} "MasterHandler" events?

With "MasterHandler" events, each eventCode has a corresponding eventData data type or structure. The eventData is defined as void * in the docs, and neither eventCode LWEVNT_TIME nor LWEVNT_SELECT docs define the meaning of the data contained in eventData, nor its type.

I'm filing a bug on the docs (which should include this info, the whole thing is woefully under documented), but in the mean time, does anyone here know the type of eventData returned with LWEVNT_TIME and LWEVNT_SELECT events, and/or what that data represents? I'm guessing LWEVNT_TIME provides the new frame slider or time value somehow in eventData, and LWEVNT_SELECT provides the selection, but am unclear about the actual types/structures used.

Thanks!

(edit) After looking at the Python docs for the equivalents, based on the Python helper functions provided (specifically data_as_time() & data_as_itemid()), I think the answers for LWEVNT_TIME & LWEVNT_SELECT may be double and LWItemID respectively. Can anyone accurately confirm or deny those types?
 
Last edited:

Jarno

Post-LW Engineer
For LWEVNT_TIME it is a pointer to an LWTime (which is indeed a double).
LWEVNT_SELECT appears to always use NULL as data. It indicates that the current selection has changed, which may involve any number of items.

---JvdL---
 

jwiede

Electron wrangler
For LWEVNT_TIME it is a pointer to an LWTime (which is indeed a double).
LWEVNT_SELECT appears to always use NULL as data. It indicates that the current selection has changed, which may involve any number of items.

Jarno, good to hear for LWEVNT_TIME, is what I expected.

What you've described is kind of a problem for LWEVNT_SELECT, though, don't you think?

For starters, it breaks the model that the code is the verb and data the direct object, which holds for the other event types. Also, unlike the other basic events, that means LWEVNT_SELECT isn't "self-contained" -- it requires using other (non-provided) interfaces to acquire the actual change info for the basic event. That seems problematic in a couple of ways:

1. There's no user context passed in the event, so no non-static/-global means of passing arbitrary interfaces, nor do the interfaces supplied (lookup(), execute(), and evaluate()) provide a means of acquiring the selection info. Requiring for just one basic event code that interfaces be available as statics or globals is neither orthogonal nor particularly flexible.

2. You could argue the handler should instead just flag that selection changed, and determine actual selection changes at "point of use" code, but that forces a "pull-model" interaction for selection updating (w/ negative multithreading implications). At that point, the LWEVNT_SELECT event/msg code path exists solely to set a flag that change has occurred, and the entire event/msg handler essentially becomes "overhead". Either way, the actual "point of use" code winds up having to poll on a variable or function to determine whether to process selection change (an inefficient approach, to say the least).

I'm really unclear why LWEVNT_SELECT was implemented in that manner, event code forcing pull-model seems pointless. Was that the case since implementation? It doesn't appear like the Python version was intended to work that way -- otherwise what other basic event/msg needed the data_as_itemid() helper? Is there at least any comment in the implementation about why it was done that way?

Thanks for the info, in any case!

-John W.
 
Last edited:

Jarno

Post-LW Engineer
I can only guess at the motivations of many, many years ago.

Typically the way it happens is that someone needed an event to indicate that there was a change in the current selection, in order to refresh something. They didn't need to know what the change was exactly, just that there was one so that they can refresh or rebuild something. So that is what got implemented and the developer moved on to the next issue in a long, long list of issues.

An additional factor is where the LWEVNT_SELECT master event gets generated. It is typically triggered by Layout redraws done for selection changes. By the time that redraw happens it is not easily possible to determine what selection changes were made, only that there was one (or something wanted the system to behave as if there was one).

---JvdL---
 

jwiede

Electron wrangler
I can only guess at the motivations of many, many years ago.

Typically the way it happens is that someone needed an event to indicate that there was a change in the current selection, in order to refresh something. They didn't need to know what the change was exactly, just that there was one so that they can refresh or rebuild something. So that is what got implemented and the developer moved on to the next issue in a long, long list of issues.

An additional factor is where the LWEVNT_SELECT master event gets generated. It is typically triggered by Layout redraws done for selection changes. By the time that redraw happens it is not easily possible to determine what selection changes were made, only that there was one (or something wanted the system to behave as if there was one).

Understood! Polling's a bit unfortunate as we deal with more and more discrete threads being involved, but definitely not a deal-breaker. Thanks for the info!
 
Top Bottom