Especially since there is a Button class now, the hardware abstraction should be done by composition rather than inheritance. For example, it's not possible to define a Button instance that uses something other than digitalRead to read the state. What do you think?
Especially since there is a Button class now, the hardware abstraction should be done by composition rather than inheritance. For example, it's not possible to define a Button instance that uses something other than digitalRead to read the state. What do you think?
https://en.wikipedia.org/wiki/Composition_over_inheritance
@KenwoodFox this can already be implemented. See the source for class Bounce in Bounce2.h.
You can set your custom override for digitalRead : virtual bool readCurrentState() { return digitalRead(pin); }
@KenwoodFox this can already be implemented. See the source for `class Bounce` in `Bounce2.h`.
You can set your custom override for digitalRead :
`virtual bool readCurrentState() { return digitalRead(pin); }`
@KenwoodFox this can already be implemented. See the source for class Bounce in Bounce2.h.
You can set your custom override for digitalRead : virtual bool readCurrentState() { return digitalRead(pin); }
This is pretty awesome! thanks so much.
> @KenwoodFox this can already be implemented. See the source for `class Bounce` in `Bounce2.h`.
>
> You can set your custom override for digitalRead : `virtual bool readCurrentState() { return digitalRead(pin); }`
This is pretty awesome! thanks so much.
@KenwoodFox this can already be implemented. See the source for class Bounce in Bounce2.h.
You can set your custom override for digitalRead : virtual bool readCurrentState() { return digitalRead(pin); }
Sorry to ask, but where would you implement this? Should this be done for every button instance you create or do i need to make my own button class using inheriting from bounce?
> @KenwoodFox this can already be implemented. See the source for `class Bounce` in `Bounce2.h`.
>
> You can set your custom override for digitalRead : `virtual bool readCurrentState() { return digitalRead(pin); }`
Sorry to ask, but where would you implement this? Should this be done for every button instance you create or do i need to make my own button class using inheriting from bounce?
It isn't a complete replacement because it doesn't have complex debouncing techniques, but the Debouncer library allows passing in the value to use.
It isn't a complete replacement because it doesn't have complex debouncing techniques, but the [`Debouncer`](https://github.com/apechinsky/arduino-libs/blob/master/Debouncer/examples/basic/sketch.ino) library allows passing in the value to use.
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.
Especially since there is a Button class now, the hardware abstraction should be done by composition rather than inheritance. For example, it's not possible to define a Button instance that uses something other than digitalRead to read the state. What do you think?
https://en.wikipedia.org/wiki/Composition_over_inheritance
Hum, interesting. But how would this be implemented?
I also want to find a way to do this, id like to be able to define a button instance with an input that is not digitalRead, maybe add in an override?
@KenwoodFox this can already be implemented. See the source for
class BounceinBounce2.h.You can set your custom override for digitalRead :
virtual bool readCurrentState() { return digitalRead(pin); }This is pretty awesome! thanks so much.
Sorry to ask, but where would you implement this? Should this be done for every button instance you create or do i need to make my own button class using inheriting from bounce?
It isn't a complete replacement because it doesn't have complex debouncing techniques, but the
Debouncerlibrary allows passing in the value to use.