Inno Setup registry entries to open multiple files with AU executable

[Garp99HasSpoken]

I have the following [Registry] entry in an Inno Setup .iss file

; TV convert filters (Extra 2)
Root: HKCR; Subkey: "*\shell\{#MyAppName}{#MyExtra2}"; ValueType: string; ValueName: ""; ValueData: "{#MyAppTitle} {#MyExtra2}"; Flags: uninsdeletekey
Root: HKCR; Subkey: "*\shell\{#MyAppName}{#MyExtra2}\DefaultIcon"; ValueType: expandsz; ValueName: ""; ValueData: "{app}\{#MyAppExeName},-5"; Flags: uninsdeletekey
Root: HKCR; Subkey: "*\shell\{#MyAppName}{#MyExtra2}\command"; ValueType: string; ValueName: ""; ValueData: """{app}\{#MyAppExeName}"" ""/f"" ""{app}\{#MyAppName}{#MyFilter}.txt"" ""/ni"" ""%1"" ""%2"" ""%3"" ""%4"" ""%5"" ""%6"" ""%7"" ""%8"" ""%9"""; Flags: uninsdeletekey
Root: HKCR; Subkey: "Directory\shell\{#MyAppName}{#MyExtra2}"; ValueType: string; ValueName: ""; ValueData: "{#MyAppTitle} {#MyExtra2}"; Flags: uninsdeletekey
Root: HKCR; Subkey: "Directory\shell\{#MyAppName}{#MyExtra2}\DefaultIcon"; ValueType: expandsz; ValueName: ""; ValueData: "{app}\{#MyAppExeName},-5"; Flags: uninsdeletekey
Root: HKCR; Subkey: "Directory\shell\{#MyAppName}{#MyExtra2}\command"; ValueType: string; ValueName: ""; ValueData: """{app}\{#MyAppExeName}"" ""/f"" ""{app}\{#MyAppName}{#MyFilter}.txt"" ""/ni"" ""%1"" ""%2"" ""%3"" ""%4"" ""%5"" ""%6"" ""%7"" ""%8"" ""%9"""; Flags: uninsdeletekey

Root: HKCU; Subkey: "*\shell\{#MyAppName}{#MyExtra2}"; ValueType: string; ValueName: ""; ValueData: "{#MyAppTitle} {#MyExtra2}"; Flags: uninsdeletekey
Root: HKCU; Subkey: "*\shell\{#MyAppName}{#MyExtra2}\DefaultIcon"; ValueType: expandsz; ValueName: ""; ValueData: "{app}\{#MyAppExeName},-5"; Flags: uninsdeletekey
Root: HKCU; Subkey: "*\shell\{#MyAppName}{#MyExtra2}\command"; ValueType: string; ValueName: ""; ValueData: """{app}\{#MyAppExeName}"" ""/f"" ""{app}\{#MyAppName}{#MyFilter}.txt"" ""/ni"" ""%1"" ""%2"" ""%3"" ""%4"" ""%5"" ""%6"" ""%7"" ""%8"" ""%9"""; Flags: uninsdeletekey
Root: HKCU; Subkey: "Directory\shell\{#MyAppName}{#MyExtra2}"; ValueType: string; ValueName: ""; ValueData: "{#MyAppTitle} {#MyExtra2}"; Flags: uninsdeletekey
Root: HKCU; Subkey: "Directory\shell\{#MyAppName}{#MyExtra2}\DefaultIcon"; ValueType: expandsz; ValueName: ""; ValueData: "{app}\{#MyAppExeName},-5"; Flags: uninsdeletekey
Root: HKCU; Subkey: "Directory\shell\{#MyAppName}{#MyExtra2}\command"; ValueType: string; ValueName: ""; ValueData: """{app}\{#MyAppExeName}"" ""/f"" ""{app}\{#MyAppName}{#MyFilter}.txt"" ""/ni"" ""%1"" ""%2"" ""%3"" ""%4"" ""%5"" ""%6"" ""%7"" ""%8"" ""%9"""; Flags: uninsdeletekey

"C:\Program Files (x86)\VideoRename\VideoRename.exe" "/f" "C:\Program Files (x86)\VideoRename\VideoRenameFilters.txt" "/ni" "%1" "%2" "%3" "%4" "%5" "%6" "%7" "%8" "%9"

The items in ValueData are being properly set in the Windows 7 registry and the parameters are passed except only *one* file is being passed to the executable.

Basically, in Windows Explorer I select 2 (or more) files and right-click to get context menu, select my AU compiled program, and I want my program to execute with the files passed in.

The problem is that my program is called for each file individually.

I expected the "%2", etc to work for up to 9 parameters/files to be passed in. Double-quotes are in case of spaces in the full path of the filenames.

What have I missed?

What else can I try?

[guinness]

What have I missed?

What else can I try?

It won't work like that without creating a shell extension handler.

A workaround I created >>

[Garp99HasSpoken]

Done some reading of the threads, and the example of registering the program which opens Notepad.

Do I understand this correctly...?

I need to use your example as a front-end program to my program (not Notepad) which will grab the file names and

pass these along to my program. So in effect, the right-click context menu entry in the registry will be the front-end program

