Long Filename \ Path Via Button Drop?

[Pumpkin]

When ever I drop a file on to an icon on the button bar it passes the short DOS file path to the application (python script.) Is it possible to get TotalCmd to pass the long path? I've tried various things %L %1 etc.. but nothing works.

As the script requires the long name it's causing issues.

If you have Python to see what I mean try:

Create this Python file and add it as a button then drop any file on it.

Code: Select all

# test,py

import sys
print(sys.argv[1])
input()

[Dalai]

The parameter(s) in a button is/are completely irrelevant when something is dropped onto it; the dropped object (file, directory) replaces the whole parameter field.

Passing short filenames happens for me only if short filenames are shown in TC, e.g. by calling cm_SwitchLongNames command, and dropping a file in such a path onto a button after that. The path I used is

Code: Select all

C:\Program Files (x86)\Total Commander\history.txt

which becomes

Code: Select all

C:\program~2\totalc~1\history.txt

when 8.3 names are shown.

[Pumpkin]

Long filenames are enabled.

As far as I can see it is an issue with TotalCmd passing the short path to the button or the button to the program? The same as it does when you drop a file on to the (textbox) input bar at the bottom right of TotalCmd. (Command box or something. Don't know what it is called.)

Edit: Here is an example of short path \ filename after I dropped a file into the bottom input:

Image: http://www.firststep.clara.net/temp/noname_no-00.png

[ghisler(Author)]

It passes the long name to the button, but the short name to the command line when you use drag&drop.
Use Ctrl+Enter to pass the long name to the command line.

[Dalai]

2Pumpkin
As I said, TC properly passes long names to a button, even when you drop objects on it. The TC command line is a different topic.

[Pumpkin]

Thanks guys for responses.

There is something weird going on though. It is happening when TC sends the command to the script \ app.

If I make a shortcut on the desktop and drop a file onto it the script gets the full long name. The same happens if I add the script to any other program I have.

It is only in TC and I am wondering if it is something to do with the method or call TC uses to pass the filename over. (Whether it uses a specific windows method.)

Sorry if I can't describe the issue better.

Anyway, just in case anyone else comes over the same issue, I have solved it for now by wrapping the script command in a batch (.bat) file like this:

Code: Select all

:: test.bat
@echo off

my_python_script.py %1

I then add the batch as the button command. The batch receives the long file name and passes it correctly to the python script.

Thanks again

[Horst.Epp]

Did you try to use the Python.exe as command,
with the name of your script file as parameter ?

[Pumpkin]

One of the first things I tried was to use python.exe + "script" in the command line. Same issue

However as Dalai said above. The parameter line is not processed in a button drop event so no use here sadly.

[white]

It passes the long name to the button..

26.01.07 Added: Button bar: When dropping a file to a program on the button bar, pass the long name instead of the short DOS name to the program (in double quotes "" if needed) if the program isn't an old 16-bit program. If this causes problems, put %p%n in the parameters field of the button

It says it only passes the long name if the program isn't a 16-bit program. It seems to default to short names for .exe files and to only use long names when TC can determine that the program is not a 16-bit program.

For example when you use this button, short names are used:

Code: Select all

TOTALCMD#BAR#DATA
cmd.exe /k echo

cmd.exe


0
-1

But if you use this button which uses full path to the program, long filenames are used:

Code: Select all

TOTALCMD#BAR#DATA
C:\WINDOWS\system32\cmd.exe /k echo

cmd.exe


0
-1

[Pumpkin]

@white

I think you have hit the problem right on target.

If I pass the whole path of ..../python/python.exe + script_name.py in the command box then it works exactly as you said. It passes the long path perfectly to the script.

Obviously it can't guess what bit version a script by itself is. However this issue does not exist for passing to .bat script files even without calling CMD first - which still seems odd.

If I add "python.exe" on it's own I suspect TC is guessing the wrong bit version of my 64bit Python unless a full path is set.

Maybe it's an XP legacy thing.

Anyway that is useful information white'. Thanks you.

I can now mark this issue: SOLVED! Thanks to you White'

[Dalai]

Ah, now it makes sense. I only tested with full executable paths in the button.

IMO it would be better for the 16-bit compatibility thing to work the other way around: use only short names if the executable is detected as 16-bit, and use long names in all other cases. Long names have existed for decades and MS is moving towards disabling short names by default.

[EDIT] Typo [/EDIT]

[white]

IMO it would be better for the 16-but compatibility thing to work the other way around: use only short names if the executable is detected as 16-bit, and use long names in all other cases. Long names have existed for decades and MS is moving towards disabling short names by default.

Since the intention is to support 16-bit programs, it makes no sense for 64-bit TC and for 32-bit TC running on 64-bit Windows. So the code can be removed from 64-bit TC, and 32-bit TC can be modified so that it does not attempt to support 16-bit programs when running on 64-bit Windows. That way you keep maximum compatibility, while also phasing out this feature.

[white]

07.01.25 Fixed: On 64-bit Windows, always assume that called programs can handle long file names (don't check whether the target program is 16-bit), e.g. when dropping a file to a button (32/64)

Tested OK using TC 32-bit and 64-bit on my 64-bit system and confirmed unchanged behavior when using TC 32-bit on a virtual machine with 32-bit Windows.

[Pumpkin]

07.01.25 Fixed: On 64-bit Windows

Thank you developers

[MVV]

I've noticed similar problem with TC 11.03 and a buttonbar button for a LNK file for a batch file under 64-bit Windows 10 where 16-bit apps can't be started at all.

Since the intention is to support 16-bit programs, it makes no sense for 64-bit TC and for 32-bit TC running on 64-bit Windows. So the code can be removed from 64-bit TC, and 32-bit TC can be modified so that it does not attempt to support 16-bit programs when running on 64-bit Windows. That way you keep maximum compatibility, while also phasing out this feature.

I agree that a modern TC should pass a short path only under 32-bit Windows and only when 16-bit program is detected, in any other case it should pass a long path. Or maybe an INI option may be added with e.g. 0 (always short), -1 (auto) and 1 (always long) choices. But I would like to disable all long-to-short translations in TC and always use only long paths everywhere, so maybe such an option may be for multiple actions that still convert long paths to short ones.