Would it be possible to make the C# bindings a little bit more developer friendly, specifically to aid testing?
I want to be able to test my code without having physical controllers but this is very hard with most of Phidget22 code being declared 'internal', no interfaces, etc.
My suggestion - that would be minimal changes is:
1. Event arguments, e.g. VoltageInputVoltageChangeEventArgs or StepperPositionChangeEventArgs should not have constructor marked as internal but public so the developer can instantiate new StepperPositionChangeEventArgs() and pass it as args without writing a wrapper first.
2. Most existing internal methods should be declared as protected virtual so the customer/developer can override if they want to (useful for testing/mocking)
3. The C# library should include interfaces as this is in spirit of C#. For example, there should be IPhidget, IStepper, etc. Obviously the customer can define their own interfaces for Phidget classes, but it risks breakage if the API changes, and it is not really something for customers to do as it is tightly related to the API. It should not be a massive effort either. This would help tremendously in dependency injection and similar.
I believe the above should not be a very big task/change and would not negatively impact any existing customers or code.
If there was a prioritisation I would think (1) is probably the biggest blocker as it leads to creating many layers of pointles shims, whilst (2) and (3) may be easier to work around.
Products for USB Sensing and Control
