cm_mand plugin

[Hurdet]

You are right. It can to work.
Honestly, I’m not convinced by using hooks and payloads hidden inside a plugin. For something like this, I’d prefer a native solution that:
- Doesn’t rely on hooks or obscure payload mechanisms.
- Integrates cleanly with Total Commander’s own model.
- Properly supports a list of selected files, not just a single file.
If Total Commander already has a complex plugin system with all this machinery, I don’t think adding support for this kind of native, file‑list‑aware DLL call would be hard. It would be a small, natural extension of what’s already there.

[Fla$her]

What do you mean by a hook in this case?

Your preferences are clear, but quite specific. I wouldn't even hope for something similar to appear in TC, considering that much simpler and more understandable things for ordinary users haven't appeared in so many years. Therefore, you are left either to use the available tools (rundll32, winapiexec, Autorun) or wait indefinitely, never getting the desired benefit.
Your request doesn't fit into the original logic of the 4 types of plugins, no matter how you look at it. Neither commands nor buttons in any part have any connection with them.

- Properly supports a list of selected files, not just a single file.

What's the use of a flat list for a library if each list item still has to be processed separately in a loop iteration?

[Hurdet]

or wait indefinitely, never getting the desired benefit

Therefore, this is a suggestion post .
Otherwise, this being the case, I prefer to continue using the old features.

[Fla$her]

Therefore, this is a suggestion post .

Strange conclusion. In the quote, I'm precisely evaluating the prospects of your suggestion.

Otherwise, this being the case, I prefer to continue using the old features.

The choice is yours, even if it's not rational.

[Hurdet]

passed

[Hurdet]

Maybe it's better this way? —>

Code: Select all

LoadLibrary Plugins\Autorun_Runtime.dll
#——————————————————————————————————————

RegisterCommand 77777 MyFunc

Func MyFunc()
   DllCall('MyLib.dll', 'MyFunction', GetCurrentPath(3, 2))
EndFunc

I not see GetCurrentPath in Autorun_Runtime.dll.
But this work: RequestCopyDataInfo("SP").

[Fla$her]

I not see GetCurrentPath in Autorun_Runtime.dll.

GetCurrentPath works without additional modules. Why are you looking in the dll when everything is in the help (help_en.chm)?
On the second tab, type the desired name and the help will focus on the desired function.

But this work: RequestCopyDataInfo("SP").

It should be completely like this: RequestCopyDataInfo('SP') & RequestCopyDataInfo('SN')

[Hurdet]

GetCurrentPath works without additional modules.

GetCurrentPath need Runtime plugin as RequestCopyDataInfo. (Function name not found: GetCurrentPath)
RequestCopyDataInfo("SP") = GetCurrentPath()
RequestCopyDataInfo("SN") = GetCurrentItem()
Why duplicate?

[Fla$her]

GetCurrentPath need Runtime plugin

You're right, I just forgot.

RequestCopyDataInfo("SP") = GetCurrentPath()
RequestCopyDataInfo("SN") = GetCurrentItem()
Why duplicate?

When using parameters, GetCurrentPath(3, 2) is shorter.
%P%N = GetCurrentPath(3, 2) = RequestCopyDataInfo('SP') & RequestCopyDataInfo('SN')
Also GetCurrentItem can be used in TC versions up to 8.0b10.

But GetCurrentPath() has a problem - it doesn't work from search results, so until the fix one will have to use the RequestCopyDataInfo option.