SlowCoder74

Worked like a charm. Thank you.

Either the site incorrectly anchored the link due to the parens, or my Firefox did it. I copied the entire link and it worked. Thank you for the info.

Thank you for the hint. I'm guessing we're talking about SendCapsLockMode. I'll give it a try tomorrow.

The link is broken, but that sounds logical.

send("{CAPSLOCK on}") send("{NUMLOCK on}") send("{SCROLLLOCK on}") I'm finding that the above code seems to work for the NUM and SCROLL locks, but not always for CAPS lock. When I execute the code for CAPS, I see the CAPS light on the keyboard flash for a split second, then revert to previous state, whether I use ON, OFF or TOGGLE. Is there any known cause for this activity? As far as I can tell, there is no other software running that would trip the CAPS lock back. If it makes a difference, I'm running Windows 7.

Yes, the file version was unrecognized apparently. I changed it to 2012.11.27.0 and it now successfully recognizes the information. Thank you.

Here is the output from my compile ... >"C:\Program Files (x86)\AutoIt3\SciTE\AutoIt3Wrapper\AutoIt3Wrapper.exe" /ShowGui /in "C:Usersqme9401DesktopKeyStateNotifyKeyStateNotify.au3" +>13:30:01 Starting AutoIt3Wrapper v.2.1.0.8 Environment(Language:0409 Keyboard:00000409 OS:WIN_7/Service Pack 1 CPU:X64 OS:X64) -> No changes made.. >Running AU3Check (1.54.22.0) from:C:Program Files (x86)AutoIt3 +>13:30:02 AU3Check ended.rc:0 >Running:(3.3.8.1):C:\Program Files (x86)\AutoIt3\Aut2Exe\aut2exe.exe /in "C:Usersqme9401DesktopKeyStateNotifyKeyStateNotify.au3" /out "C:Usersqme9401DesktopKeyStateNotifyKeyStateNotify.exe" /nopack /comp 2 +>13:30:04 Aut2exe.exe ended.rc:0 >13:30:04 Performing the Program Resource Update steps: ...>Updating Program Version information. ...>Setting Program ExecutionLevel Manifest information to asInvoker ...>Updating Program Manifest information. ...>Adding 4 Icon(s). +>13:30:04 Program Resource updating finished successfully.rc:0 >Running:(3.7.0.0):C:\Program Files (x86)\AutoIt3\Aut2Exe\upx.exe" --best --compress-icons=0 -qq "C:Usersqme9401DesktopKeyStateNotifyKeyStateNotify.exe" 682739 -> 335091 49.08% win32/pe KeyStateNotify.exe +>13:30:06 UPX Ended: rc:0 +>13:30:06 Created program:C:Usersqme9401DesktopKeyStateNotifyKeyStateNotify.exe >Exit code: 0 Time: 5.071

Will do so tomorrow ...

Ok, I compiled, and it added #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_Res_Comment=Notify when Caps/Num/Scroll Lock keys toggled. #AutoIt3Wrapper_Res_Description=Key State Notify #AutoIt3Wrapper_Res_Fileversion=20121127.1 #AutoIt3Wrapper_Res_requestedExecutionLevel=asInvoker #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** to the source. However, when I view the file's properties it doesn't show the updated info. Could it be because I am using Windows 7?

It took you a little over 3 minutes to answer my question. Way too slow. Think you can speed it up next time? (I jest of course!) I'll look at that. Thank you.

Is there a way to fill in the details, as shown when right-clicking on a .exe file and selecting the Details tab? For instance, product name, and version? Also, currently, when I right-click on one of my AutoIT .exe projects, it shows the file version 3.3.8.1 (AutoIT version). Can that be overridden?

I think that is exactly what I needed. Thanks!

#Region ### START Koda GUI section ### Form= $frmStatePopup = GUICreate("", 227, 42, 1, 1,$WS_POPUPWINDOW,$WS_EX_TOPMOST,WinGetHandle(AutoItWinGetTitle())) ;$frmStatePopup = GUICreate("", 227, 42, 1, 1,$WS_POPUPWINDOW,Default,WinGetHandle(AutoItWinGetTitle())) GUISetBkColor(0x800000) $lblStateNotify = GUICtrlCreateLabel("TEST", 8, 8, 212, 28) GUICtrlSetFont(-1, 14, 800, 0, "MS Sans Serif") GUICtrlSetColor(-1, 0xFFFFFF) GUISetState(@SW_HIDE) #EndRegion ### END Koda GUI section ### Whenever I use GUISetState(@SW_SHOW,$frmStatePopup) to popup the window, it steals focus. This is just a popup window, and I don't want focus transferred from the user's current window. I could go the route of getting the current window's hwnd, then showing the popup, then quickly refocussing on the user's window again. ... But is there a better way?

