I am sure this is just being dumb. I have been working all weekend on admin which has rotted my brain.
The documentation for KbQueueCheck states
“Obtains data about keypresses on the specified device since the most recent call to this routine, KbQueueStart, or KbQueueWait”.
“since the most recent call to this routine” suggests that the time is relative to the last call. Not, an “absolute” measure of time.
To the best of my understanding this is not the case and KbQueueCheck reports “absolute time” (by whatever measure). This is also how KbQueueDemoPart2 works.
So it seems GetSecs and the time given by KbQueueCheck are from the same source. So, to my reading “since the most recent call to this routine” is a little misleading?
P
I am very confident that it is (absolute) GetSecs() timestamps, but the help text can indeed be misread, namely if one relates the “since the most recent call” not only to the word “first” but also to “time”. I just never read it this way.
It is absolute GetSecs time. What the sentence is meant to convey is that it returns the absolute GetSecs timestamps relating to new key activity (presses or releases) since the most recent preceeding call to KbQueueCheck, or since KbQueueStart, if this is the first call to KbQueueCheck. Iow. reporting state changes during the time period between the current n’th query and the previous n-1 'th query - or start of response collection if this is the first query.
I think the text read as a whole probably make sense, but the description of each returned timestamp vector could be a bit confusing, depending on how one reads it. Curiously, one of the help texts written by a native English speaker.
Any suggestions for a reworded text welcome.
I think quite often the KbEventXXX are more elegant to use, although they just expose the same collected data in a different way.
Actually the little “AI” language model integrated into the forum explains it better than I think I did. Citing: The phrase “since the most recent call to this routine” in the documentation for KbQueueCheck refers to the accumulation of keypress events, not the measurement of time. It means the function retrieves a list of all keypresses that have occurred on the specified device starting from the moment the queue was last initialized or cleared (via KbQueueStart, KbQueueWait, or a previous KbQueueCheck call), rather than providing an absolute timestamp for each event. While the documentation might seem to imply a time-based window, it is actually describing an event buffer that resets or updates based on the last invocation of the queue management routines, ensuring you only process new input since your last check.
In my tests with LLM’s, I see very mixed results. Sometimes excellent, but quite often also utterly misleading hallucinations with respect to technical content, but eloquently presented with tremendous confidence.
BTW, “Clears all scored events, but unscored events that are still being processed may remain in the queue“ might also be worth a clarification. I have no idea what “scored event” and “unscored event” are supposed to refer to. Possibly linked is ambiguity in the explanation of the “pressed” return variable: “a boolean indicating whether a key has been pressed“. For the boolean to be true, does this necessarily imply that the key was not pressed before the last call? Would it have to be released by now? Or, to the contrary, does it have to be still in the pressed state?
Regarding the AI response, I find the “rather than providing an absolute timestamp for each event” “clarification” rather confusing, because it IS providing absolute timestamps, but only for the events collected since the last call.
I will get some revised wording together.
P
Yes. I will work this into the re-wording. We all agree it is absolute time, so that needs to come over.
P