Total Commander

Thanks for a great product.
Here are some observations... sorry if there are duplicates or things I just haven't been able to detect.

* Put the Split/Combile Files, Encode/Decode, CRC stuff, each in their own submenus.

* Same goes for Pack/Unpack/Test archive. Let them have their own submenu and update the menuitem enabled state appropriately.

* Create a new submenu for shell commands (Copy, Paste, Cut, Delete (shell style)).

* Probably know about this, but Vista claims: Error: Cannot write WINCMD.INI! Please remove the write protection!
Most likely because TC is not LUA compliant.

* Shell Extension support seems slightly broken in this version. It appears to require the NSE to support IShellFolder2 now.

* Shell Extension support should use IShellFolder::GetUIObjectOf to get the IDataObject clipboard item as 1st priority. Then go through the IContextMenu route.

* Beefed up User Interface should be due. Version 7... and it still looks too much good old DOS days. Here are some points...

x Drive Icons in the Drive dropdown list
x Gradiants in the blue path-pane
x Put a nice right-ligned faded large bulky image of the drive in the background of the Volumn Title panel+edit box (
x Better use of mixed font styles (Eg. Drive/Volume panel in top: Name in Bold style, size in normal font, use Mb/Gb calculations for sizes).
x Too many knobs and dials in some of the Configuration pages. Add more pages in the tree, split existing pages to have fewer options, nicely separated with icons/short descriptions.

* Copy in Background/ is a nice feature. Support for ZIP files would be nice. Also stable/arrange the popup Windows in nicer rows (try to start 20 background jobs). Recycle empty Window spots when a job finishes and a new starts. On Windows Vista the Progress dialogs overlap since the Window borde-size is somewhat larger.

* Drive dropdown list could include "Desktop" virtual folder, just as it has Network Neighborhood.

* Option to always remember last Search from "Search..." menuitem.

* Multirename in sub-folders.

* Option to make the Spliiter-bar position be remembered/dependant of view-type (Brief, Full Details, Tree). I'd like to browse in Brief mode only occasionally, but with one large left-pane and a very small right-pane. When I flip back to Full Details-mode, I want both the panes 50%. So I want the Splitter bar to move as I change view-type.


regards
bjarke

2bviksoe

[mod]
• Good evening,

• Please, respect the forum rules, post one message per topic !
- Such a saga doesn't help to improve the features
and risks to be skipped by a lot of readers…

Best regards,
Clo, Moderator[/mod]

2bviksoe
Almost every item on your list is even already implemented or discussed multiple times on this forum.

You may use the forum search to get the answers ...

2bviksoe

Again…

• Indeed sqa_wizard is right 1,000 times: the Search - despite it isn't a wonder -
could give you a mountain of threads to read…

• But because I'm a peaceful man, I will answer to the start of your (rather useless) saga

• You may use the standalone English LNG¦MNU files, available from the TC Web pages.

- You can customize the menus at will, this is documented in the Help and with more details in our Tutorial,
please see in my signature below.
- We have a chapter there about the TC internal commands you may use in menus, buttons etc.
and one also about the special em_xxx user's commands by Paul Vansumsen-friend.
- In TC 7.0, we have too a nice commands window, that many other soft might adopt, and images to show this…

That's all for now, please come back after reading, you'll be welcome, anyway.

 Kind regards,
Claude
Clo
NOTE : The English Tutorial is available ONLINE too

2bviksoe

* Put the Split/Combile Files, Encode/Decode, CRC stuff, each in their own submenus.
* Same goes for Pack/Unpack/Test archive. Let them have their own submenu and update the menuitem enabled state appropriately.
* Create a new submenu for shell commands (Copy, Paste, Cut, Delete (shell style)).

You might like this then: http://www.totalcmd.net/plugring/TcMenu_en_7.html

x Gradiants in the blue path-pane
x Put a nice right-ligned faded large bulky image of the drive in the background of the Volumn Title panel+edit box

Please - TC is a file manager - not a funky media player

use Mb/Gb calculations for sizes

"Configuration" -> "Tabstops" -> "In footer:" -> "dynamic (x.x k/M/G)".

Add more pages in the tree, split existing pages to have fewer options,

Support+

Drive dropdown list could include "Desktop" virtual folder

Support.
Workaround: use "Configuration" -> "Display" -> "Show parent dir also in root of drive", or use cm_OpenDrives in menu or button bar.

* Option to always remember last Search from "Search..." menuitem.

Support.

* Probably know about this, but Vista claims: Error: Cannot write WINCMD.INI! Please remove the write protection!
Most likely because TC is not LUA compliant.

You probably updated Windows from XP. Please reinstall Total Commander and choose an ini location where you have write rights, or use the tool inireloc from our addons page to change the location.

* Shell Extension support seems slightly broken in this version. It appears to require the NSE to support IShellFolder2 now.

* Shell Extension support should use IShellFolder::GetUIObjectOf to get the IDataObject clipboard item as 1st priority. Then go through the IContextMenu route.

I don't understand these remarks. What is NSE? TC already creates the context menu via IShellFolder and IContextMenu.

I will try to ignore some of the rude remarks above. If you expect feedback from casual users you don't flame them but just note their wishes in whatever form they come.

Clo gives me a (rather useless) list of customization internals that I do not wish to learn. Petermad presents what looks like a nice extension - with a horrible forest of menuitems. I wish the best from this extension had been added to the main tool.

My observations are purely for an User Experience point of view. Things that annoy me when I do a new install. They are not bugs, but when TC doesn't easily present me the same functions or visual feedback as Explorer, well why wouldn't I prefer to use Explorer then? Asking for a more tidy user interface after a fresh install doesn't seem such bad thing to ask for.

Actually if Windows Media Player had file-manager support, I'd probably use that. At least it would be more fun.
Please stop judging user requests from a techie point-of-view. Popular software appeals to ordinary users. None of them will ever customize their own menus, or ever launch an internal TC action command.

* Probably know about this, but Vista claims: Error: Cannot write WINCMD.INI! Please remove the write protection!
Most likely because TC is not LUA compliant.

You probably updated Windows from XP. Please reinstall Total Commander and choose an ini location where you have write rights, or use the tool inireloc from our addons page to change the location.

No. It was a clean install (even if there was a previous installation, it gets moved first). The Wincmd.ini file seems to be from that time and has default rights.
My default Vista user does not have access to \windows where TC seems to place the .ini file. Window LUA really discourage using private files anywhere but the \Users-specific file areas.

* Shell Extension support seems slightly broken in this version. It appears to require the NSE to support IShellFolder2 now.

* Shell Extension support should use IShellFolder::GetUIObjectOf to get the IDataObject clipboard item as 1st priority. Then go through the IContextMenu route.

I don't understand these remarks. What is NSE? TC already creates the context menu via IShellFolder and IContextMenu.

Sorry for the lack of better explanation. I'm the developer of a Shell Namespace Extension (NSE) called GMail Drive. Christian, we discussed shell extension support privately some time ago. At that time I suggested using a fallback if IContextMenu fails. You can simulate copy/paste using IShellFolder::GetUIObjectOf with IID_IDataObject and IID_DropTarget only.

I also see erradic behaviour when a NSE does not support IShellFolder2. The timestamp are random dates and the sorting behaves strangely when refreshing. I see "First-chance exception in TOTALCMD.EXE: 0xC0000090: Float Invalid Operation." in the debug trace and TC crashes with the same error when I click a sort-column.

When IShellFolder2 is added, GetDetailsEx() must still support FMTID_ShellDetails/PID_FINDDATA. You should be able to fallback and extract the needed information from the columns [GetDetailsEx() FMTID_Storage/standard PIDs, with fallback to GetDetailsOf()] most of the time.

regards
bjarke

2bviksoe

... with a horrible forest of menuitems

Talking about rude remarks

You had your wishes for the menu - my extension actually had exactly what you asked for. Other people has other wishes, they might also find what the need.

Of course my menus are extensive - that's the inevitable nature of trying to cover almost all of the functions available in TC - and of course it can be done completely differently ( http://www.totalcmd.net/plugring/TCExtMenu.html - http://www.totalcmd.net/plugring/exp_eng.html ). I have tried to mostly extend the original menu system, rather that rewriting it.

Please stop judging user requests from a techie point-of-view

If the request is in danger of making MY favorite application unnecessarily bigger and slower - I must object - sorry.

petermad wrote:2bviksoe
... with a horrible forest of menuitems
Talking about rude remarks

You had your wishes for the menu - my extension actually had exactly what you asked for...

Sorry. Wasn't meant like that. I always try to step back and view usability of software from an "average dumb" user's perspective. Most likely, that is not your target audience. It is a really nice extension, and as I said, many of the features would do very well in the main tool.

bjarke

2bviksoe

Hi!

…Clo gives me a (rather useless) list of customization internals that I do not wish to learn. …

• I answered to that you ask for, say : Another layout of the items in the menus, and extra-items.
- Since you claim that you are able to program some stuff, you might not have to learn anything.
- The customization of the menus in TC is a nice potential which is getting rare…
- It's roughly the same thing as the syntax¦principle than the boot-menus I wrote ten years ago for DOS¦Win 3.1,
and I'm not a programmer…

Petermad wrote

…If the request is in danger of making MY favorite application unnecessarily bigger and slower - I must object - sorry.

• I agree, Peter. I don't wish that TC becomes a circus parade and¦or a cover-all where all exists, and all is dashed off…

 R
Claude
Clo

That's most worrying about good applications... they tend to turn to utter bloatware after some period of time.

I hope this won't happen to TC.

Sorry for the lack of better explanation. I'm the developer of a Shell Namespace Extension (NSE) called GMail Drive. Christian, we discussed shell extension support privately some time ago. At that time I suggested using a fallback if IContextMenu fails. You can simulate copy/paste using IShellFolder::GetUIObjectOf with IID_IDataObject and IID_DropTarget only.

Unfortunately this OLE2 programming is like a mine field. Therefore I prefer to stick to the standard IContextMenu handling - better it fails than it crashes. Faking a drag&drop operation is risky, who knows what interfaces and in what order are called by the Explorer during drag&drop...

I also see erradic behaviour when a NSE does not support IShellFolder2. The timestamp are random dates and the sorting behaves strangely when refreshing. I see "First-chance exception in TOTALCMD.EXE: 0xC0000090: Float Invalid Operation." in the debug trace and TC crashes with the same error when I click a sort-column.

I'm not calling these interfaces myself. All I do is call SHGetDataFromIDList with parameter SHGDFIL_FINDDATA. This is one simple function call - you should make sure that your plugin supports it, then there should be no problems with other file managers either.

Sorry for the lack of better explanation. I'm the developer of a Shell Namespace Extension (NSE) called GMail Drive. Christian, we discussed shell extension support privately some time ago. At that time I suggested using a fallback if IContextMenu fails. You can simulate copy/paste using IShellFolder::GetUIObjectOf with IID_IDataObject and IID_DropTarget only.

Unfortunately this OLE2 programming is like a mine field. Therefore I prefer to stick to the standard IContextMenu handling - better it fails than it crashes. Faking a drag&drop operation is risky, who knows what interfaces and in what order are called by the Explorer during drag&drop...

As I suggested you would use it as a fallback if the other part fail. One can simply not expect all NSE to support these interfaces properly.
The Shell script does this internally (IContextMenu first, then IDataObject direct) in the following VB script:
MYCOMPUTER = &H11
Set sa = CreateObject("Shell.Application")
Set myComputer = sa.NameSpace(MYCOMPUTER)
Set myNSE = sa.NameSpace(myComputer.Items(1).Path)
myNSE.CopyHere "C:\Temp\Test.txt", 0

I also see erradic behaviour when a NSE does not support IShellFolder2. The timestamp are random dates and the sorting behaves strangely when refreshing. I see "First-chance exception in TOTALCMD.EXE: 0xC0000090: Float Invalid Operation." in the debug trace and TC crashes with the same error when I click a sort-column.

I'm not calling these interfaces myself. All I do is call SHGetDataFromIDList with parameter SHGDFIL_FINDDATA. This is one simple function call - you should make sure that your plugin supports it, then there should be no problems with other file managers either.

I suspect that the crash is not from SHGetDataFromIDList itself but from the fact that the sorting/display code assumes that it does not fail.

Since SHGDFIL_FINDDATA was only documented recently you will find many custom NSE that does not support it. In fact, on Vista it doesn't seem to do much any more, so most likely new NSE will not support it either.

The Explorer does this kind of fallback in many places. Obviously even Microsoft knows they have to support old stuff, when they didn't bother to document things in the first place.

bjarke

The Explorer does this kind of fallback in many places.

The Explorer doesn't seem to use IShellFolder for the file details. Instead, it asks the addon for an IShellView object, which then does all the painting by itself. Unfortunately I cannot use this method in Total Commander. So what do you suggest as a fallback?

ghisler(Author) wrote:

The Explorer does this kind of fallback in many places.

The Explorer doesn't seem to use IShellFolder for the file details. Instead, it asks the addon for an IShellView object, which then does all the painting by itself. Unfortunately I cannot use this method in Total Commander. So what do you suggest as a fallback?

Right, a truely custom NSE will implement its own IShellView. To expose its more intricate file details it must implement IShellFolder2. If it does not you can only display its name. However, most NSE (including those written with Microsoft's default implementation of IShellView, DEFVIEW) will expose IShellFolder2. However FMTID_ShellDetails / PID_FINDDATA has never been published as required. Older NSE (WinME, I think) exposed IShellDetails only. Later this was merged into IShellFolder2.

If you look at the documentation for IShellFolder::GetDetailsOf you can see how Microsoft suggests on using specific columns:
http://msdn2.microsoft.com/en-us/library/ms632951.aspx

Actually you would use IShellFolder2::MapColumnToSCID with FMTID_Storage & PID_STG_NAME, PID_STG_SIZE etc to see which columns the NSE supports.

The final order I guess would be...

IShellFolder2::GetDetailsEx with FMTID_ShellDetails / PID_FINDDATA
IShellFolder2::GetDetailsEx with FMTID_Storage / PID_STG_SIZE...
IShellFolder2::GetDetailsOf with MapColumnToSCID() [localized result]
IShellFolder2::GetDetailsOf with raw index [unreliable]
IShellDetails::GetDetailsOf with raw index [unreliable]

To complicate this, Windows ME/2000 uses IShellFolder::CreateViewObject to get to the IShellDetails instead of just QueryInterface for it. The last two are pretty outdated by now.

Some applications that are really keen on knowing file details of a custom Shell Extension may even IShellFolder::GetUIObjectOf to get its IDataObject (clipboard item) and query for CFSTR_FILEDESCRIPTOR. This may come with a performance penalty, so it's often only used to show the file details/progress-bar when the actual copy/move operation is being done.

bjarke