Left Click Drag Not Working Anymore

[skeeber]

XMBC Version: 2.20.1
Installed or Portable version: installed
Windows Version: 10 Pro

Don't know if it's a problem or just how it works. I have it set up for the left button as Button Held: (custom) and normal click = left click. Then I have 2 held for options after certain times. Normal left click works fine, but I used to be able to left click drag and resize or move the window and now I can't anymore.

This started happening after I fixed the scaling issue I had with app/profiles list. I used to be able to drag and resize windows without much problem. It will only work now if I uncheck the held for boxes.

[phil]

Thanks for the seperate topic.. I'll reply here instead ...

What are the two "abort" check boxes set to in the button held config window? I would expect the first one would need ticking, but you suggest both need to be unchecked. That does not make sense (to me)! I will have to try it here and see if I can reproduce. I don't see how it can be related to the scaling issue - more likely it was a change in 2.20 - but if changing the scaling settings back fixes it, that would be very interesting to know....

[skeeber]

EDIT: see my reply to this post

OK, I've had some time to play around with it. The boxes I unchecked were the boxes next to the "held for" timers.

I uninstalled it and deleted all the files in the app data folder and reinstalled it. I also moved all my profile setting files to another place. After I ran the program it was like new, but when I started adding options and applying them, it said my profile file was named "Toby's XMBC Settings1" one of my earlier setting files had a 1 added. Does the new version add a 1 to the filename or is it getting my old name from somewhere?

Anyway, I wanted to start fresh and try it again. The only thing I have added is the windows media player classic app. Then on the left button I have selected "Button Held: custom" Then the first held option is set for "500ms Simulated Keys: (released) {CTRL}{NUM4} " and the "Abort and revert to normal click action" is checked.

If I click on the window without moving the mouse, it seems to work OK, but when click on the window and move the cursor, the cursor jumps to the top left of the desktop and clicks it there deselecting the MPC window. Then I have to click on the MPC window to make it active again. It's like it is doing an x:y move to 0:0 and clicking it.

If I uncheck the "held for" box it only works if I click on the window and wait a split second before I try to move the window and the window moves. If I click on it and try to move it immediately the cursor goes to the top left like before and the window is deselected.

If I uncheck the abort box (with the "held for" box checked), the cursor moves to where I move it and it does the operation in the first held for option, but doesn't move the window.

Don't know what is happening, but I probably should have just left it alone. I tried setting the scaling back to where I had it and it's still the same.

[skeeber]

I just tried setting the scaling back to where it was when the list was overlapping and it is working like it used to. The only difference is the 3 red and green dots that show up are a lot smaller. I tried setting the scaling back to where I had it a day or so ago and it didn't help, but now it does lol

[phil]

When you check the "Abort and revert to the normal click action when the mouse moves", what it should do is....
1. Remember where the mouse cursor was when you clicked the button
2. When the mouse moves, during the held timer, it should then:
2.1 Cancel the held timer
2.2 Remember the current cursor position
2.3 Move the cursor to position remembers in (1) (so the first click is actioned where you originally pressed the mouse button)
2.4 Send the <pressed> action for "normal click"
2.5 Move the cursor to the position remembered in (2.2)
.... Await further movement / button release.

So if it is jumping to 0,0, its as if step 1 has gone wrong, so step 2.3 goes to 0,0 rather than where the button was pressed...
Odd - but maybe there is something to go on!

Its not particularly clear, in your last message, are you saying that it works now (after turning the scaling options back off and on again?). Perhaps there is an issue when scaling has been set, saving the cursor position correctly (in step 1) or moving it in step 2.3... That may be worth investigating, but I have now fixed the scaling drawing issues (will be in 2.20.2) so maybe its not worth looking further at this - I'm not sure!

I may be able to send you a private early build pre-release so you can check in that (this evening)

[skeeber]

After turning scaling back to where it was before I changed it, the program is working fine. Just like it always has. I haven't tried changing the scaling options back to where the listing is fine. I assumed it will be the same as before. I will try changing back and forth after I get home from work.

[skeeber]

I changed the scaling back to override high DPI scaling and it does the same things as I mentioned before. I turned off the override and it is back to normal again. I don't know why it didn't do that when I tried it earlier. Maybe I didn't select apply, I don't know. I remember looking at the app listing and it was overlapping. I was changing so many things though lol I do like the size of the dots when it's scaled properly, much easier to see.

[phil]

I'll add a couple of items to the dev list - one to customize the size of the dots (although I think it will be physically limited by the dimensions of the cursor - which without scaling is probably quite small anyway), and one to see if I can fix the DPI issue when scaling. I guess the scaling is throwing out the "remember cursor position".

I don't think that that qualifies as an emergency 2.20.2 patch item though like the list drawing issue, as its likely a long standing bug that no one noticed until now (and was only noticed because of the drawing bug which I have already fixed for 2.20.2).