weird {ACTIVATE} problem with mouseclicks using Xpadder

[BugSplatter]

unfortunately I have found another issue with {ACTIVATE} not working (no matter how long waitms is after).
I'm still testing a bit before I can describe steps to reproduce it.
Not sure from what exact version this (to me big) problem came, but I tested 2.20.2 and the problem is not there in that version.
I come back if I have more info.

[BugSplatter]

beta 11
---------
- Open Firefox
- Open a window (i.e. calculator) and make sure it's a Topmost-window
- Make sure the topmost window is activated
-------------------------------------------------------------------------------
- With the pointer over Firefox, click (i.e. button 4)
--> example: {ACTIVATE}{WAITMS:10}r
* Firefox is activated and r is pressed in Firefox, so it looks like there's no problem
-------------------------------------------------------------------------------
- With the pointer over Firefox, press a button (controller button 8 in my case) on a (old Logitech Dual Action/probably any) controller using Xpadder which clicks mouse button 4
--> example: {ACTIVATE}{WAITMS:10}r
* Firefox is not activated in +-90% of the times (taskbar button=flashing) and r is pressed in "the other window/calculator"

Extra weird: If I make the XMBC-window topmost, there's also no problem, so saw the problem with calculator, but for me the real problem is:
I have a little topmost-window open 90% of the time, it's a little, old & simple Stopwatch application.

To me this is a big issue, because I need this sort of actions many times a day.
If you need anything from me, let me know. I hope you want to/can investigate this.
Thanks in advance

[phil]

It’s odd because that’s what I was seeing prior to 2.20.3 which the changes in 2.20.2 was supposed to fix. Unfortunately Microsoft are reluctant to let programs steel focus and instead flash the taskbar like you are seeing - the installed version of XMBC should be ok (as long as it is installed under the program files folder - is it??).

The changes in the new version was to check that the activation worked and if not, try again using other means - so it should be better not worse - but at the end of the day the real issue is windows blocking 3rd party activators so I’m not sure there will be much more I can do! But if it was working fine for you before - that makes not a lot of sense to me!!!! The first thing it does, is what it did before! I will try and have a look but probably not before Monday as I’m busy this weekend!

[BugSplatter]

I've used(not sure if this should even be necessary in this case, but anyway):

@reg add "HKCU\Control Panel\Desktop" /v ForegroundFlashCount /t REG_DWORD /d 1 /f
@reg add "HKCU\Control Panel\Desktop" /v ForegroundLockTimeout /t REG_DWORD /d 0 /f

(gets rid of unnecessary flashing and most scenario's where the default stupid flashing prevents bringing another window to the top)
(1 exception is when using SetForegroundWindow/BringWindowToTop/SetWindowPos etc. while shaking the mouse really hard + not using a BlockInput&Sleep combination)
----------------------------------------------------------
Install location: C:\Program Files\Highresolution Enterprises\X-Mouse Button Control

so that should not be the problem
----------------------------------------------------------
But please have a nice weekend & then look at this problem

[phil]

Can you generate some debug log with the beta I sent you (its not publicly available yet) because the logging should give some ide of that's going on (and maybe assist me in reproducing it here)

And when you say topmost do you mean forced "always on top" like with power toys?
And what is XPadder? this? https://xpadder.com/?lang=english&country=GB - I don't have that so if this problem is solely when using that program it could get tricky to debug!

[phil]

OK I found the last free version of XPadder (on majorgeeks) and just ran the test you are describing above - typically it all works for me, with calc 'always on top' and firefox....

No flashing, just the window gets activated and seems to work fine.

I will wait for some debug log - see if there is anything in there thats showing potential problems.
I did refactor the code, as well as fixing issues specific to firefox - so maybe something got missed (although its working here - it may be a particular thing Im not doing!)

[BugSplatter]

Thanks for taking a look,

I've sent some emails that could be useful.
Im going to read your post now & then make some logfiles:
1 with 2.20.12 & 1 with beta 11

[BugSplatter]

After doing the things from my last post, I will wait for a version with the change like you said in your last post.

[BugSplatter]

I've just sent the logfiles.
In each logfile I do the action that succeeds or fails 3 times.
I used a Youtube video for the test.

[BugSplatter]

Thanks, did you use my version of Xpadder that I've sent in the email, could be important for testing?
You were right about not needing to have the window always on top, so not useful, but still:
I you use the double arrows on the bottom of the StopWatch window and make the window bigger, then 5 buttons magically appear
(the rightmost button is the 'Always on Top'-button) (for Calculator I used the 'Window on Top' application that I've sent in the email)

---
I'm not completely sure if I understand:
I’m not sure how you are starting these always on top programs but by default they don’t run as admin, so maybe that’s a red herring!

My only Windows-account (I don't have the Microsoft-account (skipped it by disabling internet access while installing Windows 10)) is a administrator-type account with a custom name, furthermore: I disabled UAC. So by default applications run as admin on my laptop i.e. I don't need to rightclick start-button and choose Command Prompt (administrator), Command Prompt is doing the same on my laptop. This makes me not an expert in knowing the difference between 'normal?' and elevated?.
---
Edit: just sent an email about your UAC and admin question, but the answer was already in this post before I saw your email

[BugSplatter]

just sent the logile
tested more than 3 times: results are +- the same, succeeds if I'm lucky, but most of the times fails

Also:
- when I was testing yesterday with Calculator, the r was pressed in Calculator because Calculator said “Cannot divide by zero” which is seen if I manually press r, so therefore XMBC got the press from the controller.
- the fact that {ACTIVATE} is done, is a reaction of me having pressed the button on the controller & XMBC reacted on that
- I've just checked again using StopWatch and saw the orange lighting up of the button in XMBC

* so I'm confused about XMBC not getting the mouseclick when you test it

[phil]

* so I'm confused about XMBC not getting the mouseclick when you test it

It is because I installed stopwatch (which requires admin) which then launced stopwatch (as admin).
When stopwatch runs as admin, xpadder is unable to send the button unless it is also running as admin.
You wont have this problem with UAC disabled!

[BugSplatter]

I've sent the logfile

Everything is working again, you are a lifesaver

I don't know if this means that it's all finished, but i'm happy bc it's working & if you need anything from me again for whatever reason, let me now, I will be checking the forum a while longer (I check it once in a while out of curiosity anyway)

again thanks for you're time and fixing this

[phil]

Ahhh I thought so looking at the logs... But what is really weird, it didn't get the the code I changed, its just working again now.
The only difference, a small (20ms) delay before calling the Windows API to set the widow active...
Which I had taken out in 2.20.3....

So the only question now is, does it undo the fixes I made for others in 2.20.3 hahaha... I will push out Beta 11 to all and get them to test it too!

Thanks for your patience, detail and assistance - always makes things easier to manage!

[BugSplatter]

glad that it helped, and I'm going to press a few buttons many times