which is what the user will see, and when the user selects 2+ files/folders, it will pass these along to my real program.

Edited March 15, 2013 by Garp99HasSpoken

[Garp99HasSpoken]

After getting the example code incorporated into my code, I see that what I called a front-end above is more like a daemon process that needs to be started up and then sits around waiting for 1 or more files passed to it with the context menu.

I run into a few problems with this method:

- first I need a way for adding the program to Windows Start-up folder which I might be able to figure out with Inno Setup

- once started, it conflicts with the same program but with different parameters passed in. I add 3 entries into the registry for the same program name but extra parameters (different config file) and options. Using the example code, I see the first entry's context menu change to "Start my prog" but the other two are unchanged. When the daemon running, the first option correctly passes only the new file names as expected.

Using the second two options will pass all the parameters as a file name, so instead of "Filename", I get "-f C:Program Files (x86)VideoRenameVideoRenameFilters.txt /ni Filename"

I will have to re-think how to best handle this -- multiple versions of the same program but different names perhaps.

[Richard Robertson]

A simpler solution is to let them each open a fresh process, but check to see if a process is already running and use IPC to pipe all the new filenames to it. For a more advanced mechanism, you could add a check to see when the last process was started instead of blinding referring all new files to the old process if you wanted to allow running more than one at a time.

[guinness]

A simpler solution is to let them each open a fresh process, but check to see if a process is already running and use IPC to pipe all the new filenames to it. For a more advanced mechanism, you could add a check to see when the last process was started instead of blinding referring all new files to the old process if you wanted to allow running more than one at a time.

Kind of how I did it in that example but I send the WM_COPYDATA to the first process.

[wraithdu]

There are other limitations to context menus, such as the total number of items you can select and operate upon (15 I believe). You might be better off to alter your workflow and use the Send to menu. There is no restriction to the number of files to act upon, and they are all sent in a single command.

Edited March 15, 2013 by wraithdu

[guinness]

_SendTo and _Startup UDFs in my signature.

[Garp99HasSpoken]

I will investigate the suggestions.

SendTo would be more inconvenient as it requires going into a submenu, but still possible if more than 1 file passed.

guinness, the example opens up Notepad to get a windows handle, how do I create an empty handle if I want it to be a non-gui daemon process?

[guinness]

I would just use SendTo.

[Garp99HasSpoken]

Ok.

Just FYI, a weird thing that I see in your Notepad example is that 11 parameters are passed in "-f filter.txt File1 empty2 empty3...empty9" which implies the "%1 %2 ... %9" is used but the passed in filenames are not substituted in for them.

[guinness]

Just FYI, a weird thing that I see in your Notepad example is that 11 parameters are passed in "-f filter.txt File1 empty2 empty3...empty9" which implies the "%1 %2 ... %9" is used but the passed in filenames are not substituted in for them.

I don't pass such parameters like that in my example, sorry. Perhaps you're talking about a different example?

[Garp99HasSpoken]

I was referring to the OP and the registry entry.

[MHz]

AFAIK, %1 is the parameter used to get all parameters passed. There is also %* though I have never found it to do anything. A cmd script does the %0 to %9 parameters so do not consider that the registry will behave the same. When the registry with %1 expands to multiple paths being passed then an executable will be opened multiple times. This is where context menu handlers (extensions) are used. The handlers reside in memory just to handle the tasks like multiple paths used in %1. So that is the choice you have.

As for your registry entries. Now, they are a concern. When you write filetypes and associations, then you have 2 places to write them.

HKCU\Software\Classes

HKLM\Software\Classes

HKCR is a merging of those 2 places so you can get to read the association without the need to read from multiple places.

Here is a quote from here that I found as reference

Important considerations about file types include:

• The HKEY_CLASSES_ROOT subtree is a view formed by merging HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\Software\Classes
• In general, HKEY_CLASSES_ROOT is intended to be read from but not written to. For more information, see the HKEY_CLASSES_ROOT article.
• To register a file type globally on a particular computer, create an entry for the file type in the HKEY_LOCAL_MACHINE\Software\Classes subkey.
• To make a file type registration visible to the current user only, create an entry for the file type in the HKEY_CURRENT_USER\Software\Classes subkey.

• An application can provide its own implementation of a verb, such as open or play, as shown in the following registry example.

Now, if you write to HKCR then undesirable results can happen. If the registry has the keys and values in HKCU\Software\Classes and you wanted to write them to HKLM\Software\Classes then HKCR will write them to the keys and values in HKCU\Software\Classes instead as the later has higher priorty. Thus it is a grave mistake to write to HKCR.

Here is a example I created to prove this. It has #RequireAdmin, so you may need to run Scite as admin to see the consolewrites.

expandcollapse popup

#RequireAdmin
; run scite as admin to see the ConsoleWrite

Global $old_value[3]
Global $new_value[3]

; HKLM write
If RegWrite('HKLM\SOFTWARE\CLASSES\.abcdef', '', 'REG_SZ', 'HKEY_LOCAL_MACHINE') Then
    _ReadAndMessage('HKLM write. OK')
EndIf

