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

Valid. It's just very odd and frustrating then that even with a full clean install the issue persists and yet is somehow also difficult for some to reproduce.

I totally forgot about the PSUserConfig.txt! I used to have it, but you have to re-add it for every new version install (thx Adobe). This solved it so far. 

Make a  PSUserConfig.txt file - add it to this folder:
C:\Users\[User]\AppData\Roaming\Adobe\Adobe Photoshop 2024\Adobe Photoshop 2024 Settings

In the file you need the line: 

UseSystemStylus 0

You might have to also make sure your Wacom Driver preferences (under "Calibrate") has "Use Windows Ink" set to OFF.

Resetting the preferences only helped me temporarily (I celebrated too early, it was maybe just random). But so far, after several restarts, I don't have the click issue after copying the PSUserConfig.txt.

It's kina opposite solution of what @alanp6536080 said (but thanks for reminding me). Either way, it is related to it, so try one or the other way:
> 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  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.

Strange that Adobe tells us they worked on this for 4 months without even reproducing what users now supplied instantly.

@ericman2323 i guess Plugin it's not problem.
When I tested countless times (24.5~24.7? version). These days, when the release comes out, I test it out and roll back it right away...), I just reinstalled the OS clean, installed Photoshop, and did nothing, and reproduced it with just a mouse.

As this seems to be a PS-specific bug and as stated previously, is most likely not video card-related, I wonder if a contributing factor or even the culprit could be a PS addon or extension that is somehow interfering with PS noticing the WM_LBUTTONUP state.
 Below is a list of the addons and applications I have installed for use with Photoshop specifically as well as a list of my computer specifications.

>> 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?

It's really hard for me to say, since we have such difficulty reproducing. But yes, that is a possible scenario.

@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

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

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.

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

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