Total Commander

May be this discussed before, but a lot of time ago.

I want to write fully correct temporary panel plugin. At first, I made that it moves file within same volume, open normal properties dialog, returns normal file icons etc.

But when I starting external application, TC passes invalid path to file. I think in case of temporary panel TC should pass real path to files (generate filelist with real filenames) because TP returns real path for its files (if path may not be resolved, TC should skip file).


Summary for the topic:

0.a get real filename/generate filelist with real filenames when passing file from temporary panel as parameter for external application (for %P%N); (7.55b1)
0.b same as 0.a (for %L etc);
1 if user drops files onto a folder in FS/TP panel, TC should append its name to a result path; (7.50a)
2 fill time field when user opening attributes dialog for file in FS/TP; (7.55b1)
3 make [tc.file type] working with files in FS/TP;
4 refresh both panels after file operation if both have same FS/TP plugin;
5 ask confirmation on read/hidden/system file or non-empty folder deleting within FS/TP; also hide hidden/system files on cm_SwitchHidSys;
6 copy/move folder to its subfolder detection for FS/TP;
7 beep if FsExecuteFile(, , "properties")==0 instead of displaying version dialog w/o any information in FS/TP;
8 count size of subfolders on Ctrl+L;
9 do not show "to: " label in delete dialog;
A correct handling of flag FILE_ATTRIBUTE_REPARSE_POINT for FS/TP objects (e.g. deleting);
B add function to put/delete folder with subfolders (if plugin can't perform operation, use usual method);
C allow to execute FS commands via buttonbar buttons (I mean passing command "quote ..." to FS plugin), if plugin folder is specified as working dir e.g. (this would be useful for creating plugin-specific user-commands, bar buttons etc);
D do not return 1 in ProcessProc every time after user press Cancel, return 1 only when user presses Escape/Cancel button again - this is necessary in order to allow user to continue operation on false cancel;
E when I use Shift+F4 inside virtual folder, I expect that TC will call RemoteNameToLocal and create new file according to returned path, but not that TC will create file in TOTALCMD.exe's current directory;
F add to FsDefaultParamStruct struct field RootName to inform plugin which root name is used in TC if not default; by FsDefaultParamStruct::size field plugin may determine if enchanced version of structure is used;
G disable drop-down hints when start cmdline param with \ or ..\ in FS plugin - TC suggests wrong items from its current real folder. But don't disable hints when user types full path from real drive like "F:\..." (in any path of command line);
H when user packs files from TP, TC should pass real filenames to packer instead of copying files to temp folder and passing its paths;
J make internal associations work inside temporary panel; (7.55b1)
K make P/N keys in Lister working with multiple selected files within FS/TP;
L make possible to pass as buttonbar button parameter not only real name but virtual name too (in 7.55 and later).
M branch view and partial one;
N 'feed to listbox' from search dialog.
O retrieve real name and use Ctrl+Left/Right for folders too.
P show normal context menus and overlay icons for files/folders that provide real path.

This issues was discovered after many months of work on temporary panel plugin.

Have you implemented FsLinksToLocalFiles and FsGetLocalName?

ghisler(Author) wrote:Have you implemented FsLinksToLocalFiles and FsGetLocalName?

Yes, of course. Only with help of this functions TC may know real filenames.
When I press F3, TC calls FsGetLocalName and shows real filename in Lister title. But TC don't call FsGetLocalName when I press button with %P%N in parameters, it just passes to program something like '\\\bla\bla.bla'.

Sorry, %P%N doesn't currently handle plugins. I will add it to my wish list.

ghisler(Author) wrote:Sorry, %P%N doesn't currently handle plugins. I will add it to my wish list.

Thanks, it would be great for temporary panel.

I want to write fully correct temporary panel plugin.

Sounds great.

Sorry, %P%N doesn't currently handle plugins. I will add it to my wish list.

Support++

MVV wrote:I want to write fully correct temporary panel plugin

Support++. Please, keep us informed about the development progress.

@MVV check out HFT and how it does Baskets,
Note the shopping cart icon for "recent baskets"
The OpenFolder icon for open a basket
And the Disk icon to save a current basket.

Then see how simple the actual .bsk files are (INI FILES!!):

[Basket]
FoldersCount=2

[Folder_1]
FolderPath=c:\
filesCount=5
file_1=AUTOEXEC.BAT
file_2=boot.ini
file_3=CONFIG.SYS
file_4=IO.SYS
file_5=MSDOS.SYS

[Folder_2]
FolderPath=C:\Program Files\Logitech\MouseWare\
filesCount=2
file_1=MOUSEDRV.TXT
file_2=Readme.txt

It also has a very intuitive right click option, "send to basket" when you have selected either a file or a folder.

Granted its Virtual Folders (Baskets) are pretty much the only thing this particular program does well, but they work almost exactly how I would think TC could do it. Ease of saving file lists, opening saved lists, and actually opening files that are contained within the basket.

It also allows you to rename files in the basket, and that will rename the real file (in its actual location).
The only thing it can't do that I think would be cool, is if CTRL+DEL could delete both from the basket, and the real file too. DEL just removes items from the basket.

Anyways, just thought you might find that implementation interesting. Good luck.

Thanks for example but we already have base as TC, so not all features may be realized in TP (especially in context menu), but I want it to keep links to files and folders, with possibility to browse that folders in it. Real folder browsing is possible via Ctrl+Enter + Enter, launching file and run command - as usually. I won't use INI format anyway, for large line ammounts it has much waste information like field names.

One of existing plugins has feature to delete real files but it asks for every file deletion and it is very annoying. I want to make it user-friendly. E.g. if user holds shift on first file deletion, plugin asks to remove real file, and subsequent delete requests won't ask confirmation. Unfortunately there is no way to determine end of delete operation because TC calls file find functions and delete functions for each file and empty folder separately. So, some convention should be used here (maybe user need to hold Shift during whole deletion operation, and plugin will warn if user releases Shift).

Well the primary reason(s) I don't have any use for the implementation of the VirtualFolder's I have seen for TC is that
(1) you can't open archives,
(2) if you move files - they don't move
(3) You can only have 1 Temporary Panel,
i.e. can't save it and just open another List.

The TempPanel (plugin) is just clunky compared to HFT's implementation of Baskets.

Balderstrom wrote:Well the primary reason(s) I don't have any use for the implementation of the VirtualFolder's I have seen for TC is that
(1) you can't open archives,
(2) if you move files - they don't move
(3) You can only have 1 Temporary Panel,
i.e. can't save it and just open another List.

The TempPanel (plugin) is just clunky compared to HFT's implementation of Baskets.

1. agreed, but it is not so big problem.
2. THEY MOVE !!! if plugin was written by the man with straight hands (e.g. my plugin will move, as I wrote in 1st post )
3. you may use any number of top-level folders in temporary panel for different baskets, and to load/save filelist (at least I want to realize this features).

Wow, I found way to determine end of delete operation for real files removing. I just needed FsStatusInfo callback function


Another issue with FS plugins. When I copy/move a file to plugin, TC appends to its name current plugin folder. But when I drop file onto a folder in plugin panel, TC doesn't append this folder name to a result path (dialog 'Upload as' always contains just filename).

If this a bug, maybe it should be fixed (maybe I should create corresponding topic), if it's a misfeature, I suggest to show always in 'Upload as' dialog full target path of file/folder instead of just filename. Also TC should determine if objects was dropped onto folder and not onto just plugin panel and suggest right path, as it does this when work with usual folders.

Also TC doesn't fill time fields in attributes dialog - is is intent or misfeature?

Another bug - I see that [tc.file type] works for my plugin. Why Search function ignores its values?

And new little issue with temporary panel.

When I add/delete files/folders within local drives, TC refreshes target panel. But when I add/delete files/folders in temporary panel, TC leaves target panel (or vice versa) with outdated contents. I think in this case TC should refresh both panels if one of them is temporary.

And why TC don't ask confirmation when deleting hidden or system file? Or when deleting non-empty folder?

Plugin can't detect if user tries to delete non-empty folder because TC calls delete command for each file and folder individually.

And it is sad that TC doesn't detect when user copies/moves folder to its subfolder within FS panel because plugin can't detect when TC does it.

Also unfortunately plugin can't detect when user adds folder into it because TC creates new folder and copies files. So I need to invent some way of adding real folders onto temporary panel.

Can somebody answer, why TC opens strange version info dialog for file system plugins if they may have no version meaning?
IMHO, TC should beep if FsExecuteFile(, , "properties")==0 instead of displaying version dialog w/o any information.

Also TC doesn't use FsGetLocalName in compare tool launched from sync dialog on dblclick.

Seems I'm the one here:)

Or I bother people too much with this things:)


I'd tested load/save filelist in virtual panel and saw two things:

* TC doesn't calculate folder size even if I press Ctrl+L (sad).

* TC while deleting files shows dialog "Delete" "from: " filename "to: ". I think "to:" shouldn't be showed for delete operation.