while (ConnexionReadEvent(&event) == EVENT_WAS_READ)
useThisEvent = event;
The device delivers data at approximately 60Hz. I'd say that anything older than 1/60 of a second ago, that does not have all-zero values, will shortly be followed up by another event. If the values are all-zero, the next event would be the next time the user touches the cap.davecotter wrote:i was afraid you might say that. bummer.
1) if there is a precise definition of "too old" this might work, but it'd be far too easy to process events you don't need to, or actually miss the last event that you actually want. Due to the realtime nature of whatever calculation we're doing, every event may seem "too old".
This isn't our API nor functionality. These are just simple wrappers over the OS-X platform. I do see where this is a place we could try to improve the Apple API, though. I am sure you are correct, that this sort of thing hurts us, preventing others from incorporating support for the products. We did provide a solution for this on Windows. I will look into a better solution for OS-X. The failure of this project should help me to get resources to provide a better solution.davecotter wrote:i'm amazed that there is no simple, cross platform command for your API that says "flush everything", or a way to say "only hand me the most recent event if there are more than one in the que". this is really a requirement for simple adoption.
#define kNanoSecondsPerSecond 1000000000
#define kMilliSecondsPerSecond 1000
#define kNanoSecondsPerMilli (kNanoSecondsPerSecond / kMilliSecondsPerSecond)
static bool IsMostRecentMessage(UInt64& messageT)
UInt64 dur_message_milliT(dur_message_nanoT / kNanoSecondsPerMilli);
UInt64 dur_tick_milliT(kMilliSecondsPerSecond / 60);
bool recentB = dur_message_milliT <= dur_tick_milliT;
davecotter wrote:apparently, see enhancement request 4503
Users browsing this forum: No registered users and 0 guests