P: Completely broken Hand tool (PS24.5) Hand Tool Sticking, sticky, not seeing mouse-up

Report · Jun 19, 2023

This is a bug. Please don't move it to the Discussions tab.

And please don't merge into another unrelated thread. I will report a bug with this thread.

------------------------------------

I made a YouTube video using a keyboard mouse overlay to show what action I'm taking. I hope you can refer to refer to it.

https://youtu.be/Cle6dEgP5_Y

------------------------------------

I was disappointed that there were so many bugs that were not fixed in 24.5, but I was still trying to give it a shot.

However, this bug is pretty serious. Really...

Please see the video I attached.
If you watch the video, you will see that I am shaking the screen.
I'm not using a hand tool, it should release automatically, but that thing is sticky.

To release this sticky, pinned handtool, you'll need to make one more unconditional click.

Here's how I've organized them for your reference.

< What I can be sure of >

Window10 (Tested a total of 14 PCs)
Use WacomTablet
Not related to preferences at all (Especially not related to Spring loaded, Flick panning stuff things)
I've tried all the known Photoshop troubleshooting methods and no improvement.
Even reinstalling Windows does the same thing
Only in 24.5 does this bug occur with certainty. I can't reproduce it at all in earlier versions.

< I'm not sure about the >

Mac OS not tested
I couldn't even test if it was a GPU company difference. I and my team all use NVIDIA

And while there are a few threads pointing this out, there doesn't seem to be a proper plan to fix it.

If this is not fixed in 24.6, 24.6 will be equally unusable as 24.5.

Also check out the links below.

https://community.adobe.com/t5/photoshop-ecosystem-discussions/hand-tool-lock-after-releasing-spaceb...

https://community.adobe.com/t5/photoshop-ecosystem-bugs/some-ps-tools-keep-reading-wacom-pen-after-l...

https://community.adobe.com/t5/photoshop-ecosystem-discussions/hand-tool-won-t-let-go-of-image/m-p/1...

https://community.adobe.com/t5/photoshop-ecosystem-bugs/24-5-impossible-to-use-with-wacom-intuos-on-...

(cjbutler 1/12/24: edited title from "not reverting to cursor" to "not seeing mouse up" to reflect latest focus on lost mouse-up as root cause, and not just a stale cursor setting.)

Report · Nov 06, 2023

@Vit Kovalcik Good Point! but..........
It might have something to do with Wacom, but when I reinstalled Windows 10 OS, which didn't even have a Wacom driver installed at all, and only installed Photoshop, I was able to reproduce it with just a mouse.

Report · Nov 07, 2023

I have noticed this has to do with how fast are the clicks coming one after another. For example, if I'm using the mouse and I'm on the hand tool and I'm panning fast many times through an image, it gets stuck at some point - quite fast in fact. BUT if while panning I do it while clicking slow enough that it doesn't "sound" like a double click, it never gets stuck. It's like PS thinks "oh, that was a double click while panning, I gotta glue the mouse to the image, he wants to pan without holding mouse down". I hope it helps because I feel like I'm getting to old age slowly panning through the image - I'm normally working way faster than this.

Report · Nov 09, 2023

Hi;

I posted a few days ago about having the same issue, after upgrading to PS 25.0. Well, today I tried to use it for some actual production work and I'm sorry to say it is completely and utterly unusable.

It is not only the pan tool that sticks, but actually everything. Lassos get stuck even after releasing keys, transform tools, clone tool, etc, etc. Just about everything.

The app is completely broken. I'm not sure how it got here from a fully-functional PS 2020. Frankly, I can understand everyone's frustration after what I just saw.

I really hope this gets some resources put on it at Adobe because it's rather shameful to see something in such a state of disarray.

In the meantime, I'll revert back to PS 2020, although it's a shame to not be able to use the generative tools, which is why I upgrade in the first place.

-Richard

Report · Nov 09, 2023

@Richard Rosenman what OS are you running? If on Sonoma, try upgrading the OS to 14.1.1

