[8.0ß25] 'Edit linked button bar' is shown incorrectly

[Flint]

The problem was mentioned here, but since there was no reaction I suppose it was just overlooked. So, I create a separate report for it (and extend it a little).

The presence and absence of the "Edit linked button bar" and "As Administrator" commands in the right-click menu of a buttonbar button sometimes calculated incorrectly. Here are two scenarios.

Scenario I
1. Add the following button to the TC buttonbar and right-click it:

Code: Select all

TOTALCMD#BAR#DATA
OPENBAR "%COMMANDER_PATH%\DEFAULT.BAR"

wcmicons.dll,14

2. Though the command opens the buttonbar, its menu contains the "As Administrator" command (which does nothing) and does not contain the "Edit linked button bar" command. If quotes around the BAR path are removed, everything goes back to normal.


Scenario II
1. Add the following button to the TC buttonbar and right-click it:

Code: Select all

TOTALCMD#BAR#DATA
notepad %COMMANDER_PATH%\DEFAULT.BAR

notepad.exe

2. The command just opens Notepad, but it's recognized by TC (erroneously) as opening the child bar, and therefore its right-click menu does not include the "As Administrator" command but includes the "Edit linked button bar" command.

[MVV]

Confirmed.

I think TC should split command line to parameter array (and remove quotes around parameters) and check:

1. First parameter contains path to BAR-file.
2. First parameter is 'OPENBAR'.

Only theese two cases should enable 'Edit linked button bar'.

[ghisler(Author)]

Please stop using OPENBAR in button bars! Just use the .bar file directly. There are probably dozens of other problems caused by using OPENBAR in the button bar. OPENBAR was NOT added for this - you could use .bar files for much longer to swap bars directly without OPENBAR.

[Flint]

Please stop using OPENBAR in button bars!

Well, I don't but some users might add this command after reading in the help file that this command is designed specifically for switching buttonbars. TC does need some fool-proofness here, so OPENBAR should be either fully supported, or explicitly forbidden in buttonbars.

Besides, using OPENBAR might be useful if you wish some flexibility: for example, specifying OPENBAR without parameters would allow to drag&drop the buttonbar to this button for simply opening it. (Of course, in this scenario it is impossible to use the "Edit linked bar" command, but my point was that OPENBAR in buttonbar is not that useless as it may seem.)

[white]

I think TC should split command line to parameter array (and remove quotes around parameters) and check:

1. First parameter contains path to BAR-file.
2. First parameter is 'OPENBAR'.

Only these two cases should enable 'Edit linked button bar'.

I think there is no way you can do this without breaking compatibility with older versions.

I suggest to add a tri-state checkbox to the change button dialog that can override the default behaviour. So the checkboxes would be:

Code: Select all

Subbar (tri-state checkbox)
Run minimized/Show as menu
Run maximized

States of the Subbar checkbox:

• Square -> No override (default). Whether or not the command is a subbar is autodetected. (the compatible way)
• Checked -> The command is a subbar, regardless which extension is used.
• Unchecked -> The command is no sub bar, regardless which extension is used.

Furthermore, like Flint (here), I think there should be no difference whether the user specified the OPENBAR command or not.

[MVV]

I think there is no way you can do this without breaking compatibility with older versions.

Why? Any correct usage case is compatible with my statements for all TC versions:

1. First parameter contains path to BAR-file.

Code: Select all

1.1 X:\Path\To\Bar.bar
1.2 "X:\Path\To\Bar.bar"

2. First parameter is 'OPENBAR'.

Code: Select all

2.1 OPENBAR X:\Path\To\Bar.bar
2.2 OPENBAR "X:\Path\To\Bar.bar"

I don't see any other correct command for BAR-file in a buttonbar button.

[white]

I don't see any other correct command for BAR-file in a buttonbar button.

Well, the following also works:

Code: Select all

My buttonbar.bar
\\Computer\Sharename\My buttonbar.bar
\\?\c:\my path\My buttonbar.bar

How should Total Commander deal with the following examples?

Code: Select all

My program My buttonbar.bar
This is not a buttonbar but another format also using the bar extension.bar

[MVV]

