John

I found a description in MSDN where is is explained exactly how the quotes are used by windows and the routine windows falls back on in their absents. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx In effect by AutoIt not accepting these quotes passed as strings as valid it forces windows to fall back into a search routine if this same sting is passed to windows by AutoIt. This can lead to an execution of the wrong program. If you have a path like: c:program filessub dirprogram name and a different program path exist like: c:program filessub dir.exe Then 'sub dir.exe' get executed in place of 'program name.exe' This doesn't create a name collision because a 'sub dir' folder, 'sub dir.exe', and 'sub dir.bat' file can all simultaneously exist in the same folder, as well as other executable file types. 'sub.exe dir' is also a valid folder name. So windows does officially support and document the use of quotes passed as path strings. Even without any errors having these quote stings makes windows faster and more efficient without falling back on a search routine. Including the .exe doesn't in itself bypass the search routine since 'name.exe' is a perfectly valid folder name.

If it is a working directory issue you need to change @WindowsDir to @SystemDir, since you say it's in the system32 folder. Shouldn't make much difference on the path that way, but that can also depend on Ghost32.exe.

To test Melba23's idea I would add ConsoleWrite($OCRString & @CRLF) After it was defined. I also noticed you set the StringSplit flag to disable the array count in the first element ($OCRArray[0]), yet you began you For loop at 1. This means you are skipping the first element of the array by starting the loop at $OCRArray[1] instead of $OCRArray[0]. Starting $i at 1 is how you would do it if you hadn't set the StringSplit flag to not put the array element count in $OCRArray[0].

I assume your "edit field" is a GUICtrlCreateEdit. If you want to break lines then just use a @CRLF. $string = "Line 1" & @CRLF & "Line 2"

I don't really get what exactly you cod is supposed to act on, but I used a fluffed ini with the contents: [App1] version=version 0.1 setup=setup true User=Username Password=mypass MSI=install.msi filesize=6.2 meg filetime=1952 [app2] version=version 0.2 setup=setup true User=Username2 Password=anotherpass MSI=install.msi filesize=8.1 meg filetime=1958 The sample code: Opt("TrayMenuMode", 1) Opt("TrayOnEventMode",1) local $sections = IniReadSectionNames(@ScriptDir &"\CHSofT.ini") For $i = 1 To $sections[0] TrayCreateItem($sections[$i]) TrayItemSetOnEvent(-1,"_runme") Next TrayCreateItem("Exit") TrayItemSetOnEvent(-1,"_runme") While 1 Sleep(50) WEnd Func _runme() $sect=TrayItemGetText(@TRAY_ID) If $sect="Exit" Then Exit $prog1=IniRead(@ScriptDir &"\CHSofT.ini", $sect, 'setup', 'Error reading file') $prog2=IniRead(@ScriptDir &"\CHSofT.ini", $sect, 'MSI', 'Error reading file') ;~ _runme($sect,$prog1,$prog1) is the equivalent of _runme($sections[$i],$prog[$i][2],$prog[$i][5])) ;~ Though you can do you function stuff here now and retrive anything from the ini under $sect. MsgBox(0,"",$sect &" | "& $prog1 & " | "& $prog2) EndFunc

Yes, I have written a complete open with replacement shell for windows this way, that would give a unique drawer of choices for every filetype and act as a drawer of options for every link toolbar link. Presently doing a rewrite so that configuring it doesn't require manually editing the config file. All files are associated with the same AutoIt program on my windows machine.

What I do is call the function without args, use a Switch on the text of the Tray Item. This is apparently $prog[$i][0] in your code. So your: TrayItemSetOnEvent($tempprg, _runme($sections[$i],$prog[$i][2],$prog[$i][5])) Would look like TrayItemSetOnEvent($tempprg, "_runme") Then the _runme() would contain a Switch with cases that depend on the the string defined by: $sections[$i],$prog[$i][2],$prog[$i][5]) This also has the added advantage that you don't have to pre-read anything from the ini except the $sections. Wait till the function is called to read the section values and run $sections[$i],$prog[$i][2],$prog[$i][5] based on the return there.

Ok, I tried it and see what's you mean. You can fix it in the line in the _KeyProc() function where it says: If $vkCode <> 0x72 Then Return 1The 0x72 is the F3 key. Change this line to: If $vkCode <> 0x72 And $vkCode <> 0x55 And $vkCode <> 0xA0 Then Return 1This leaves F3, Left Shift, and U unblocked allowing your last example to work. For a complete list of the vkCode keys go here: http://www.kbdedit.com/manual/low_level_vk_list.html

It looks like Shadow Defender may not associated with a particular file type. Not sure and the download site for it doesn't look that helpful. Do you know where Shadow Defender is, or a shortcut to it? Does clicking the right click menu bring up anything different than clicking the shortcut? You always just search the 'Data' parts of the registry for 'Shadow' to find its command strings.

That is understandable, which is why I called it a nitpick bug. I wouldn't waste too much time simply on saving script developers a few lines of code either. It does seem a relatively straightforward and easy change though.

HotKeySet key parameters are exactly the same as with Send(). Look up the Send function in the AutoIt help file and it'll describe how to use any set of keys you wish.

