I'm trying to use this with an i2c port expander and I understand I can create my own handler to read the i2c port and also it would break out the bits to simulate single button bits.
what seems to be missing is a user callback to init. like many things, there's a duality for a 'setup' and a 'loop' concept. same here. you have the user vector callback to get data but not to init it, the first time. you say the user has to do that outside. why not just provide a way in the begin() call, when you refer to VIRTUAL pins, to provide an optional callback. that extends the library more easily and hides that init code from the main app's setup() code.
maybe something like:
void myInitCB(void)
{
// user will setup their i2c PE, etc
}
button1.begin(VIRTUAL_PIN, myInitCB);
so just 1 more ctor that takes a 2nd parm and you call the callback once at that time. just a little bit of 'init hiding' but it feels more natural to have both vectors that the user provides instead of just the data polling one.
this is a nice library.
I'm trying to use this with an i2c port expander and I understand I can create my own handler to read the i2c port and also it would break out the bits to simulate single button bits.
what seems to be missing is a user callback to init. like many things, there's a duality for a 'setup' and a 'loop' concept. same here. you have the user vector callback to get data but not to init it, the first time. you say the user has to do that outside. why not just provide a way in the begin() call, when you refer to VIRTUAL pins, to provide an optional callback. that extends the library more easily and hides that init code from the main app's setup() code.
maybe something like:
void myInitCB(void) { // user will setup their i2c PE, etc }
button1.begin(VIRTUAL_PIN, myInitCB);
so just 1 more ctor that takes a 2nd parm and you call the callback once at that time. just a little bit of 'init hiding' but it feels more natural to have both vectors that the user provides instead of just the data polling one.