white, your examples cause ambiguity so I would refuse to use them. Well, TC may firstly check if entire command line points to existing BAR-file, and then apply my statements.

[white]

Well, TC may firstly check if entire command line points to existing BAR-file, and then apply my statements.

It's probably not a good idea to do IO-checks while the user is editing the input field.

[MVV]

So, what do YOU suggest to do?
It is always hard to detect if user is lazy enough to skip quotes around path containing spaces, especially if there are more than one space. I think TC shouldn't check more than one path in such case.

TC may do checks with some delay (e.g. one per second or two) using some kind of a timer message (or simply after a delay since previous check, or w/o delays at all, just when command field loses focus - probably the best case).

[Flint]

Just my 2¢
Checking by extension only is enough. The whole Windows relies on file extensions being the unique file type identifiers, so I don't think TC doing the same should be treated as a greatest fault in the world.

[MVV]

Flint, problem comes with command lines that contain spaces and ends with .BAR. TC must decide here what user wants: start some program with a path to BAR-file (notepad default.bar) or he just specifies path to BAR-file with spaces (my best default.bar). As I said, TC may try to check if entire line exists as a file (notepad default.bar or my best default.bar) and then parse string as a command line with multiple parameters divided by spaces.

[Flint]

MVV
I see. I missed this point…
But checking the file system may be slow, especially if this is a network drive. Well, I suppose that in this case TC should work as follows:

1) OPENBAR anything with_or_without spaces -> BAR file (even when the file name does not end with ".bar")
2) something_without_spaces.bar -> BAR file
3) something with spaces.bar -> not a BAR file (but program named "something" taking arguments "with spaces.bar")
4) "something with spaces.bar" -> BAR file

Seems to cover all the cases. Yes, there is still possibility that my file.bar specified without quotes is a real BAR file, and according to the suggested scheme it won't be recognized as such. But it's the user's fault not to specify quotes. Imagine that after creating such a button you install a program named "my.exe" that happens to be in your PATH — the real action of the button will immediately change, which is impossible to find out without checking the real disk contents, and I'm quite positive this must be avoided at all costs. BTW, TC itself should also add quotes when user creates a child panel button…

[white]

Imagine that after creating such a button you install a program named "my.exe" that happens to be in your PATH — the real action of the button will immediately change, which is impossible to find out without checking the real disk contents, and I'm quite positive this must be avoided at all costs.

Too late. Execution of the button command already depends on disk contents and people maybe are already using it. Changing this behavior would mean that some people's buttonbar may no longer work right after updating TC.

So, what do YOU suggest to do?
It is always hard to detect if user is lazy enough to skip quotes around path containing spaces, especially if there are more than one space. I think TC shouldn't check more than one path in such case.

TC may do checks with some delay (e.g. one per second or two) using some kind of a timer message (or simply after a delay since previous check, or w/o delays at all, just when command field loses focus - probably the best case).

TC should do the same checks as when the command is executed. However that means IO-checks. It could be done when the command field loses focus, but is this also wanted behavior when right clicking a button?

My suggestion was to not have a fully consistent subbar checking, but to give the users the possibility to explicitly tell TC when something is a subbar for cases when auto-detection is off.

As an alternative for the proposed tri-state subbar checkbox, you could also make a more general solution for disabling auto-detection. Below the Command field, a new field "Command type" could be added. This could be a dropdown field with values like:

Code: Select all

Command type: Auto-detect (default)
              External command
              Internal command
              Button bar

Or an entry "Change command type" could be added to the menu under the Change button.

In any case, it would be a nice if users could have full control by turning off auto-detection and control things manually.

[Flint]

Too late. Execution of the button command already depends on disk contents and people maybe are already using it. Changing this behavior would mean that some people's buttonbar may no longer work right after updating TC.

What do you mean? I'm not talking about executing a button's command, I'm talking about detection of the button as opening a child BAR file or not, and therefore having or not having the appropriate commands in the context menu.

You cannot run a command without disk I/O request, so working with disk when running a command is normal. But if just opening a context menu for a button would check the disk contents and possibly hang for several seconds because of slow network, I'll probably stop using the buttonbar.