First of all, thanks for all the good discussion and testing, to you and everyone else participating.
Quote:
Originally Posted by mschnell
Allowing for a dedicate (functionally -> .axt) release action for buttons seems like a good idea do cover in certain cases. It would open up possibilities like "do something {e.g. play} while pressed, "long press" special action, "DoubleClick", "simultaneous pressing multiple buttons", ... to be provided by the CSI infrastructure.
This of course would not effect the handling of the light in a button.
For the issue in question, the "SomeButton PressReleaseXXX" definition would need enough parameters to care for the special cases. At least:
|
Let's re-use our previous example:
SomeButton PressRelease 90 46 7f 90 46 00
We are going to remove this definition and it will be replaced by the ones below.
Quote:
- Define message we receive when pressed
|
You can already do this:
SomeButtonPress Press 90 46 7f in the .rst file -- give a name to the button press
SomeButtonPress SomeAction in the .axt file -- tie button press to an action
Quote:
- Define message we receive when released
|
You can already do this:
SomeButtonRelease Press 90 46 00 in the .rst file -- give a name to the button release
SomeButtonRelease AnotherAction in the .axt file -- tie button release to another action
Quote:
- Define message we send to the device after receiving a "pressed" message (which might be modified by the state CSI stores after this action).
|
Generally we don't want to store surface state where we can avoid it, please describe a use case.
Quote:
- Define message we send to the device after receiving a "released" message (which might be modified by the state CSI stores after this action).
|
See above.
Quote:
Thanks for listening,
-Michael
|
Thanks for contributing !