Report · Nov 09, 2023

I am on Windows 10.

-Richard

Report · Nov 09, 2023

Can confirm - pan, lasso, text (moving), clone, selection and many others -
this does affect most tools. It's easiest to reproduce in the pan tool for
sure but it does affect every tool with a left-mouse-click to some extent.
I even had it stick with the paint tool today. I let go of the left mouse
and it just kept painting. I needed to double click it to "unstick" it.
Windows 10, v25.0, no wacom tablet (for those who still think this is a
wacom issue)

Report · Nov 09, 2023

Had exactly the same issues. Absolutely unusable for me and it felt like like it was related to PS not knowing or detecting when the mouse button got released. Out of shear desperation, I changed my Windows double-click/lmb speed to the absolute minimum. Saved the settings, quit/restarted PS and I didn't have the issue again until I installed an update. Thought I'd gotten lucky with double-click change but modified it again (moved it up, saved it, moved it back to minimum) and the problem went away aagin. Haven't had it return for the past few weeks and I'm using 25.0.0 on Win 10. It's obviously a work-around and Adobe need to get this fixed ASAP but I've at least gotten my sanity back for a while. Suggest everyone at least tries it to see if it works (easy enough to do after all).

Report · Nov 09, 2023

Just tried your suggestion (see pic) but unfortunately changes nothing (unless I need a reboot).

-Richard

Report · Nov 09, 2023

Hi Richard, thanks for trying it. Your settings there are exactly the same as what I have, only mine fixed the issue and I didn't need to reboot - I just quit/reloaded Photoshop. I'm sorry that it hasn't work for you and can only guess that there's something specific to my set-up/system that means it did the trick. For the record, I have a basic Logitech mouse and didn't install any specific drivers for it. It's just a plug and play.

To confirm, I had the 'sticky' thing happening with absolutely everything. Marquee, Crop, Eyedropper, pan and even painting. Like you said, it was unusable for me too. I regret that my 'solution' doesn't work for everyone and can only wish you luck in finding something that works for you in the meantime. I daren't touch anything with my current install in case it breaks again! I certain;y won't be updating any time soon.

Report · Nov 14, 2023

Windows 10

Phoroshop 25.1

The same issue is still present, it's a click issue, It also happens when dragging corners while on Transform, I'm ctrl + drag and it will also get stuck. Finally a version with the blasted spring tool option to turn it off and now this, I'll just go back to ver. 22+, it has been until now the only non-laggy/problematic version since ver. 17.

Report · Nov 14, 2023

The strange trick outlined by @alfredoc1234 worked.

@Caity.psd Is Adobe actually having a "Fix in progress"? Like how many of your engeniers are on this since .... August? Nobody here even bothered to "keep you informed!", for all I see. Thank god the users helped.

Report · Nov 14, 2023

Please see my earlier posts in this thread. The current state has not meaningfully changed in the last several weeks. @Caity.psd would just be checking with me for updates.

The bug is Open/ToTest. We still cannot reliably reproduce at Adobe. We've seen the bug happen, but very infrequently and not all reliably, which makes it very difficult for us to diagnose the root cause. I understand this is contrary to the experience of many of the folks on this thread; for many of you, this happens all the time and is a productivity killer.

The normal sequence for handling a bug looks something like this:

New bug report
ToTest/Refine – we establish precise steps to reproduce (STR) the bug, allowing a Developer to debug the fail case.
ToFix – The Developer crafts a fix
ToTest/Verify – The fix is tested and verified that the STR no longer triggers the bug to occur.
Code Review – Other Developers review and approve the proposed code change.
Merge to Main Line code base
Automated testing, internal user testing
Prerelease, Beta Release – This is the first point end users can see the code change.
Official Release build with the fix.

We’re still on step 2. I'm still reading posts in this thread looking for information that might help get us into step 3.

Report · Nov 14, 2023

