Post a reply

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

martin

SlugFiller wrote:

It also gave an error like "Cannot focus invisible or disabled window" after the last session closed.

Thanks for your report.

Can you send me an email, so I can send you back a debug version of WinSCP to track the problem? Please include link back to this topic in your email. Also note in this topic that you have sent the email. Thanks.

You will find my address (if you log in) in my forum profile.
SlugFiller

Okay, I tested and it indeed keeps the internal editor windows open. Although it won't allow me to access them until the session is closed. It also gave an error like "Cannot focus invisible or disabled window" after the last session closed. So, slight improvement from previous versions, at least. I lose the session, but get to keep the files.

I do find myself simply opening a second WinSCP instance on various occasions, just to avoid dealing with the modal reconnection dialogs. At least that's available as a workaround.
martin

I understand that all. But you also have to understand that your use case is very specific.

SlugFiller wrote:

"Ok" will close the session tab, close all the internal editor windows opened from that session, and basically cause you to lose any unsaved edits.

This is the part where we differ. Closing session tab does not close internal editor windows. At least not in the latest version.
SlugFiller

No, the problem isn't the main window. The problem is that the session tab itself is closed, along with any internal editor windows associated with that session. More importantly, the problem is that you can't access the window at all if there's a connection issue on any session.

Since this seems not clear to you, I'll give a couple of example use cases.

Case 1: Suppose you connect to a server that's hosted on a private internet connection with a dynamic IP. You open a few files to edit in the internal editor. While working, the server has a momentary internet loss, and gets a new IP. You're quickly able to determine the new IP, and want to reconnect. However, WinSCP is determined to retry to connecting to the same IP as before.

In a perfect world, WinSCP would allow you to edit the connection settings, but keep all the other session details intact. But let's assume that's farfetched.

In a moderate world, you'd be able to tell WinSCP to stop trying to connect, transforming the session into "offline mode". You'd still be able to view the file list on the last open directory, and work with the open internal editors, but you wouldn't be able to change folders or save the open files.

In a minimal usability world, you'd be able to ignore the reconnection window, click on the internal editors, use Ctrl+A and Ctrl+C to copy the unsaved content, and paste it in an external editor. You can then close the session, open a new session, re-open the files, and paste the data from the external editor back into the internal editor.

In the actual world, WinSCP will not allow you to interact with any part of it except for two buttons: "Reconnect" and "Ok". "Reconnect" will continue to fail, and basically keep you stuck in the same loop. "Ok" will close the session tab, close all the internal editor windows opened from that session, and basically cause you to lose any unsaved edits. It will also switch to another tab, which, if it also has connection issues, will re-pop the reconnection window without even redrawing the window in the background or actually telling you which session it belongs to.

Use case 2: You have two sessions open. For security reasons, you decided not to save the session password of the second session in memory. But that's okay, because that password is saved on a file available from the first session. You had a network hiccup which made both sessions disconnect. The first one reconnects without issue, but the second one pops up a password prompt.

To get the password, you have to go to the other session, to look at the file containing the password. But WinSCP will not allow you to switch tabs, let alone open a file, while it's waiting for a password prompt. You have only two options: Input the password (which you can't access), or close the session. So in actuality, you only have one option.

At least in this case, if remembering the password for the first session was just a formality (as opposed to, say, the password having been entered by someone else who already went home), you can open a new instance of WinSCP, and connect to that session from there. But it's really telling when you need to open a new instance of your multi-tab program. It means your tabs aren't doing what tabs are supposed to do.

These are just 2 of numerous use cases I've encountered over the years. And they all boil down to the same problem: Once the connection dialog pops up, the entirety of WinSCP becomes inaccessible. Heck, let's go for one more, one that should be super trivial:

Use case 3: You've been told to connect to a server. For security reasons, the connection details were placed as a text file on another server to which you already have access. You go to that server, double click the text file, which opens it in the internal editor, and then hit "New Session". You now want to copy and paste the connection details from that text file to the "New Session" connection dialog.

Wanna know what actually happens? Just test it. Open any text file in the internal editor, then hit "New Session", then click on the internal editor's window. Once you try that, it should become very obvious what the problem is.
martin

SlugFiller wrote:

This problem has been bugging me for years. Not only does it not let you switch tabs or start a new session, it also locks you out from any open Internal Editor windows. I've lost data because I couldn't access an Internal Editor window to copy the text to another program, because WinSCP was demanding either a successful reconnect, or to close all windows, with no middle ground.

I'm not sure if I understand the problem, but it seems to me that enabling "Keep main window open when the last session is closed" is what you need.
https://winscp.net/eng/docs/ui_pref_window
SlugFiller

This problem has been bugging me for years. Not only does it not let you switch tabs or start a new session, it also locks you out from any open Internal Editor windows. I've lost data because I couldn't access an Internal Editor window to copy the text to another program, because WinSCP was demanding either a successful reconnect, or to close all windows, with no middle ground.

I should note that besides the dialog, WinSCP also freezes if loading a directory index takes too long. While it can show you the progress in the title bar, it won't let you switch to a different tab. This is a real productivity killer.

It would be incredible if this could finally be fixed.
martin

Re: Re: Embed modal dialogs in the tab corresponding to the connection.

So what other dialogues do you mean?
ffirenze

Re: Re: Embed modal dialogs in the tab corresponding to the connection.

Possibly I did not explain myself well.

The disconnection is just one example of the multiple dialogues that exist. I think that if they were part of the tab, the application would be more flexible to use multiple simultaneous connections.

Regards!
martin

Re: Embed modal dialogs in the tab corresponding to the connection.

If a non-active session is disconnected, you do not get any dialog. You just get a tray popup. You can keep working with the active session without an interruption. Or do I misunderstand your post?
ffirenze

Embed modal dialogs in the tab corresponding to the connection.

I have been using WinSCP for a long time, and I always wanted to make this suggestion, for this reason:

When you use multiple connection tabs, and one of this tab has a problem, or something who needs to show a dialog, he entire program becomes unusable until answer the dialog. What I say seems silly, but I think it would make it much more usable.

For example, if a connection was lost, possibly because one of them sent to restart the host, and wants to continue using another connection, we are currently forced to disconnect that session, to work with the other one and then reconnect. With my proposal, the problem would only be shown in the corresponding tab, and when we can retry the connection whenever we want. (More easy to reconnect)

Regards!