It's a little too easy to get a full process list and PID. But what I need to be able to do is; 1. find out who the owner user of the processes is, and 2. if the process belongs to a window.

Yeah, that sounds like it could work for what I needed, if it weren't for the requirement for literal source path. My program could be launched from any location. I developed my own piggybacker utility, so now I can put my two progs together and it only prompts for UAC for the functions that require it.

What is the upper limit to [count] for the FileRead command?

Will do. Thank you all!

I think of it this way ... I'm probably only using 1/100th of the actual interpreter code to run a simple command like "shutdown". Therefore I was inquiring if there was a way to trim/remove the unused portions. I guess something like the obfuscator you mentioned, but for the interpreter. One of my projects at work is a tool that needs access to UAC for only some functions, but not others. An older version of it is being used by IT throughout our division, and works good on XP. Now I'm working on Win7 compatibility, and UAC gets in the way. The tool needs to be exactly 1 executable, downloaded via web. Unless I want UAC bugging people every time they run it, I've found that it's necessary to have 2 executables. Therefore, I've come up with the idea to piggyback the UAC enabled executable on the main one. When needed, the main EXE will extract the piggybacked one to the temp folder, and execute it. If a single EXE has a minimum size of 300KB, then I'm looking at a minimum of 600KB, probably closer to 700-800K once combined. I appreciate the input, but the "shutdown" was just an example to demonstrate the use of a single command. I could have used 'msgbox(0,"","Hi")', just the same.

I see that UPX is able to compress the header of my compiled executables. Say I create a program with just 1 'shutdown' command, and compile it. The size is 635KB without UPX. With UPX it's 296KB. 635KB is HUGE, especially for just one command. UPX greatly reduces it by about 50%, but even at 296KB, that's pretty big for such a simple program. What else can be done to shrink a file even smaller? Is there a way to only include required components of the header?

This is what I thought. Thanks for that clarification. As it is, I use runas to call my script in elevated access, but UAC buggers it all up in Vista. I'm now looking into the link AdamUL sent. Not particularly an option. My script may be downloaded from a webpage. Therefore having multiple executables would be a problem. I need to keep it a single file.

Ok, let me clarify ...1. Tool run under limited user context. 2. Admin user logs into the tool with their admin credentials. The tool authenticates the admin user's credentials against AD. 3. Tool runs 2nd instance of itself using RunAs, with the admin user's credentials. 4. 2nd instance of tool performs admin level task, then closes. Where I have a problem is at #4. In Windows 7, it has been established that, even with user admin privileges, the tool cannot successfully write to certain parts of the registry ... See I don't want the tool to display the UAC prompt unless one of the functions requires that level of access. However, it seems, no matter where in the code I put #RequireAdmin, say inside an "IF i need admin access THEN" statement in the 2nd instance, it always shows the prompt. Therefore, I get prompted both when the tool is run under the user context, then again when the tool runs itself again under the admin user context.

My program is designed to run under the context of a limited user. It requires an admin user login for some functionality, so once that is gathered, it runs a 2nd instance of itself with the admin user privileges. I would like to only have the #RequireAdmin activate under the 2nd instance. However, it seems no matter where in the code I put #RequireAdmin, it prompts each time the program is run at all. Is there a way to get past this?

Ugh ... grrr ... pffff ... Well, that stinks. But it's better than nothing. Thank you.

Son ... Of ... A ... Bleep ... Yes, I see it works for me also. This means it's an access problem, even though I am a network admin, as well as explicitly in the local Administrators group on the PC. No way to get past that without it prompting me if it's ok?

Coming back to this after a while ... I read through that, and pulled up nothing valuable. Maybe I don't know how to read. I've compiled my code as 32 bit and 64 bit, tried HKLM and HKLM64, and WOW6432Node, and continue to get a failure. Note, that I can read the data fine using $sHive = "HKLM" if @OSArch = "X64" or @OSArch = "IA64" then $sHive = "HKLM64" ;if 64bit system, modify hive location $RegAutoLogon = regread($sHive & "SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon","AutoAdminLogon")