Both my computers, the workstation and the PC have nVidia cards, 3060 TI and 3050 respectively. It may have to do with this, maybe. As for testing, try to switch fast and repeatedly from brush to hand tool for example and back again, panning all over the image as if repositioning constantly and FAST for brushing or whatever. Try using the spacebar while having brush selected, to activate the hand tool for paning, release it and use it again several times. Also, try to change brush size and hardness using the ALT + right click down several times. This should do the trick. The reproduction has to be done by an artist, rather than a software developer. I am both, fortunately, that's why I can make the distinction. If you are working fast on an image it's impossible not to replicate the bug within seconds.

Report · Nov 14, 2023

What I'm noticing is that the bug activates while click + key. Clicking (simple brush strokes for example) doesn't seem to have any issues, I clicked a ton with my brush, rapid clicking all over the canvas and everything was fine, the simple ctrl + drag was okay as well... the moment I used a alt or space + click/drag the bug started. When transforming a shape it's when ctrl + drag bugs out.

I'm an artist, I have to change brush size via alt + right click (also bugged) constantly, transform shapes on every single file. This bug renders 25.1 useless.

Report · Nov 14, 2023

Focusing on Windows 10 for a moment:

We don’t think the problem has anything to do with video cards.

There is an Event Queue that Photoshop polls as it works to handle commands like the Hand Tool and Panning, Creating a Selection, Painting and so on.

Looking at the panning gesture as a detailed example, That Event Queue holds the initial WM_LBUTTONDOWN event, followed by a series of WM_MOUSEMOVE events, followed by a WM_LBUTTONUP event. There are also periodic WM_KEYDOWN (the space key) which is referenced when initiating the mouse-down and figuring what Command to execute. Within Photoshop, this sequence of gestures initiates a Command (The Hand Tool), which then starts what is referred to as a Tracker. The Tracker is terminated when we see the WM_LBUTTONUP, and the panning gesture stops. This is how it is supposed to work. And in all our testing that is how it does work.

Even when you are an Artist working very quickly, the Windows OS Event Queue feeds us events, sometime a little out of order, but generally within a few milliseconds. We are supposed to see all the events in the above gesture.

Sometimes we get extra events, like when a Pen or other pointing device is involved. We can also get WM_POINTERDOWN and WM_POINTERUP, but even when working purely with a Pen, we still get the equivalent mouse events (Windows thoughtfully creates them and adds them to the Event Queue for us).

Our guess is that the Photoshop Tracker logic loop, for some reason, never gets to see the WM_LBUTTONUP event. We don’t know why, since we can’t reproduce the failure. For those of you with the problem, is Photoshop even getting the event? Is some sub-process consuming it silently and inappropriately? We just don’t know at this point.

Report · Nov 14, 2023

FINALLY you come up with some technical background!

I am sure, that helps some more technical competent people/users to encircle the topic even more.

And it also shows more openness and let us have some insight.

Thanks for that and good luck for isolating the bug piece by piece.

Report · Nov 14, 2023

There is most definitely something happening in a way that the WM_LBUTTONUP is not triggered, or caught, rather. Unfortunately, there is not much I can say about this, without having a look at the source code. My wild guess is somewhere in a for or a while loop there is something which will shoot out of the WM_LBUTTONUP message processing. Everything resets to normal after first left click (without any other ley pressed).

Report · Nov 14, 2023

@CJButler Hi. Thanks for coming this thread.
I press the spacebar very often because I'm a Retoucher, but when I reproduce that bug, I just press it once very slowly and it reproduced.
I don't know how this works (because I'm not a programmer).

https://community.adobe.com/t5/photoshop-ecosystem-discussions/when-press-f-doesnt-change-screen-mod...

I reported on this last year. I thought it was a bug that wasn't serious, and actually that failed when I tried to change the screen mode myself, so I had to turn off Photoshop and turn it back on unconditionally at the time. But after version 24.5, I often had that bug and I inadvertently pressed the spacebar just one more time (hand tool was not active). And that's solved.
So I changed my mind. I also claimed that by the time I reported this bug earlier, I had considered issues with Windows Ink, Wacom, or user settings, and that Photoshop's own installation file was broken.

