Total Commander

I want to convert many em_command which are just command with parameter I call from powerpro using wm_copydata mechanisn with 0x4D45.
I want to use CD, SELECTFILES, LOADSEARCH, LOADLIST, SAVESELECTION ... In the history i've seen:
19.06.16 Added: Use WM_COPYDATA to also send cm_commands with parameters to TC, with command used to send em_commands (32/64)

I''m not able to call such command with a filename/pattern as parameter, anyhow if i use an em command with %A as parameter, it is working.

It is also not working from tc command_line. Why not detecting all command with parameter listed by TC as TC command and still searching for a file to execute.

Do you have a working sample for CD |*\ CD *.* SELECTFILES *.bak OPENSEARCH ==Images do you have a flag in Total commander to log what is received and rejection reason if the command is not executed !

@ghisler(Author) can you explain why the command with parameter cannot be called correctly from TC command line or wm_copydata.
If i define alias (same name calling em_command with %A) i can do it but why do i need those 2 extra step.

I do support for some colleague each time i need to go with user command step even to call standard commands. I also provide powerpro or other kind of script but it never work out of the box. I need to check for em_command or explain that calling TC from script do not works for all command even from TC internal command line..

We also have in totalcmd.inc (command browser as UI) a section called command with parameter but the one listed do not work on command line nor on wm_copydata except CD. Some "normal" cm_ command have hidden parameter and works on command line and wm_copydata but the only way to know it is to study history and the forum. This makes the learning curve painful and somehow frustrating.

Specifying cm_ commands in the header is unwarranted.
Parameterized commands without CM_ work from the command line. There were enough tests and fixes on the forum.

For WM_COPYDATA, this topic has existed for a long time and there is no point in placing it in the bugs section.

nsp wrote: 2025-04-12, 07:04 UTC We also have in totalcmd.inc (command browser as UI) a section called command with parameter but the one listed do not work on command line nor on wm_copydata except CD.

Did you use capital letters for these commands?

nsp wrote: 2025-04-12, 07:04 UTC Some "normal" cm_ command have hidden parameter and works on command line and wm_copydata but the only way to know it is to study history and the forum. This makes the learning curve painful and somehow frustrating.

Or press F1 when you have the command browser on your screen.
Or look at this wiki page: https://www.ghisler.ch/wiki/index.php?title=List_of_internal_commands

white wrote: 2025-04-12, 12:33 UTC Did you use capital letters for these commands?

Other than the CD/cd discrepancies, I don't remember any string case problems in the command line.

Fla$her wrote: 2025-04-12, 13:22 UTC Other than the CD/cd discrepancies, I don't remember any string case problems in the command line.

Help page "Command line":

The command line also handles internal commands starting with cm_ and em_, and commands with parameters like OPENTABS. The latter must be written in capital letters.

I understood why it worked. In the drop-down list there were duplicate commands in uppercase, and TC selects them if you write in lowercase. Strange, of course.

On the command line, if i use SaveTabs, LoadList, SelectFiles .. (it is more natural for me to write this way) instead of the full name in UPPERCASE or lowercase command is not found. It works anyhow for some of them like "LoadSearch" but not for all.

On wm_copydata message, all commands not starting with cm_ or em_ does not work at all.
If you have powerpro and total commander 64bit, just try this in a script or a note: You can do the same in autohotkey or C or pascal or whatever. 0x4D45 is the dword signal for em_cmd.
This is the meaning of this bug report.

Currently only cm_ and em_ commands are supported via WM_COPYDATA. This isn't a bug, it's a limitation. I'm therefore moving this thread to the suggestions forum.

Moderator message from: ghisler(Author) » 2025-04-13, 08:51 UTC

nsp wrote: 2025-04-13, 05:35 UTC This is the meaning of this bug report.

As I immediately made it clear, this is not a bug, but a limitation. It's enough just to join the support in an existing MVV topic.

[/quote]

ghisler(Author) wrote: 2025-04-13, 08:52 UTC Currently only cm_ and em_ commands are supported via WM_COPYDATA. This isn't a bug, it's a limitation. I'm therefore moving this thread to the suggestions forum.

Even if you call it a limitation, it is for me a coherency discrepancy.It has been asked by MVV 6 years ago without any response.
It is just a parsing issue for the first term of the passed data and almost same thing to do that what is dome from the command_line.

@ghisler(Author) When do you plan to fix it ?

2025 year, we still can't send powerful commands X_X

Why not just put it in an em_command and then call that?

ghisler(Author) wrote: 2025-04-22, 10:13 UTCWhy not just put it in an em_command and then call that?

I'm sharing my scripts and each time i need to also explain and share usercmd.ini stuff amd em_CMDXXX for each and every command needing parameter.
It would be great to have it work out the box without asking to edit usercmd.ini. It is just mapping one command with same name and same parameter %A all the time. All the other command works even the cm_cmd with parameter but not some of the most usefull to manipulate TABS, SELECTION, LIST, Some of them have modifier and need many variant like SELECTFILES which is a bit too much.

ghisler(Author) wrote: 2025-04-22, 10:13 UTC Why not just put it in an em_command and then call that?

As MVV wrote,

MVV wrote: 2019-11-05, 07:53 UTCIt isn't portable and useful to create a wrapper command per every command with parameters.

The reasons, in my opinion, are obvious:

1. Overwriting ini in the code itself slows down the speed of its operation, and the entry itself with checking for its presence (for example, in a button with TCFS2) becomes much longer. Moreover, usercmd.ini may already have similar commands, which is fraught with their overwriting or duplication of functionality, which is unsafe when publishing code.
2. If one overwrite ini manually, then, as has already been made clear, this leads to the need to constantly warn users about additional actions that are not always interpreted correctly by beginners, as a result of which errors are possible.