> So if I understand you correctly, its is workign much worse. Rather than > failing intermittently, it never properly sends the ` until you manually set > the focus away and then back. > > Or was that the same behaviour as before, only with this version it happens > all the time rather than intermittenly. > > I uploaded a new version which uses a different approach to send the keys.
I don't think it was much different. With the latest version you uploaded, there is still a delay in sending the ` key...but I think that there is a loop that's running before the ` is allowed to be sent from powerpro...and it's that loop that's causing the delay. If I had to guess how the hotkey/keyboard macro functions work it'd be something like: - powerpro gets the hotkey trigger - Powerpro checks what current window has focus - powerpro verifies the current window focus hasn't changed - powerpro sends the eaten key to the window I feel that it's between 2 and 3 that there's a validation loop verifying window focus or identifying something and the loop keeps getting different results and isn't passing out of the loop to send the key. If I change focus to a window type that never has the problem (firefox for example) whatever the check powerpro is waiting on is satisfied and it sends the key to the window. ----------------------------- Summary of what is occurring right now with latest build just so we're on the same page: There are two "classes" of program windows. - First class of window keyboard macro works perfectly, and send the eaten key right away - Second class of window keyboard macro doesn't get typed (retyped) right away (with latest version it sends after a 2-10 seconds, where before it would hold the eaten key indefinitely until there was window focus changes). If I use the mouse to change focus to the first class of window that doesn't have a problem, the macro key will be typed immediately and the looping debug messages stop. While focus is in the notepad window, and the macro key has been hit but hasn't been typed there's a looping debug output. ----------------------------- In the debug output: 00928 47 Notepad**Untitled - Notepad 329396 506b4 0 0 Wed Aug 05 09:15:48 2009 What is the first 47, and what is 506b4 ? When it's looping, I'm getting: 00928 47 Notepad*<snip> 00929 47 Notepad*<snip> 00930 62 Notepad*<snip> 00931 47 Notepad*<snip> 00932 47 Notepad*<snip> 00933 47 Notepad*<snip> 00934 62 Notepad*<snip> 00935 47 Notepad*<snip> 00936 47 Notepad*<snip> 00937 47 Notepad*<snip> 00938 46 Notepad*<snip> 00939 63 Notepad*<snip> The series of 47, 62, 63 is not in any pattern but it is looping and the debug is changing while the eaten key isn't sent. > I found the following on MSDN help regarding the sendinput function, which > the current version which you are have tested on is using. I don't really > understand the Vista (and I presume windows 7) concepts to which it refers; > does it make sense to you? Reading about UIPI and IL levels I've seen some places that say it's linked to UAC...but I have UAC disabled. I think it's still in effect even with UAC off. It says that you can raise it by adding the running user as an admin, and using the RUN AS command to run as admin but even when doing that I'm still having the same results. I see from: http://www.anvir.com/user-interface-privilege-isolation.htm "UIPI is not a security boundary, and does not aim to protect against all shatter attacks. UI Accessibility Applications can bypass UIPI by setting their "uiAccess" value to TRUE as part of their manifest file. This requires the application to be in the Program Files or Windows directory, as well as to be signed by a valid code signing authority, but these requirements will not necessarily stop malware from respecting them." From here: http://www.minasi.com/apps/ it looks like I have a commandline IL querier. Powerpro reports as a "medium" and notepad reports as "unknown" "File c:\windows\notepad.exe's integrity level: Unknown ("unknown" because SDDL string was "S:AI".) Inheritance flags: Integrity policies: No read up: disabled No execute up: disabled No write up: disabled (Actually, in this "no policy" case, Windows seems to behave as if there is a "no write up" policy in effect.)" I'm going to try and work on this more and will post what I find...gotta go do some work :) I see I can set the IL on notepad to something but I need to figure out how to reset it back to "unknown" before I do that so I can do other testing if that fixes the problem. >> > Also, if there are any debug lines in debug.txt containing >> "openprocess" pls post that line and the next 2. This is debug output >> from the other problem with unable to open process in some circumstances. > > I think this error is ignorable so I will remove this debug output. I have a feeling it's some special windowless object powerpro is seeing, it should be fine. David Troesch | Atlanta, GA | ICQ# 2333123 "You are the only real obstacle in your path to a fulfilling life." Funstuff: Defeat: For every winner, there are dozens of losers. Odds are you're one of them. www.despair.com
