Switching to C: after returning the drive and canceling the selection of another one

[Fla$her]

An ancient problem that I was embarrassed to raise, because the locals probably already know about it, but for some reason ignore it.

1. IgnoreDirErrors=0/-1
2. An external drive is open in the active panel.
3. Turn it off through the notification area (this is often necessary before switching to sleep/hypernation).
4. Activate TC (including after hypernation) and receive a message with a combo box:

   Code: Select all

   -------------------------
   ERROR!
   -------------------------
   F:
   Please chose another: [ ]
   [OK] [Cancel]
   -------------------------

5. While this dialog is present, I return the drive.
6. I click [Cancel] in the dialog, expecting to avoid changing the path, but instead of trying to check for the drive, TC opens the root of C: (even if the tab is locked with the possibility of changing the directory), which is frustrating and annoying.

Please check for the drive after pressing [Cancel] and do nothing if there is one.
And if the drive is not found, then follow the path of the active locked tab, if there is one.

In the case of IgnoreDirErrors=1, this dialog doesn't appear and I just need to press Ctrl+R (cm_RereadSource) so that instead of <Read error!> see the contents. But the problem is that with this option, this dialog will appear when you independently try to open a non-existent drive/folder.

[JOUBE]

If you click cancel, this additional check would consume far too much time *) and disrupt the workflow.

*) especially if the drive is really not accessible/exists

[Fla$her]

If you click cancel, this additional check would consume far too much time and disrupt the workflow.

This is a very quick check. Only the current behavior disrupts the workflow.

[JOUBE]

Only the current behavior disrupts the workflow.

No.

And (additional): The behavior is a decision, not a bug.

[Fla$her]

If no, then there would be no reason to write.

And (additional): Unexpected and problematic behavior can also be classified as a bug. And it doesn't matter what you call it. There is no strict logic here.

PS: I don't comment on further flooding/trolling.

[JOUBE]

And (additional): Unexpected...

Maybe for you as a new user. For all other users not.

...strict logic...

Software has nothing to do with that.

[ghisler(Author)]

Thanks for your suggestion. Currently there are no plans to change this behavior.

Moderator message

Moved to suggestions

[Fla$her]

Currently there are no plans to change this behavior.

1. What do you mean by "Currently"? The current version or your current attitude to this?
2. What justifies the current behavior with C: opening? Why does this also happen when canceling the closure of a locked tab?
3. Why doesn't the locked tab folder open?

[ghisler(Author)]

It's a minor inconvenience which would require a LOT of work to change. For example, it's not guaranteed that the locked tab folder is accessible, which would result in another error.

[Fla$her]

For me, it is significant because I encounter it every day, both when returning from hypernation, and when accidentally pressing Ctrl+W. It's so annoying that I can't stand it anymore. Therefore, gritting my teeth, I finally wrote about it, although I should have done it a long time ago.

I didn't think it would take a lot of work to check a couple of states.
But you could do the first part first: do nothing if there is a drive.

I'm trying to understand the logic behind opening the C: drive, especially when trying to close a locked tab. Logically, how can the No or Cancel buttons lead to drive C: instead of doing nothing? Aren't these buttons just to hide an accidentally triggered dialog? If the drive needs additional checking, then what does the existing folder in the locked tab have to do with it?

[Fla$her]

2ghisler(Author)
Please answer my question.

[ghisler(Author)]

I don't want to risk introducing a ton of new bugs this late in the beta test, sorry.

[Fla$her]

2ghisler(Author)
1. OK, can you move this to the next beta testing pool?
2. You are not answering the question itself. Why do the Cancel and No buttons behave inexpediently? Why was such a strange choice made during development?

[ghisler(Author)]

What no button? There is only an OK and a Cancel button in the drive choose dialog ("Please chose another:").

[Fla$her]

>>>

6. I click [Cancel] in the dialog, expecting to avoid changing the path, but instead of trying to check for the drive, TC opens the root of C: (even if the tab is locked with the possibility of changing the directory), which is frustrating and annoying.

I'm trying to understand the logic behind opening the C: drive, especially when trying to close a locked tab. Logically, how can the No or Cancel buttons lead to drive C: instead of doing nothing? Aren't these buttons just to hide an accidentally triggered dialog? If the drive needs additional checking, then what does the existing folder in the locked tab have to do with it?