It's not configurable without rebuilding the library.
If you are filling the internal queue, you'll see an error event on your channel with type EEPHIDGET_DISPATCH. A bigger queue probably isn't the right solution - if you are doing blocking work in the event handlers, it would be better to move that work to another thread. When we want to deal with high data rates in the control panel, or internal tests, we generally fill a queue in the event handler, and then deal with the data in chunks from another thread.
Thanks for the suggestion, and actually already have long-running tasks run on a thread. Yes, I don't fully understand why my queue is filling up, so I am just looking at all options. I am getting the EEPHIDGET_DISPATCH error:
```txt
Phidget API emitted an error event with error event code 4 and error event description 'Current Input Ch:0 -> DAQ1400 -> HUB0000 Port:0 S/N:562433: Event queue is full; dropping event(s). Make sure data event handlers are fast and non-blocking, or reduce data rate.'.
```
> without rebuilding the library
Out of curiosity, how can one rebuild the library? Are there docs on this somewhere?
Sounds good on not distributing Windows or macOS source. In my use case, I am using Python 3.11 with Phidget22 package on Windows 10, with about 10 Phidgets connected running an instrument.
I think I have a multithreading issue somewhere in my application code such that one of the event handlers gets hung up or delayed too long over time (the queue randomly just fills up on day 2 or 3 of a run). I am separately investigating possible reasons for a multithreading issue.
