Albuquerquefx

Not true, you can build an event sink that will internally fire linked functions. Here is a psuedo-example (I'm not doing the WMI impersonate levels, you will need error checking, and obviously other functions blah blah): ; WMI object creation for CIMV2 namespace $gobjWMI_CIMV2 = ObjGet("winmgmts:\\.\root\cimv2") ; WMI event notification sink for power management $gobjWMI_PowerEVT_Sink = ObjCreate("WbemScripting.SWbemSink") ObjEvent($gobjWMI_PowerEVT_Sink , "PowerEVT_SINK_") ; Build notifier object for power management events $gobjWMI_CIMV2.ExecNotificationQueryAsync($gobjWMI_PowerEVT_Sink, "Select EventType from Win32_PowerManagementEvent") ;; Sleep forevAr - make sure to build a hotkey somewhere to allow you to terminate this process... While 1 Sleep(100000) WEnd ;; Power Management event sink function Func PowerEVT_SINK_OnObjectReady($wmiObject, $wmiAsyncContext) $intEvent = $wmiObject.EventType Switch $intEvent Case 4 ; Machine is entering suspend") Case 7 ; OS reports resume from suspend is complete") Case 10 ; AC <-> DC switch Case 11 ; OEM Power event... Case 18 ; Hardware triggered resume from suspend... Case Etc... ; You can case these out from the constant defines mentioned earlier in this thread EndSwitch EndFunc This code is ugly, I kinda slapped it together for this thread, but you get the idea. No windows necessary, not even a hidden one. I use this for automatic detection of when the WHS connector on my various machines start up in the wee hours of the morning to do their backup. The box wakes up, triggers my app, it goes watching for the backup service to start. If it does within five minutes, I track the process until it completes, and then force the box to go back to whatever sleep state it was in (hibernate / suspend). Otherwise it drives the wife nuts as she has automatic sleep turned off on her netbook, which means it stays powered on and her OCD side can't take that

Only posted once, didn't refresh my page, didn't encounter any errors, but I did preview my post probably abou that many times. And it was a preview, this isn't my first time using a forum. Sounds like a bug to me...

Huh? I don't know what you're talking about? I previewed my post a few times to make sure the code looked correct, but I only posted it once (and searching by my own user ID, I haven't posted anything in this forum in months...) Tried that, didn't work Did it work for you?

I've been searching through these forums for a way to "see" a 16-bit Windows app running, and it looks like there wasn't much luck thus far. A few people mentioned VDMDBG.DLL available from Win2K on, so I referenced this MSKB article and arrived at this really basic chunk of code: $astrNTVDM = ProcessList("ntvdm.exe") For $i = 1 to $astrNTVDM[0][0] _VDMEnumTaskWOWEx(Hex($astrNTVDM[$i][1])) Next Func _VDMEnumTaskWOWEx($dwProcessId) MsgBox(Default,Default,"Got here: " & $dwProcessId) $hDll = DllOpen("vdmdbg.dll") $hFnc = DllCallbackRegister("_TaskEnumProcEx","int","dword;hwnd;hwnd;str;str;lparam") DllCall($hDll,"int","VDMEnumTaskWOWEx","dword",$dwProcessId,"ptr",DllCallbackGetPtr($hFnc),"lparam",Chr(0)) If @error Then MsgBox(Default,Default,"DllCall didn't work") EndIf DllClose($hDll) DllCallbackFree($hFnc) EndFunc Func _TaskEnumProcEx($dwThreadID,$hMod16,$hTask16,$strModName,$strFileName,$lparam) MsgBox(Default,Default,$dwThreadID & ": " & $strModName & "|" & $strFileName) Return False EndFunc So here's what is supposed to happen... I poll the current processlist for any running NTVDM's, and from their PID's I can then do a DLL call to enumerate all the 16-bit tasks (module, full path, and thread ID) inside of it. The documentation is very clear on how it works, and I'm not getting any errors. But I'm also not getting ANY output while running a known 16-bit Windows app. They have me do a VDMEnumProcessWow() to get all those NTVDM PID's to make sure they don't contain DOS apps, but for sake of this example, I'm running a little crappy 16-bit Windows app that isn't DOS so I know my only running NTVDM is acceptable for using with the VDMEnumTaskWowEx() function. Nevertheless, I also wrote the appropriate VDMEnumProcessWow() dllcall + callback function with the exact same results as this one: absolutely zero output and no errors. Is there something obvious that I'm just not doing?

You could probably do this via a search of the system event log for the most recent WinLogon event that wasn't your admin account... Physically impossible in the current windows threading model. An application started under a user context will forever stay in that user context until it terminates. You can't hand-off control of a thread or process like that... Here's something that you might be able to try, but keep in mind that it may not be entirely reliable -- run the script as the LimitedUser account. Now you know who is running it... Then use the internal RunAs command to elevate to AdminUser, but use the special flag '0' to ensure that you don't load the admin's profile. RunAs("AdminUser",@LoginDomain,"Password",0,"rundll32.exe shell32.dll,Control_RunDLL sysdm.cpl,,3",@SystemDir,@SW_SHOW) I haven't tried this yet, but by not loading the profile of the Admin user, you may be able to force it to update the HKCU of LimitedUser instead...

So then, even your AutoIT script would be run under AdminUser's context? I've done a small bit of googling for that registry entry you mention, and even did another small bit of hacking on one of my Dell test rigs here at the office. Given all the constraints you've mentioned up to this point, that setting is effectively impossible for you to manipulate so far as I can tell. If you can "fix" the machine so that LimitedUser is able to launch your AutoIT executable (as in, with their own credentials) it may be possible to use RUNDLL32 to open up the performance pane and make the adjustments via the user interface. Otherwise, I can't find anything else that would help you.

Ok, I have a seperate question: You mentioned that LimitedUser cannot open executables -- how are they opening your AutoIT?

I think I get what you're saying... You've got two users: LimitedUser and AdminUser Since LimitedUser is, well, limited in what they can do, you're firing up something like Control Panel with AdminUser's credentials. Now, you want LimitedUser to take over and change the settings they require, but using the control panel that was spawned using AdminUser's credentials. If I got all of that right, the unfortunate part is this: it doesn't work that way. If you spawn a process under someone else's credentials, then any / all the changes made by that application will be under the user context of the alternate credentials as well. You really do only have one option: your EXE needs to determine the GUID of LimitedUser, then use the AdminUser's credentials to elevate up, and then make the registry change to HKEY_Users\<GUID>\...

My primary development platform is now Vista; I've been testing against both 32-bit and 64-bit versions without issue. I still do regression testing on XP32 and 64 as well, and so far I have not found any differences in window handling functions. I have found differences in OS DLL handling, but that's expected behavior in most cases.

Heh, that Krumsick utility is a GUI interface to the reg key I posted above. Microsoft doesn't provide any other way to remap those "special" keys unless you're working with an HID driver...

keyboard Hooks would only work if you wrote yourself a program in C#, or else you built / found a DLL that would allow you to do a DLLCall function. There isn't any "stock" interface to that functionality in AutoIT that I'm aware of. And hooks can be precarious things; they're quite timing dependent. If your hook app doesn't acknowledge the event in a specific timeslice, the hook will get passed back to the system for further work. It would be far easier to remap the key(s) through altering the scancode than it would to write a keyboard hook IMO

I can't see exactly what you're doing, but I think a file write is not the answer. It looks like you're using that file to store some temporary data between loops and whatnot; you'd be much better served with another array for comparisions. In any case, regardless of what you think of my suggestion, here's the fix... When you specify the file name directly in the File...() operation, you don't need to do seperate opens, reads, and closes. So, instead of: FileOpen("pos.txt") ... FileWrite("pos.txt","blahblah") FileClose("pos.txt") FileDelete("pos.txt")

Not at an OS-level there isn't, at least according to Microsoft. I guess in theory you could write your own keyboard driver, and "drop" the keys that you don't want. You could then swap the HID driver for your keyboard on the fly, and I believe that would take effect immediately versus a reboot. But if you're that good, then I'd say do it and lend me a free copy

I severely doubt it needs full access to the entire programs folder structure; I'm quite sure that was a stupid / general "go away" response from tech support. There's no reason that sibelius needs access to C:\Program Files\Microsoft Office for example I strongly suggest you take Skruge's advice and look at Regmon to see what it's doing to the registry; I'd wager either that or it's trying to write temp data to some stupid protected location like C:\Windows

If you truly want to disable those keys, I have only found ONE way to make it work 100% of the time. Unfortunately, this is an OS change and so requires a reboot both to enable and to disable. Fortunately, it's a change that is administered through the registry, so your AutoIT script can apply the registry entry and on the next powercycle it will "just be there". Here's the problem: this is UGLY. I warned you Microsoft Developer Network knowledgebase article on scancode mapping: http://www.microsoft.com/whdc/device/input/w2kscan-map.mspx And you'll need to know the scancodes of the keys you wish to remap: http://www.randyrants.com/sharpkeys/ Here's an idea -- dont' remap ALL the keys, just remap the ones that are common. We wanted to kill off ALT-F4 and CTRL-ALT-DEL. Well, you don't need to remap five keys, you only needed to remap one: ALT. Once it's "broken", the key-combo functions that rely on the ALT key stop working too. Restoring the keyboard back to default is as simple as deleting the registry key described in that MSDN article. But again, this isn't an instant-on / instant-off process. It requires a reboot to enable, and a reboot to disable.