The debounce algorithm can only be changed by adding a #define in the source file Bounce.h.
Selection of the debounce algorithm should be allowed from the sketch instead.
- The _debounce_ algorithm can only be changed by adding a `#define` in the source file `Bounce.h`.
- Selection of the _debounce_ algorithm should be allowed from the sketch instead.
A quick glance through the source tells me that this is because the defines are tested using precompiler statements in Bounce2.cpp instead of Bounce2.h.
An easy solution for this is to define each behavior in their own member functions and have an inline function in the header call the appropriate one based on the state of the precompiler definitions.
If these can be mixed within the same execution, making these individual functions public could allow users to call them depending on the desired behavior at any point during run, defaulting to the one specified by precompiler. If they can't be mixed, these should be made private or protected.
If more flexibility is desired, the desired method could be made an enumeration and passed as part of the constructor, so multiple Bounce objects could be instantiated using different methods for debouncing. This approach would break the existing interface as it pertains to selection of debouncing method.
If you'd like, I can try implementing the first method I suggested and create a Pull Request. I don't have a good way to validate the fix easily accessible, however.
A quick glance through the source tells me that this is because the defines are tested using precompiler statements in `Bounce2.cpp` instead of `Bounce2.h`.
An easy solution for this is to define each behavior in their own member functions and have an inline function in the header call the appropriate one based on the state of the precompiler definitions.
If these can be mixed within the same execution, making these individual functions public could allow users to call them depending on the desired behavior at any point during run, defaulting to the one specified by precompiler. If they can't be mixed, these should be made `private` or `protected`.
If more flexibility is desired, the desired method could be made an enumeration and passed as part of the constructor, so multiple `Bounce` objects could be instantiated using different methods for debouncing. This approach would break the existing interface as it pertains to selection of debouncing method.
If you'd like, I can try implementing the first method I suggested and create a Pull Request. I don't have a good way to validate the fix easily accessible, however.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
#definein the source fileBounce.h.A quick glance through the source tells me that this is because the defines are tested using precompiler statements in
Bounce2.cppinstead ofBounce2.h.An easy solution for this is to define each behavior in their own member functions and have an inline function in the header call the appropriate one based on the state of the precompiler definitions.
If these can be mixed within the same execution, making these individual functions public could allow users to call them depending on the desired behavior at any point during run, defaulting to the one specified by precompiler. If they can't be mixed, these should be made
privateorprotected.If more flexibility is desired, the desired method could be made an enumeration and passed as part of the constructor, so multiple
Bounceobjects could be instantiated using different methods for debouncing. This approach would break the existing interface as it pertains to selection of debouncing method.If you'd like, I can try implementing the first method I suggested and create a Pull Request. I don't have a good way to validate the fix easily accessible, however.