But don't think it's working well to return that spacebar from a version at some point (that's more prominent from 24.5). (Nothing to do with spring rod options)

If you press and release the spacebar, you should recognize it.
But it recognizes it as being pressed. This wasn't even a problem with the OS update. I was convinced when I tested it on the same Windows build version, the same drivers, the same CPU, multiple desktops and laptops of GPUs.

So once again, I don't know about programming.
But now this bug should be recognized in Photoshop as a user pressing "Spacebar" and then "unpressing" it (the Spacebar is not pressed), but it is not. Photoshop keeps thinking. The Spacebar order has come in, so I think I keep it.

Report · Nov 15, 2023

@CJButler: You are right! I didn't think it was possible, but I did a test:

I used Spy++ from MS Visual Studio package (the 64-bit version spyxx_amd64.exe to be precise). I tried other apps, so other people could test it too without installing Visual Studio, but so far I failed.

My process:

- Preparation in PS: Open a file, switch to hand tool, from then on use just left mouse button, no keyboard, no tablet (even though I have a Wacom tablet and its drivers)

- Spy++ settings: Watching message from Photoshop and message from the same thread and same process

- Spy++ settings: Watching _only mouse_ messages, otherwise it gets messy very fast

- Spy++: Start the capture, switch to PS

- PS: After a few drag movements, the tool remain stuck and as you wrote WM_LBUTTONUP is indeed missing. But many times few seconds before that, on occasions when the tool was not stuck, the WM_LBUTTONUP was sent, so there is indeed this glitch from time to time.

You can ind the respective log here:

https://www.pastel.cz/temp/ps_messages_error.zip

After message 004166 I ended up with a stuck tool, waited for a while (no new messages occured), Alt-Tabbed to Spy++ and terminated the logging, so no further mesasges are relevant.

I also tried to capture mouse messages from ALL WINDOWS, but WM_LBUTTONUP was again not sent at all.

If there is anything else you would like me to test, I would be happy to try it.

Report · Nov 15, 2023

Hi @CJButler

After reading @Vit Kovalcik 's post I've done some investigation using Spy++ on the problem as it affects my own system. (Windows 10, nVidia GTX 1060, Wacom Intuos tablet, PS 25.1.0)

With this I *never* see the issue using a mouse. I *do* see the issue with a Wacom tablet if I have UseSystemStylus=0 in a PSUserConfig.txt file AND have Use Windows Ink set to OFF; I do *not* see the issue with a Wacom tablet with no PsUserConfig.txt and Use Windows Ink set to ON.

And *rarely* the issue goes away for no apparent reason and I don't see it at all.

The test sequence was the same in all the tests I did. Spy++ was looking at

WM_KEYDOWN

WM_KEYUP

WM_LBUTTONDOWN

WM_LBUTTONUP

WM_MOUSEMOVE

WM_POINTERDOWN

WM_POINTERUP

and set to track all windows in same thread, all windows in same process, child windows and parent windows.

PS was open with a PSD file that I had smaller than the main window to give me a background. All tool windows were closed. The Hand tool was preselected.

The sequence was this:

Move cursor into the PS window, click once on the background to give it focus

Move cursor into the image

Click and hold to pan the image

Lift the mouse button or pen and see what happens

In the "Mouse with Windows Ink OFF" log I used a mouse with UseSystemStylus=0 in PSUserConfig.txt, and the tablet driver set with Windows Ink OFF. I have *never* seen the problem in this configuration and the log looks clean.

In the "Tablet with Windows Ink ON" log I used a Wacom tablet, with no PSUserConfig.txt file, and the tablet driver set with Windows Ink ON. I do *not* see the problem here and the message flow in the log seems sensible.

In the "Tablet with Windows Ink OFF" log I used a Wacom tablet, with UseSystemStylus=0 in PSUserConfig.txt, and the tablet driver set with Windows Ink OFF. This is the only configuration where I see the problem.

Here there is no WM_LBUTTONUP message when I lift the pen, although from then on WM_MOUSEMOVE's wParam does show that no button is pressed.

The major difference is that in the Windows Ink ON case I see

WM_POINTERUP

WM_LBUTTONUP

when I lift the pen, and with Windows Ink OFF I see neither. I've annotated the logs to show sequencing.

In the mouse case, I see a WM_LBUTTONUP as I would expect.

---

So is that any help to you?

As a thought - is there any mileage in you giving a test recipe for those of us able to use Spy++ to get the maximum amount of information out? I was tracking the mesages that seemed most useful from your recent explanation, but is there more that could help?

Alan

---------------------------------------

Mouse With WIndows Ink OFF

======================

SEQUENCE USING MOUSE WHERE PROBLEM DOES NOT OCCUR
-------------------------------------------------

This sequence is generated using a mouse. I have never seen the problem with a mouse
I have UseSystemStylus = 0 in PSUserConfig.txt, and Use Windows Ink is ON.

In this configuration I do see the problem with a tablet.

--

I move the mouse cursor into the PS window

<000001> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:1038 yPos:427
<000002> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:974 yPos:415

... many repeats

I click and release to give PS focus. I don't see a WM_LBUTTONDOWN?

Here the mouse cursor does not change to the Hand cursor until I move the
mouse.

<000012> 00000000000212CA P WM_LBUTTONUP fwKeys:0000 xPos:870 yPos:378
<000013> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:871 yPos:378

Now I move the nmouse cursor into the image

<000014> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:874 yPos:383

... many repeats

I click and hold the left button

<000051> 00000000000212CA P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:517 yPos:302

I move the mouse around and the image pans as expected. The WM_MOUSEMOVE wParam
shows the left button down as expected.

<000052> 00000000000212CA P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:518 yPos:303

... many repeats

I lift the left button and see a WM_LBUTTONUP

<000066> 00000000000212CA P WM_LBUTTONUP fwKeys:0000 xPos:737 yPos:389

And now mouse moves do not cause panning. The WM_MOUSEMOVE wParam
shows the left button up as expected.

<000067> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:737 yPos:389
<000068> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:736 yPos:389
<000069> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:735 yPos:389

Tablet With WIndows Ink ON

======================

SEQUENCE USING TABLET WHERE PROBLEM DOES NOT OCCUR
--------------------------------------------------

This sequence is performed using a Wacom Intuos tablet.
I have Use Windows Ink turned ON, and there is no PSUserConfig.txt file

--

I move the cursor into the PS window

<000001> 0000000000031416 P WM_MOUSEMOVE fwKeys:0000 xPos:1225 yPos:440
<000002> 0000000000030FB2 P WM_MOUSEMOVE fwKeys:0000 xPos:9 yPos:411

... many repeats

I tap and release on the PS window background to give it focus. The cursor changes immediately
to the Hand cursor.

Here I am seeing WMPOINTER* messages

I also see a WM_LBUTTONDOWN message

<000074> 0000000000040FBE P WM_POINTERDOWN wPointerID:0002 wFlags:6016 ptX:1378 ptY:597
<000075> 0000000000040FBE P WM_MOUSEMOVE fwKeys:0000 xPos:1151 yPos:425
<000076> 0000000000040FBE P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:1151 yPos:425
<000077> 0000000000040FBE P WM_POINTERUP wPointerID:0002 wFlags:6002 ptX:1378 ptY:596
<000078> 0000000000040FBE P WM_LBUTTONUP fwKeys:0000 xPos:1151 yPos:425

Now I move the cursor into the image

<000079> 0000000000040FBE P WM_MOUSEMOVE fwKeys:0000 xPos:1154 yPos:421

... many repeats

I tap and hold on the image

<000217> 0000000000040FBE P WM_POINTERDOWN wPointerID:0002 wFlags:6016 ptX:884 ptY:600
<000218> 0000000000040FBE P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:657 yPos:428

I pan the image, and WM_MOUSEMOVE wParam shows the left button is down

<000219> 0000000000040FBE P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:677 yPos:436
<000220> 0000000000040FBE P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:681 yPos:438

... many repeats

I lift the pen and see "up" messages

<000259> 0000000000040FBE P WM_POINTERUP wPointerID:0002 wFlags:6002 ptX:1122 ptY:723
<000260> 0000000000040FBE P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:895 yPos:551
<000261> 0000000000040FBE P WM_LBUTTONUP fwKeys:0000 xPos:895 yPos:551

And now the image is not panning, and WM_MOUSEMOVE wParam shows the left button is not down

<000262> 0000000000040FBE P WM_MOUSEMOVE fwKeys:0000 xPos:895 yPos:551
<000263> 0000000000040FBE P WM_MOUSEMOVE fwKeys:0000 xPos:893 yPos:544

Tablet With WIndows Ink OFF

======================

SEQUENCE USING TABLET WHERE PROBLEM DOES OCCUR
----------------------------------------------

This sequence is generated using a Wacom Intuos tablet.
I have UseSystemStylus = 0 in PSUserConfig.txt, and Use Windows Ink is ON.

--

A major difference between this case and the log where I don't have this is that I don't see
WM_POINTER* messages.

To start I use the Wacom pen to move the cursor into the background of the PS window

<000001> 0000000000080ABA P WM_NCMOUSEMOVE nHittest:HTBOTTOM xPos:1379 yPos:899
<000002> 00000000000214A8 P WM_MOUSEMOVE fwKeys:0000 xPos:778 yPos:15

... many repeats

I tap on the background of the PS window to give it focus, and I get the cursor for the Hand tool

I see a WM_LBUTTONUP, but no WM_LBUTTONDOWN

<000119> 00000000000212CA P WM_LBUTTONUP fwKeys:0000 xPos:903 yPos:429

Now I move the cursor into the image

<000120> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:902 yPos:430

... many repeats

I tap and hold on the image

<000248> 00000000000212CA P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:451 yPos:357

I start to pan the image around. In these messages, WM_MOUSEMOVE's wParam is detecting the
left button down. PS works as expected.

<000249> 00000000000212CA P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:452 yPos:357
<000250> 00000000000212CA P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:453 yPos:357
<000251> 00000000000212CA P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:454 yPos:357
<000252> 00000000000212CA P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:455 yPos:357

... many repeats

At some point in the sequence I lift the pen from the tablet. The image continues to pan even
though I have lifted

I don't see a WM_LBUTTONUP. But WM_MOUSEMOVE's wParam is correctly showing that the left
button is not down.

<000293> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:765 yPos:229
<000294> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:764 yPos:225
<000295> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:766 yPos:225
<000296> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:773 yPos:228
<000297> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:774 yPos:230

Finally I hit the ESCAPE key and the tracker stops the panning action

<000365> 00000000000212CA P WM_KEYDOWN nVirtKey:VK_ESCAPE cRepeat:1 ScanCode:01 fExtended:0 fAltDown:0 fRepeat:0 fUp:0
<000366> 00000000000212CA P WM_CHAR chCharCode:'27' (27) cRepeat:1 ScanCode:01 fExtended:0 fAltDown:0 fRepeat:0 fUp:0
<000367> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:442 yPos:390
<000368> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:442 yPos:390

... many repeats

<000379> 00000000000212CA P WM_KEYUP nVirtKey:VK_ESCAPE cRepeat:1 ScanCode:01 fExtended:0 fAltDown:0 fRepeat:1 fUp:1

From here a pen move is not panning the image. PS is responding correctly to the WM_MOUSEMOVE's wParam being zero.

<000380> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:453 yPos:389
<000381> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:453 yPos:388

Report · Nov 15, 2023

Hi @CJButler again -

Well, I can certainly share your frustration with this on-and-off issue.

After I did those Spy++ tests in my previous message I had an idea and went back to the configuration that shows the problem: UseSystemStylus=0 in PSUserConfig.txt and Wacom drivers set with Use Windows Ink OFF. This is almost certain to manifest the problem.

No other changes apart from restarting PS after changing the configuration.

And of course, now I don't see the problem.

But at least it's another possibly helpful data point for you

Move the cursor into the PS window, click on the background and release to give it focus. The Hand tool is preselected.

<000059> 0000000000180A50 P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:1699 yPos:397
<000060> 0000000000180A50 P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:1700 yPos:397
<000061> 0000000000180A50 P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:1698 yPos:397

... many repeats

<000062> 0000000000180A50 P WM_LBUTTONUP fwKeys:0000 xPos:1698 yPos:397

Move the cursor into the image

<000063> 0000000000180A50 P WM_MOUSEMOVE fwKeys:0000 xPos:1700 yPos:396
<000064> 0000000000180A50 P WM_MOUSEMOVE fwKeys:0000 xPos:1699 yPos:396

... many repeats

Tap and hold the pen, and pan the image.

<000228> 0000000000180A50 P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:1158 yPos:462
<000229> 0000000000180A50 P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:1157 yPos:463
<000230> 0000000000180A50 P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:1156 yPos:463

... many repeats

Lift the pen.

And now we *do* get a WM_LBUTTONUP!

<000257> 0000000000180A50 P WM_LBUTTONUP fwKeys:0000 xPos:659 yPos:604

Move the pen around and the image does not pan.

<000258> 0000000000180A50 P WM_MOUSEMOVE fwKeys:0000 xPos:649 yPos:599
<000259> 0000000000180A50 P WM_MOUSEMOVE fwKeys:0000 xPos:647 yPos:599

Report · Nov 15, 2023

So, in random not-that-informed thought mode:

It is unlikely in the extreme that a WM_LBUTTONUP message is not fired when a button is lifted. The fact that some people (but not me) see this just using a mouse means it's not tablet-driver specific, and makes it vanishingly improbable. Nothing else would work if this message was unreliable.

The only reason I can think of where PS would not get the message is if some other process had fleetingly taken mouse capture at just the right (wrong?) moment. That's what I was going to test for when my system decided to not show the issue any more. So does anyone with the problem see WM_CAPTURECHANGED messages flying around? Does the wrong message queue get the message?

I suppose one approach here would be to check that the wParam value in WM_MOUSEMOVE corresponds to the expected button up/down state? The logs I've run suggest that that setting is relaibly tracking the button state (again reinforcing the point that the WM_LBUTTONUP message has to have been fired)

@CJButler I'm happy to test anything you want done (assuming my system drops back to show-the-issue state) and I appreciate your work!

Alan

Report · Nov 16, 2023

Well, I've tried today to get my system back into showing-the-issue mode so I can do some more Spy++ investigating, but it simply will not fail.

I've played with settings on and off, restarts, reverted from 25.1 to 25.0, updated back to 25.1 and PS is rock solid working as it should.

So here's a system that has had the issue constantly, and now it works perfectly. It's very annoying, isn't it? Great for me personally, but not so good for me adding my little bit of help to the work.

Report · Nov 16, 2023

Thanks Alan. Great data, and I really appreciate the effort. There's some new information in there (for us) that we are studying.

Report · Nov 16, 2023

@CJButler Glad to be of service. I can't do more as it stands, but eventually my system will misbehave again ...

I was thinking along one line (reply or not as you have the time and inclination! I last coded directly in Win32 many, many years ago so I have forgotten much...)

Spy++ is taking the global message hooks, and my reading is that it logs a message when a thread accesses it from its message queue with GetMessage/PeekMessage, and not when it placed in the queue.

So the non-appearance in the logs of WM_LBUTTONUP does not imply it doesn't happen, just that it has gone to a message queue that is not being read - which presumably is not the one it was expected to go to. Am I right?

Good luck with the hunt!

Alan

Adobe Community

P: Completely broken Hand tool (PS24.5) Hand Tool Sticking, sticky, not seeing mouse-up

1 Correct answer