Auto insert EnVar in path after select from dialog

[Fla$her]

It would not be desirable to spend too much time manually editing some of the paths with environments variable in configuration files when interacting with dialogs called in different ways:
• Configuration > View Mode > [>>] button
• Configuration > Language > [>>] button
• Configuration > Edit/View > [Associations...] button > [New type] button
• Configuration > Edit/View > [Configure internal viewer...] button > Multimedia > [>>] button
• Configuration > FTP > [>>] button
• Configuration > Plugins >>
• a) Configure packer plugins > [New type...] button
• b) Configure FS/Lister/Content plugins > [Add] button
• Configuration > Thumbnails > [>>] button
• Configuration > Log file > [>>] button
• Configuration > Ignore list > [>>] button
• Configuration > Packer > [>>] buttons
• Zip packer > [>>] buttons
• Change single button > [Change >>] > Insert file name...
• Change user command: em_ > [Change >>] > Insert file name...
• Edit file type (Internal Associations) > Open [>>] button
• Edit file type (Internal Associations) > Change icon button > Icon file: [>>] button

It 's high time to fix it.

[Dalai]

I certainly don't want absolute paths replaced by environment variables for two reasons:

1. They might contain a different path on different systems, which doesn't help for a portable TC and might even cause TC to operate on completely different files - and that's potentially dangerous,
2. Multiple environment variables might contain the path one might want to use, so which one should be used by TC?

Furthermore, some commands you mention don't contain paths at all, like cm_LoadSelectionFromFile and cm_SaveSelectionToFile, MRT's Load names from file and a couple more, so they don't need environment variables.

There's one exception, which has been annoying for years, and that's when installing a new plugin. TC really should replace the plugin path with %COMMANDER_%PATH%\Plugins (or whatever is defined by [Configuration] pluginbasedir setting in wincmd.ini) when the plugin is installed in that directory.

Regards
Dalai

[Fla$her]

2Dalai
1-2. Please provide examples.
cm_LoadSelectionFromFile/cm_SaveSelectionToFile/MRT deleted. Hastened slightly. Was afraid to miss something.
The rest is relevant.

[petermad]

2Dalai

There's one exception, which has been annoying for years, and that's when installing a new plugin. TC really should replace the plugin path with %COMMANDER_%PATH%\Plugins (or whatever is defined by [Configuration] pluginbasedir setting in wincmd.ini) when the plugin is installed in that directory.

Just change the pluginbasedir setting in wincmd.ini to:

Code: Select all

pluginbasedir=%COMMANDER_%PATH%\Plugins

Or have I misunderstood what you want ?

[Fla$her]

Or have I misunderstood what you want ?

Did you read first sentence about manual editing of the source request?

[Dalai]

1-2. Please provide examples.

Examples of what? That the contents of environment variables can be different on different systems? Really? Environment variables can be set by the user, programs, scripts and so on, even on the fly depending on the situation and program used. As a result, TC would operate on completely different files on different systems. And it isn't hard to imagine that multiple environment variables on the same system might have the same contents, or similar contents like a=C:\blub and b=C:\blub\blah.

So, I don't see what's unclear about these two points that could be made clearer with examples.

Just change the pluginbasedir setting in wincmd.ini to:

OK, that seems to work indeed, thanks. Need to do more tests to verify it. However, I have seen pluginbasedir been changed sometimes, not sure why or what caused it.

Regards
Dalai

[Fla$her]

Environment variables can be set by the user, programs, scripts and so on, even on the fly depending on the situation and program used. As a result, TC would operate on completely different files on different systems.

I understand, but this also applies to COMMANDER_PATH, which is automatically inserted when dragging an object from TC directory to the toolbar. Therefore, there is nothing wrong with %COMMANDER_PATH%, %COMMANDER_EXE%, %PROGRAMFILES%, %USERPROFILE%, %Temp%, %WinDir%, %$APPDATA%, %LOCALAPPDATA% being substituted automatically. If a person changes these variables himself, then he should be perfectly aware of the consequences. This applies to any settings at all. "Danger" here is only in rash actions.
But if you dig deeper, you can pay attention to pseudo-variables, which the user will not be able to change.

[Dalai]

If a person changes these variables himself, then he should be perfectly aware of the consequences.

No, certainly not in all cases. Imagine a user changes environment variables for one Windows profile only, but not in another, but these changes were made years ago. Do you honestly believe that that user is aware of the consequences of the changes made years ago, in that particular situation, perhaps when being under stress? Come on.

And, BTW, %ProgramFiles% is a really bad example for automatic substitution because its contents depend on the bitness of your system and the program used! Its contents are "C:\Program Files" for x64 programs but "C:\Program Files (x86)" for x86 programs on the same x64 system, but "C:\Program Files" on x86 Windows systems. TC x86 would work on completely different files than TC x64.

Just to make it clear: An optional automatic substitution (off by default) would be OK for me, but the users must be made aware of the consequences when enabling such a thing.

