mirek wrote on Thu, 01 April 2021 23:49

Are you 100% sure this does not work with Wacom:

https://stackoverflow.com/questions/29857587/detect-if-wm-mo usemove-is-caused-by-touch-pen

?

Last time I tried it did not work. It was zero all the time. Since then, I have reinstalled the Wacom drivers.

Now I get: "GetMessageExtraInfo() = 4283520772" for pen and "GetMessageExtraInfo() = 0" for mouse. These are present for e.g. WM_MOUSEMOVE and WM_LBUTTONDOWN.

So, I may have made some stupid mistake last time or the driver re-installation may have had an effect.

Best regards,

Tom

Please try trunk reference/Pen now...

Notes: This is just a first rough attempt, if this works, it needs a cleanup and handling of history.

mirek wrote on Fri, 02 April 2021 12:43

Please try trunk reference/Pen now...

Notes: This is just a first rough attempt, if this works, it needs a cleanup and handling of history.

Hi Mirek,

I just updated to latest SVN. All drags start 2 cm late. (Let's call this issue 'DragLag' for short from now on.) This is no wonder as WM_POINTERUPDATE does not send MouseMove() events to the app through any channel. Giving WM_POINTER* messages to the DefWindowProc*() to handle, causes DragLag before WM_LBUTTONDOWN and respective WM_MOUSEMOVE messages are generated. I have spent last two weeks on the issue and have not found any clean and easy way out with Wacom.

I understand that you don't have this DragLag -nightmare with XP-PEN and everything you do works with it. And that my attempts here are complex and ugly.

In general: I strongly believe that whatever model we choose in the end, it must not require changes in CtrlLib.

WRT to draglag, after reading MSDN docs, I have the impression that this is exactly what M$ wants to happen.

Anyway, a draglag related question - it is not quite clear to me whether the draglag which you experience is

a) drag starts late, after moving pen a bit, not immediately
b) drag has offset

(With XPPEN, with current model, drag just starts a little late, but position is correct)

Mirek

What about other issues? I mean, does it work as mouse elsewhere?

Adding:

	case WM_TABLET_QUERYSYSTEMGESTURESTATUS:
			return TABLET_DISABLE_PRESSANDHOLD;

Removes the pen down/hold/up mapping to RightDown/RightUp and instead gives LeftDown/LeftUp. No LeftHold is generated during the prolonged pen-down though.

Unfortunately, this does not help at all with draglag.

Best regards,

Tom

Tom1 wrote on Sat, 03 April 2021 11:37

Adding:

	case WM_TABLET_QUERYSYSTEMGESTURESTATUS:
			return TABLET_DISABLE_PRESSANDHOLD;

Removes the pen down/hold/up mapping to RightDown/RightUp and instead gives LeftDown/LeftUp. No LeftHold is generated during the prolonged pen-down though.

Unfortunately, this does not help at all with draglag.

Best regards,

Tom

Another thing we can try is to retain Pen method, but discard bool return value, always process with DefWindowProc. Create new RectTracker just for Pen...

mirek wrote on Sat, 03 April 2021 16:52

Tom1 wrote on Sat, 03 April 2021 11:37

Adding:

	case WM_TABLET_QUERYSYSTEMGESTURESTATUS:
			return TABLET_DISABLE_PRESSANDHOLD;

Removes the pen down/hold/up mapping to RightDown/RightUp and instead gives LeftDown/LeftUp. No LeftHold is generated during the prolonged pen-down though.

Unfortunately, this does not help at all with draglag.

Best regards,

Tom

Another thing we can try is to retain Pen method, but discard bool return value, always process with DefWindowProc. Create new RectTracker just for Pen...

OK, let's see how it turns out. GetMessageExtraInfo() may be useful to classify events to application so that we can filter out already processed pen events and not do it again as if they are coming from the mouse.

OK, I'll try, but I'm afraid it may fall back to you eventually...

As for the RectTracker, I would prefer it is a single RectTracker capable of reacting to both pen and mouse, so that I do not need to create separate Sketchers for each.

Best regards,

Tom

Hi Mirek,

Thanks for accepting the changes.

It was a stupid mistake of me to use Image::Arrow() instead of CursorImage(). It should be in CtrlMouse.cpp(145) like:

	if(supports_pen && is_pen_event) return CursorImage(p, keyflags); // Avoid duplicated pen events

Without 'supports_pen' it would become a tedious battle in client code to avoid various pen originated duplicate mouse events, so I rather block them just before. Anyway, making 'bool supports_pen;' a configurable flag in Ctrl:: in CtrlCore.h is fine with me:

	Ctrl&   EnablePenSupport(bool b = true)                   { supports_pen = b; return *this; }

Then, to avoid Pen() return value assignment in Win32Proc.cpp(147), we should remove 'supports_pen =' and have just:

				q->Pen(p, pen, GetMouseFlags());

This works here. (I will of course add 'EnablePenSupport();' to constructors of Pen() enabled widgets.)

This includes RectTracker::RectTracker() in LocalLoop.cpp:

RectTracker::RectTracker(Ctrl& master)
{
	EnablePenSupport();

Best regards,

Tom