In painting apps that don’t support the button, it’s the same freeze behavior (illustrator, adobe sketch).
In other apps like clip studio or samsung’s notes app, it works well though. These ignore button events during a stroke and only only decide on what to do when the button is pressed either away from the tablet with no cursor showing or in proximity with the cursor showing but not touched yet
Thanks for the quick update, button works as expected during the stroke now without the flashing. Pen is still inactive when pressing the button before the stroke.
Btw I’ve just installed visual studio and I could see the function AMotionEvent_getButtonState returns “34” instead of “0” when the button is down when nearing the tablet or touching. Don’t know why some applications appear to block the pen when the button is down, I was using the standard C++ HelloWorld example to check.
Hmm are you sure it’s “34” and not “32”?
“34” means you are pressure AMOTION_EVENT_BUTTON_STYLUS_PRIMARY and AMOTION_EVENT_BUTTON_SECONDARY at the same time (android doc)
Do you know the value returned by AMotionEvent_getAction ?
I do release all the pointers when there is something that I don’t recognize (although as you noticed I introduced a small bugs and sometimes it’s not released well).
If I can know what exactly is the returned value from AMotionEvent_getAction maybe I can fix the frozen thing as well.
pen approach-hover-remove without drawing, AMotionEvent_getAction returns 9-7-7-…-7-7-10
pen approach-hover-draw-hover-remove is AMotionEvent_getAction returns 9-7-7-…-7-7-10-0-2-2-…-2-2-1-9-9-7-7-…-7-7-10
so nothing special, except the weird double 9
getButtonState is 34 maybe to simulate the right mouse button for some apps
getToolType is the same (2) with button down or not
on my wacom pen from the 90’s there’s secondary button which switches the tooltype to 4 (eraser)