But if you dig deeper, you can pay attention to pseudo-variables, which the user will not be able to change.

Of course these can be changed, too! Just use the properties in Windows to move My Documents, Downloads, My Music and similar folders to a new location and TC will pick them up automatically. Do that only on one system, and TC operates on completely different files on the involved systems.

Regards
Dalai

[Fla$her]

By changing the location of these folders in this way, the essence of addressing the right elements is not lost. This cannot be compared to manual lye variable through plugins.

Your concerns are understandable, but for me they are not so significant. In this case, it was necessary to write initially about the optionality of such an auto-replacement. The main thing is to add the opportunity itself.

[petermad]

Or have I misunderstood what you want ?

Did you read first sentence about manual editing of the source request?

The question was to Dalai, and from the later posting from him, i see that I haven't misunderstood him.

As for the first sentence. I read the double negation in the sentence as if you want environment variables inserted automatically as much as possible.

Doing what I suggest, is a solution where %COMMANDER_PATH% is automatically used for plugin installation.

[Fla$her]

Bump for v.10
At least with %COMMANDER_PATH%. Mayby with %USERPROFILE%, %Temp%, %WinDir%, %APPDATA%, %LOCALAPPDATA%.

[Fla$her]

Bump for v.10.50

[ghisler(Author)]

I have considered this, but it's not clear where the variables should be used, and which should be used.
For example, there are internal variables like %COMMANDER_PATH% or %COMMANDER_DRIVE% which could both be used (but only separately, not together), because one is a part of the oher. The same is true for system variables like %APPDATA% and %USERPROFILE%.

[Fla$her]

it's not clear where the variables should be used, and which should be used.

What do you mean by "where"? Dialogues and elements are listed in the first post. It was about configuration files.

%COMMANDER_PATH%, %COMMANDER_EXE%, %PROGRAMFILES%, %USERPROFILE%, %Temp%, %WinDir%, %$APPDATA%, %LOCALAPPDATA%

For example, there are internal variables like %COMMANDER_PATH% or %COMMANDER_DRIVE% which could both be used (but only separately, not together), because one is a part of the oher. The same is true for system variables like %APPDATA% and %USERPROFILE%.

Of course, in order of priority from more to less:
a) 1. %COMMANDER_EXE%; 2. %COMMANDER_PATH%; 3. %COMMANDER_DRIVE%
b) 1. %TEMP%; 2. %LOCALAPPDATA%; 3. %USERPROFILE%; 4. %COMMANDER_DRIVE%
c) 1. %APPDATA%; 2. %USERPROFILE%; 3. %COMMANDER_DRIVE%
d) 1. %PROGRAMFILES(x86)%; 2. %PROGRAMFILES%; 3. %COMMANDER_DRIVE%
e) 1. %WINDIR%; 2. %COMMANDER_DRIVE%
%COMMANDER_DRIVE% can be inserted only after checking all the others.

Example of .vbs with an approximate implementation:

Code: Select all

With CreateObject("Scripting.FileSystemObject")
   TF = .GetSpecialFolder(2) & "\" & .GetTempName: .CreateTextFile(TF).Write _
   "<script language=jscript>with(self){resizeTo(0,0);moveTo((screen.width-781)/2,(screen.height-657)/2)};"&_
   "window.onload=function(){f = d.object.openFileDlg('','', 'All files (*.*)|*.*|', 'Select file');" &_
   "if(f!=''){new ActiveXObject('Scripting.FileSystemObject').createTextFile('" & Replace(TF, "\", "\\") &_
   "',1,1).write(f)};close()}</script><object id=d classid=clsid:3050f4e1-98b5" &_
   "-11cf-bb82-00aa00bdce0b width=0 height=0 /><hta:Application Caption=no />"
   CreateObject("WScript.Shell").Run "mshta.exe """ & TF & """",, 1
   If .GetFile(TF).Size = 473 Then q = 1 Else File = .OpenTextFile(TF,,,-1).ReadAll
   .DeleteFile TF, 1: If q = 1 Then WSH.Quit
End With

With CreateObject("WScript.Shell").Environment("Process")
   For Each EnVar in Split("COMMANDER_EXE COMMANDER_INI COMMANDER_PATH " &_
   "COMMONPROGRAMW6432 COMMONPROGRAMFILES(x86) COMMONPROGRAMFILES PUBLIC " &_
   "PROGRAMFILES(x86) PROGRAMW6432 PROGRAMFILES WINDIR TMP TEMP LOCALAPPDATA " &_
   "APPDATA USERPROFILE ALLUSERSPROFILE COMMANDER_DRIVE SYSTEMDRIVE HOMEDRIVE")
      i = .Item(EnVar)
      If i <> "" Then
         If InStr(1, File, i, 1) = 1 Then
            File = Replace(File, i, "%" & EnVar & "%", 1)
            Exit For
         End If
      End If
   Next
End With

MsgBox File, 4160

[Fla$her]

I have considered this

And what did you decide?