; HKCR write changes HKLM
If RegWrite('HKCR\.abcdef', '', 'REG_SZ', 'HKEY_CLASSES_ROOT') Then
    _ReadAndMessage('HKCR write. Changes HKLM. OK')
EndIf

;~ ; HKLM write again
If RegWrite('HKLM\SOFTWARE\CLASSES\.abcdef', '', 'REG_SZ', 'HKEY_LOCAL_MACHINE') Then
    _ReadAndMessage('HKLM write again. OK')
EndIf

; HKCU write
If RegWrite('HKCU\SOFTWARE\CLASSES\.abcdef', '', 'REG_SZ', 'HKEY_CURRENT_USER') Then
    _ReadAndMessage('HKCU write. OK')
EndIf

; HKCR write changes HKCU
If RegWrite('HKCR\.abcdef', '', 'REG_SZ', 'HKEY_CLASSES_ROOT') Then
    _ReadAndMessage('HKCR write. Changes HKCU. Not OK if you wanted HKLM to change')
EndIf

$type = '.abcdef'
$assoc = _Comspec('assoc .abcdef')
ConsoleWrite('--- Assoc returns' & @CRLF)
ConsoleWrite($assoc & @CRLF)

RegDelete('HKLM\SOFTWARE\CLASSES\.abcdef')
RegDelete('HKCU\SOFTWARE\CLASSES\.abcdef')

Exit

Func _ReadAndMessage($message)
    $new_value[0] = RegRead('HKCR\.abcdef', '')
    $new_value[1] = RegRead('HKCU\SOFTWARE\CLASSES\.abcdef', '')
    $new_value[2] = RegRead('HKLM\SOFTWARE\CLASSES\.abcdef', '')
    $string = ( _
        $message & @CRLF & _
        StringFormat('%-8s %-22s %-7s', 'HKCR', $new_value[0], _Changed($old_value[0], $new_value[0])) & @CRLF & _
        StringFormat('%-8s %-22s %-7s', 'HKCU', $new_value[1], _Changed($old_value[1], $new_value[1])) & @CRLF & _
        StringFormat('%-8s %-22s %-7s', 'HKLM', $new_value[2], _Changed($old_value[2], $new_value[2])) & @CRLF _
    )
    ConsoleWrite('--- ' & $string & @CRLF)
    $old_value = $new_value
;~     MsgBox(0x40000, @ScriptName, $string)
EndFunc

Func _Changed($value1, $value2)
    If $value1 == $value2 Then
        Return ''
    Else
        Return 'Changed'
    EndIf
EndFunc

Func _Comspec($parameter = '')
    Local $output, $pid
    $pid = Run('"' & @ComSpec & '" /c ' & $parameter, '', @SW_MINIMIZE, 2)
    Do
        Sleep(10)
        $output &= StdOutRead($pid)
    Until @error
    Return $output
EndFunc

The output will be

--- HKLM write. OK

HKCR HKEY_LOCAL_MACHINE Changed

HKCU

HKLM HKEY_LOCAL_MACHINE Changed

--- HKCR write. Changes HKLM. OK

HKCR HKEY_CLASSES_ROOT Changed

HKCU

HKLM HKEY_CLASSES_ROOT Changed

--- HKLM write again. OK

HKCR HKEY_LOCAL_MACHINE Changed

HKCU

HKLM HKEY_LOCAL_MACHINE Changed

--- HKCU write. OK

HKCR HKEY_CURRENT_USER Changed

HKCU HKEY_CURRENT_USER Changed

HKLM HKEY_LOCAL_MACHINE

--- HKCR write. Changes HKCU. Not OK if you wanted HKLM to change

HKCR HKEY_CLASSES_ROOT Changed

HKCU HKEY_CLASSES_ROOT Changed

HKLM HKEY_LOCAL_MACHINE

--- Assoc returns

.abcdef=HKEY_LOCAL_MACHINE

The 1st HKCR write is OK if you meant it to write to HKLM\Software\Classes. The 2nd HKCR write is not as it writes to HKLM\Software\Classes instead. So you may notice that HKCR is a mixture of both of the classes and writing to them is unknown from a script to where the entries may go to.

As for the Send To idea. It can handle muliple parameters as it is a context menu handler. It does have a limit on how many parameters you can pass. Been awhile since I last tested it though it maybe something like 1024 chars or number near that range on Vista/7. XP does much better and could do many times more, so take note of that when testing.

[MHz]

Correction on last post. The forum messes the code on reedit I notice so reposting the edit here.

The statement near the end

The 1st HKCR write is OK if you meant it to write to HKLMSoftwareClasses. The 2nd HKCR write is not as it writes to HKLMSoftwareClasses instead. So you may notice that HKCR is a mixture of both of the classes and writing to them is unknown from a script to where the entries may go to.

should be

The 1st HKCR write is OK if you meant it to write to HKLMSoftwareClasses. The 2nd HKCR write is not as it writes to HKCUSoftwareClasses instead. So you may notice that HKCR is a mixture of both of the classes and writing to them is unknown from a script to where the entries may go to.

[Garp99HasSpoken]

Ok thanks for info, I'll look into it.