[8.0ß22x86] Inplace rename confirm button problem

[Bluestar]

Steps to reproduce:

01. Enter to an FS (wfx) plugin inside Total Commander (which lists some items) [for example Device Manager]
02. Click once on an item, for example on "About"
03. Type "cm_RenameSingleFile" (without quotes) to TC's command line (or click twice on the item slowly), and press Enter
04. The edit confirmation button keeps being visible (however the editbox is - correctly - already invisible) [screenshot]

One more problem about this thing:
Since this "Error: Can't write: \\Device Manager\.." dialog seems not to be modal, the user can still click anywhere inside TC while this dialog is opened... that leads to many problems, for example check this screenshot.

Win7SP1x86 / TC8.0ß22x86

[umbra]

Confirmed in both 32b and 64b versions.

[karlchen]

Hello, Bluestar.

Followed the steps that you listed.

I can reproduce the problem which you explained in the section One more problem about this thing:.

Yet, here the inline rename box remains visible and editable. Even if I switch on the InplaceOKButton. (It is off here by default.)
I.e. I can keep on trying to edit the not changeable name everytime I have confirmed the error message that the file cannot be moved, until finally I click on cancel in the error dialogue.
Maybe this is due to the fact that the only filesystem plugin here is Christian's sFTP plugin v1.2 and not the Device Manager plugin.

Environment:
+ Total Commander 8.0ß22 32-bit
+ Total Commander 7.57a (no InplaceOKbutton available of course)
+ on Wine v1.2.3 and Ubuntu 10.04.4 Desktop 32-bit

Kind regards,
Karl

[ghisler(Author)]

2Bluestar
Sorry, I do not understand the problem. After I press ENTER, I get an error that the item could not be renamed. While this box is shown, the confirmation button is visible - but it disappears as soon as I close the box when I click on Cancel. If I click on OK, it remains visible while TC asks for a different name, but goes away when the last dialog box is closed.

[umbra]

2ghisler
Yes, when you close the dialog everything works fine. But the dialog is not modal and if you try to work with TC while this dialog is open, you will see many kinds of bugs.

[karlchen]

if you try to work with TC while this dialog is open, you will see many kinds of bugs.

I really wonder what these bugs might be?
The term bug implies that software malfunctions. Yet, which malfunctions do we really experience?

We can activate the T.C. main window and double-click on a number of folders. T.C. will display the open-folder icon for each of them, but not enter one of them.
This behaviour may not be what we expect. Yet, what do we expect here? Should T.C. enter the double-clicked folder and list its content? Or should it refuse and explicitly tell us to close the error dialogue first?

We can activate the T.C. main window and double-click e.g. a .txt-file. T.C. will launch the associated editor and the editor will open the selected file. This can hardly be called a bug. This is by design.

The issue here really and only is that T.C. allows us to ignore the error dialogue and re-activate the main window. It should not do so.

Karl

[umbra]

Karlchen, seriously? In that state TC doesn't allow you to open folders, it shows wrong icons, tab switching doesn't work, ... And you are wondering whether it's a bug or it's by design. I call this behavior a "many kinds of bugs".
Also you (accidentally ) omitted the first part of the quoted sentence:

But the dialog is not modal and ...

Well, I thought it was obvious what the problem was.

[karlchen]

Hello, umbra.

But the dialog is not modal and ...

The issue here really and only is that T.C. allows us to ignore the error dialogue and re-activate the main window. It should not do so.

Hm, different wording, but describing the same fault. So we seem to agree that this is the bottom of the problem. Once this has been corrected there will be no more need to discuss the various details of unexpected behaviour which result from the source problem.

Cheers,
Karl

[ghisler(Author)]

But the dialog is not modal and ...

That's the real bug here - I will fix it.

[umbra]

I can confirm a fix in TC 8.0 b23. The confirmation button next to the inplace rename box is still visible even when an error dialog is shown, but that is just a glitch.

[ghisler(Author)]

Thanks!