Total Commander

The present topic has been also covered over the TC beta forum without a conclusion yet but with TC 7.50 public beta released we can move on here now I guess.

Story goes as follows: When using the new TC installer feature to update directly, it will also install all other menu and language files if just a single custom menu is in use as in my case.

IMHO, this is incorrect. Having said that, a check mechanism can be harder than initially thought due to custom menu filenames. It's even hard to decide how TC should behave if a standard name has been customized but a TC update installation "needs" to update it.

This is a minor issue really and maybe so much thought is not worthy.

But then again someone might have a better idea that I cannot think of.

Actually this happens when the installer finds MORE than one language file.

ghisler(Author) wrote:Actually this happens when the installer finds MORE than one language file.

As I said over the beta forum as well, my <language> directory inside TC installed path contain only my custom TCExtMenu.mnu file.

This makes TC direct installation pass also all other language and menu files which practically in not a replacement update installation.

It's not a major issue and I just delete useless to me language files after an update installation but I just thought another "automated" workaround can be found.

If you can give me some pseudo code (instructions) when TC should install all languages and when not, I will try to implement it.

ghisler(Author) wrote:If you can give me some pseudo code (instructions) when TC should install all languages and when not, I will try to implement it.

Why not tagging which and how many languages are installed in the ini file (on a fresh installation), so that TC can understand what to do on an update installation?

And also if a custom one has been defined via the language configuration section, to pass also this information inside the ini file as well (in a way this is already possible since in an update installation my custom menu file is not replaced anymore by the default one as in the past prior to v7.50.)

A problem with the above approach can be if a user has customized the default filenames. TC in this case won't understand the change and will overwrite directly the files to update with the possible changes of a newer version.

I suggest to let TC update all language files that are already present in the language folder, but not install additional language files. Afterall there is currently only 14 languages to check for.

I think that if TC detects that wcmd_xxx.lng exists that should be enough, and consequently update all 3 files (wcmd_xxx.lng, wcmd_xxx.mnu and wcmd_xxx.inc).

There is absolutely no need for registering "installed" language files in wincmd.ini - that would mean that TC had to update that list at every close down, since language files can get "installed" by simple copying.

@petermad

Fair enough and simple. This should work but we should also consider the two additional factors:

1) The behaviour over customized versions of .mnu and/or .lng with custom filenames as well.

2) Same as point 1 above but customization has been applied over the standard filenaming scheme.

1) The behaviour over customized versions of .mnu and/or .lng with custom filenames as well.

If a customized .lng/.mnu/.inc file set is beeing used that should stay in effect after an upgrade. Just as it is now.

bump

Sorry, I haven't found a solution yet. The problem is that some languages now have .inc files which they didn't have before. If TC would update only the existing language files, these .inc files wouldn't be installed...

The problem is that some languages now have .inc files which they didn't have before

As I suggested:

if TC detects that wcmd_xxx.lng exists that should be enough, and consequently update all 3 files (wcmd_xxx.lng, wcmd_xxx.mnu and wcmd_xxx.inc).

Hi, folks.

Issue fixed by T.C. 7.50 pb5. Cf. here, please.

Kind regards,
Karl

Thank you Christian for implementing this.

I have also tested the behavior when using a custom filename.

The install won't install any menu or language file keeping the custom one in use.

Yes, that's how it should be! The only problem is that users with a custom menu will not see any new commands like the internal associations then...

ghisler(Author) wrote:The only problem is that users with a custom menu will not see any new commands like the internal associations then...

Well, yes but I don't see this as a problem. If a user is using a custom one he is responsible for either continue modifying it or follow the custom menu development of the corresponding menu author.

At the end of the day not all added new internal commands are also added on the default menu file so this is only a natural "limitation".

Thank you once again!