Version: SU13
Frequency: Consistently
Severity: Low
Context: SimConnect API new Input Events
Bug description:
This is not really a bug per-se, but if it’s a design decision then it would be nice to clear that up explicitly.
The API is inconsistent between SimConnect_GetInputEvent and SimConnect_SubscribeInputEvent
- With
GetInputEvent()we specify the Hash, and a request ID to use in the response (like other API functions).- Then in the response we get only the request ID back: SIMCONNECT_RECV_GET_INPUT_EVENT
Which is OK I guess, because we’re used to tracking our requests by ID anyway. Though the lack of the hash ID here seems like an omission.- (BTW, the URL for this doesn’t match the struct name, and all links to it from the docs point to the wrong (missing) link.)
- Then in the response we get only the request ID back: SIMCONNECT_RECV_GET_INPUT_EVENT
- With
SubscribeInputEvent()we can only specify the hash (or zero). No request ID?- Correspondingly, in the response struct we get only the hash ID as a way to identify the request:
SIMCONNECT_RECV_SUBSCRIBE_INPUT_EVENT - So internally we now have to track the requests by the 64-bit hash ID so we know what we’re getting (assuming subscribing to individual event values, anyway).
- Correspondingly, in the response struct we get only the hash ID as a way to identify the request:
- Between the two, we have to track “Get” vs. “Subscribe” requests in two different ways, even though they’re going to be representing the same value. Likewise the code handling the two different response structs needs to be subtly different, which seems awkward for no apparent reason.
Thank you,
-Max