Totally annoying…same problem now with Surface…has anyone had this before with Surface? There is no Dell-Manager or Display-Manager…
I have an Asus laptop on which this happens. I’ve not yet figured out the issue.
Maybe the graphics driver or display driver.
Have you updated it or reinstalled it completely?
Which Clarion version do you use?
I’m migrating the app from 10 to 12.
I’ve updated all the drivers, including graphics.
One app is an established older app written in C10. It wasn’t recompiled, just installed from the installation file. Apps being developed, compiled in C11 and C12 also have the issue.
This is all I can find online which could be related.
TLDR.
Posted when the user presses the left mouse button while the cursor is in the
client area of a window.
If the mouse is not captured, the message is posted to the window beneath the cursor. Otherwise, the message is posted to the window that has captured the mouse.
Posted when the user presses the left mouse button while the cursor is within the
nonclient area of a window.
This message is posted to the window that contains the cursor. If a window has captured the mouse, this message is not posted.
HTCAPTION In a title bar.
so I would create a SubClass Procedure in the MDI child windows and see if you can capture the mouse when its over the Window Title.
I’ve now finished the documentation. I can also reproduce it using WM_NCHITEST with an incorrect response, but I still don’t understand why this is happening.
Something on the PC must be intercepting this event and responding incorrectly.
Could it be related to the touch display? Or a third party tool?
My laptop has multi functional Function keys, so F1 is also mute, F2 is Vol Down, F3 Vol Up, etc etc.
Its possible your PC manufacturer has an app, or somebody elses app (something like this Realtime Soft UltraMon) which is intercepting something.
If you can put together a demo procedure, and post the source or app online, I can test it here to see if its happening on my machine, if that helps.
At least that way, you might narrow it down then.
Were you using
Return ISWA_DefWindowProc( PA:WM_SysTray, phWnd, pwMsg, pwParam, plParam )
to pass on the event after capturing it?
Its not the usual
Return ISWA_CallWindowProc( PA:WM_PostSendMsg, phWnd, pwMsg, pwParam, plParam )
used in traditional subclassing scenerios.
I have those keys too.
But I thought maybe a touchscreen could be a problem.
I can try creating a test program.
The app with the problem is probably too large to simply share.
I don’t actually do any subclassing in the app; I just use the AcceptLoop and standard templates.
Under window display settings, scroll down to the graphics section and add your application as an exception. Then be sure the “optimize graphics for gaming” is OFF. Fixed this for us after fighting this for months.
2 Likes
It’s enabled in my settings, and I don’t have the issue on my laptop.
But I’ll test it on the customer PC and report back.
Thanks for the tip!
WIndows Settings :: System > Display > Graphics
Optimizations for windowed games = Off
Also, below there is a list of Custom settings for applications
where you can set a GPU preference and enable/disable the optimizations for windowed games
Turning the optimizations off helped, it still feels a bit hit and miss, which is a significant improvement over always failing. Note this also fixed a problem I had with splitter logic using a region that was failing as well.
Thank you for the tip
Glad to hear it helped with the issue
It doesn’t help in my case…It’s a surface device…