Multible list parameters (%L %F %UL etc) not supported

[petermad]

While testing the new %Y parameter I discovered this, which unrelated to the %Y parameter and is not new to TC 9.20). It might not be a bug but it is certainly an unexpected and non-transparant behaviour:

If I use more than one list parameter (%L, %l, %F, %f, %D, %d, %WL, %WF, %UL or %UF) in a button, only one list file is created in the %TEMP% dir.

And the resulting file is influenced by all parameters. For example:

%L %F results in a list file like if I used %F
%f %F results in a list file like if I used %f
%F %UL results in a file like if I used %UF
%UL %WL results in a file like if I used %WL
%WL %UF or %WL %F results in a file like if I used %WF
%WL %f results in a Unicode file with content like if I had use %f alone.
The order of the parameters seems to be of no importance.

So there seem to be some kind of scheme where lowercase precedes Upperscase parameters and %F/f precedes other parameters. %W precedes %U - Not very easy to keep track of especially if usin more than just two list parameters.

I could need to use more than one list parameter in the parameters field when cripting with %COMSPEC% in the command field - so I think it would be better if TC created separate .tmp files for each list parameter used in the parameters field.

[MVV]

I agree that it is a quite strange behaviour, and that it would be much better to have multiple temporary files, one per file list kind.

[ghisler(Author)]

This is documented in the help:

%L, %l, %F, %f, %D, %d, %WL, %WF, %UL, %UF create a list file in the TEMP directory with the names of the selected files and directories, and appends the name of the list file to the command line. The list is deleted automatically when the called program quits. Only one list per command is supported.

[petermad]

2ghisler(Author)
Ah, I overlooked that - sorry. Would it be troublesome to add support for multiple lists?

Moderator - could this be moved to Suggestions?

[ghisler(Author)]

It would add a lot of complexity, and wouldn't be useful for most users. Why pass the same file list multiple times to a called program, and in various formats?

[MVV]

I can see e.g. following usage: some script reads full paths from one list and just names from another in order to do some actions and/or copy files to some dir.

It shouldn't be too hard to do, you should already have some struct/class that holds all command-specific data including string with path to temp list file, you need only to change string to string array with fixed length and add an enumeration describing which item of that array corresponds to which list format. Removing temp files won't be hard - just iterate over non-empty strings in array and delete files.

Code: Select all

enum ListFormats {
	ListLongPaths = 0,
	ListShortPaths,
	ListLongNames,
	ListShortNames,
	ListDosPaths,
	ListDosNames,
	ListLongUtf8Paths,
	...,
	ListFormatCount // will contain number of formats
};

struct CommandRuntimeInfo {
	...
	string[ListFormatCount] listFilePaths;
	...
};

// Same in Pascal:
// type TListFormatType = (ListLongPaths, ListShortPaths, ...);
// listFilePaths: array [0 .. Ord(High(TListFormatType))] of string;


typedef bool (* FormatFunctionPointer)(const string& path, ...);

struct FormatterInfo {
	int formatIndex;
	FormatFunctionPointer formatter;
};

static std::map<char, FormatterInfo> formatters;
formatters['L'].formatIndex = ListLongPaths;
formatters['L'].formatter = &writeLongPathsToFile;
formatters['F'].formatIndex = ListLongNames;
formatters['F'].formatter = &writeLongNamesToFile;

for (all char paramChar in cmdline) {
	if (formatters.count(paramChar)) {
		FormatterInfo& fi = formatters[paramChar];
		string filePath = getTempFilePath();
		fi.formatter(filePath, ...);
		cri.listFilePaths[fi.formatIndex] = filePath;
	}
	else {
		// it is not a list parameter
	}
}

In your current implementation it would be safer to pass empty paths for subsequent list file parameters instead of passing path to file with another list format (I can't see any usage in path to file with unexpected contents).

[petermad]

In your current implementation it would be safer to pass empty paths for subsequent list file parameters instead of passing path to file with another list format

I agree on that - if not support for more than one list, only the first list parameter should be recognized.