Yes, I read the thread. In particular relevance is the _WinAPI_PathFileExists() function demonstrating a windows API handling in the same way as as FileExists. There are 2 points that moot this fact. First, AutoIt is not the windows environment, but an scripting language for interacting with the windows environment. Second, and more importantly, windows does not depend solely on this one API for validating paths, just as I am suggesting with the FileExist() function. Here's a demonstration: FileOpenDialog ( "title", "init dir", "filter" [, options ] ) 1 = File Must Exist (if user types a filename) 2 = Path Must Exist (if user types a path, ending with a backslash) To use more than one option, add the required values together. FileOpenDialog('Unquoted path:', @ScriptDir, "All (*.*)",3) Now if you enter: "C:Program FilesWindows Media Playerwmplayer.exe" With or without quotes it comes back a valid path. Windows is not strictly dependent on PathFileExistsW in shlwapi.dll path validation, but itself preprocesses what subset of a string to validate with that API. This is why paths and arguments are separated by individual sets of string quotes in the registry by default, so that PathFileExistsW can be applied to the proper subset of the string in relevant cases. Otherwise certain command lines would simply be too ambiguous for windows to parse. For AutoIt, or FileExist in particular, to mimic this behavior requires validating single quoted path strings when passed as strings.

BrewManNH, Yes, the first quotes should always be consumed by AutoIt to indicate a string. The second treated like windows treats them, as valid parameters to a path. Any beyond that is up to the script developer to deal with. I know this is a nitpick, but also allows extended functionality if handled properly. I have used the following function as a workaround, and it finds valid paths with args even when no quotes are provided. Though after pulling some path strings from the registry it occurred to me that windows standard behavior makes requiring passing the quotes as strings, to separate paths and arguments, far superior to this method. Func _FileExistEx($f) $f=StringReplace($f,'"','',0,2) Local $a=FileGetAttrib($f) If StringInStr($a,"D",2) Then Return 1 Local $i=StringInStr($f,' ',2,1,StringInStr($f,'.',2)) Local $s=StringLeft($f,$i) While $i<=StringLen($s) $s=StringLeft($f,$i-1) If FileExists($s) And Not StringInStr(FileGetAttrib($s),'D') Then Return 1 If Not StringInStr($f,' ',0,1,$i) Then Return 0 $i=StringInStr($f,' ',0,1,$i+1) $s=StringLeft($f,$i) WEnd Return SetError(1) ; Shouldn't happen EndFunc

Yes, I understand how quotes work in and out of AutoIt. The point here it that when quotes are passed (as strings) in AutoIt FileExists fails, but when quotes are passed as strings from AutoIt to windows it is perfectly valid in all cases. Allowing FileExists to be passed string paths containing the quotes (as strings) then has the advantage of added functionality for working with windows and easily validating paths with arguments, which FileExists normally fails on. Example: $str = '"C:Program FilesWindows Media Playerwmplayer.exe"' $test=FileExists($str) Returns false. However: $str = '"C:Program FilesWindows Media Playerwmplayer.exe"' $test=Run($str) Works fine, as it does in all cases. This would allow strings like '"C:Program FilesWindows Media Playerwmplayer.exe" %1' to be properly validated as a valid path using FileExists

This should work regardless: #include HotKeySet("{F3}", "_UnBlock") HotKeySet("{F4}","_Block") Global $pStub_KeyProc, $pStub_MouseProc, $hHookKeyboard, $hHookMouse Func _Block() $pStub_KeyProc = DllCallbackRegister("_KeyProc", "int", "int;ptr;ptr") $pStub_MouseProc = DllCallbackRegister ("_Mouse_Handler", "int", "int;ptr;ptr") $hHookKeyboard = _WinAPI_SetWindowsHookEx($WH_KEYBOARD_LL, DllCallbackGetPtr($pStub_KeyProc), _WinAPI_GetModuleHandle(0), 0) $hHookMouse = _WinAPI_SetWindowsHookEx($WH_MOUSE_LL, DllCallbackGetPtr($pStub_MouseProc), _WinAPI_GetModuleHandle(0), 0) ConsoleWrite("Blocked" & @CRLF) EndFunc Func _UnBlock() DllCallbackFree($pStub_KeyProc) DllCallbackFree($pStub_MouseProc) _WinAPI_UnhookWindowsHookEx($hHookKeyboard) _WinAPI_UnhookWindowsHookEx($hHookMouse) ConsoleWrite("Unblocked" & @CRLF) EndFunc Func _KeyProc($nCode, $wParam, $lParam) If $nCode < 0 Then Return _WinAPI_CallNextHookEx($hHookKeyboard, $nCode, $wParam, $lParam) Local $KBDLLHOOKSTRUCT = DllStructCreate("dword vkCode;dword scanCode;dword flags;dword time;ptr dwExtraInfo", $lParam) Local $vkCode = DllStructGetData($KBDLLHOOKSTRUCT, "vkCode") If $vkCode <> 0x72 Then Return 1 _WinAPI_CallNextHookEx($hHookKeyboard, $nCode, $wParam, $lParam) EndFunc Func _Mouse_Handler($nCode, $wParam, $lParam) If $nCode < 0 Then Return _WinAPI_CallNextHookEx($hHookMouse, $nCode, $wParam, $lParam) Return 1 EndFunc While 1 Sleep(100) WEnd Edit: The forum code tags are what is stripping the <WinAPI.au3> from the #include