ericjs wrote:

Isn't there some easier partial fix that could be made in the short term, like simply making that connection window non-modal?

Unfortunately no.

I second this request! (Actually I think I posted it a couple years ago and got a reply that it was going to be revised in an upcoming version...perhaps that was when it was realized that the design was such that it wasn't easy to fix?)

It truly is a bothersome behavior. It's really eccentric, even incorrect, windowing behavior. It used to particularly drive me nuts when I had multiple sessions going, would lose the connection to one and not want to dismiss it since I knew I'd be able to reconnect again in a few minutes, but had no way to access the other sessions in the meanwhile.

Isn't there some easier partial fix that could be made in the short term, like simply making that connection window non-modal?

Thanks for understanding. I look forward to future development of WinSCP. Also, I am now using the latest version and I have not experienced any unexpected disconnections (yet). :)

-Neil

I understand your problem. Misunderstanding here is that you think WinSCP does this by purpose. It does not. Redesigning this is definitely on todo list. Though it is quite complex think to do, so it takes time.

martin wrote:

Neillithan wrote:

So that's it? My point is invalid because the blocking of user interaction is the preferred method? This is a blatant disadvantage/limitation, especially since it interferes with the multiple sessions feature. I wish to know your response to this.

I'm sorry I'm confused. WinSCP supports background transfers as you also acknowledge. So if you prefer that, use them.

Okay, lets start completely over.

When I am transferring files to and from my server using background transfer, I am allowed to continue freely browsing the FTP and I can freely access any and all buttons / menus of WinSCP. But, when I lose connection to the FTP, the background transfers are still going, but I lose the ability to access buttons / menus of WinSCP because that message window is blocking me from doing so. You claim this is normal behavior, but you're not taking into account that WinSCP supports multiple sessions, and if just one of the sessions disconnects, that message prevents the user from accessing the drop down menu to change sessions. They are forced to deal with the reconnect dialog, and from what I've told you... if there are any background transfers in progress, the only button you can press that won't interfere is the "reconnect" button. If I press "Ok", it disrupts the background transfers. I can't just leave the reconnect message open and switch sessions, I have to "deal" with it by first reconnecting and then I gain access to the drop down menu to change sessions.

The "entire" point I'm making is, the reconnect message box is "extremely" annoying, and as such, you probably "should" redesign it. It's not very well implemented, and it makes using the multiple sessions feature of winSCP a real pain, especially when background transfers are in progress, because when that "reconnect" message box appears, it blocks all interaction with the program until I click the "Reconnect" button. It's only a matter of time before the FTP disconnects from the server and that "reconnect" message box reappears causing further annoyance. Sometimes I don't want to reconnect to the FTP, I just want to change sessions. I can't do that without reconnecting or else the background transfers will be interrupted due to the fact that the only other button to press is the "OK" button.

I feel like, at this point, I'm beating a dead horse... so if you "still" do not understand, the only way I can convey this with a total lack of confusion would be to record a video and illustrate / narrate how the reconnect message box can seriously make using WinSCP a pain. Don't get me wrong, I love WinSCP and I would love to see it be constantly improved, I'm just saying one thing about it could be done differently to make using it a whole lot easier.

Thanks,
-Neil

Neillithan wrote:

So that's it? My point is invalid because the blocking of user interaction is the preferred method? This is a blatant disadvantage/limitation, especially since it interferes with the multiple sessions feature. I wish to know your response to this.

I'm sorry I'm confused. WinSCP supports background transfers as you also acknowledge. So if you prefer that, use them.

So that's it? My point is invalid because the blocking of user interaction is the preferred method? This is a blatant disadvantage/limitation, especially since it interferes with the multiple sessions feature. I wish to know your response to this.

-Neil

I don't have a lot of time to respond, I have to head to work, but I'll be sure to get the latest version of WinSCP when I get back from work today.

Regarding the window blocking interaction with the program, WinSCP does allow multiple sessions simultaneously. The fact that any window like that would block user interaction regardless of their being multiple running sessions just seems ... not very well thought out.

I'd much rather use multiple "instances" of the program to get around this problem, so why not take that into consideration? Using multiple sessions like that is almost counter productive when I can simply use multiple instances of the program to avoid a nasty inconvenience.

Please tell me I'm not wrong with my line of thinking.

Thanks,
-Neil

Neillithan wrote:

So that's where I make a feature request: can the disconnect window be made less annoying? Perhaps, make it a toolbar that pops down inside the remote-side portion of the WinSCP window that says, "You have been disconnected" with the usual "OK", "Reconnect" and "Help" button (Similar to Firefox's Yellow toolbar that drops down at the top when asked to save passwords for a website). Also, can a warning be displayed (when pressing "OK") that all background transfers will be interrupted if the user continues? With the toolbar method, I could continue using the program normally having access to scroll bars, file/edit/view menu or the local side file manager. This would (above all) enormously reduce the annoyances of the program.

It is actually opposite. The message blocks WinSCP for a simple reason. WinSCP was not designed to operate when the session is closed. So I cannot make it less annoying, unless I redesign WinSCP. Though since 4.2.2, WinSCP does reconnect automatically, so it should be better now. What version are you using?

I suggest implementing a "global" upload restriction. One that affects SESSIONS as well. For instance, if I set my upload rate to 64, it should affect all active sessions, not just the "one" I just so happened to restrict. This upload restriction should be configurable from the preferences of WinSCP, or a dropdown menu always-viewable from a toolbar on the main program.

Again, available since 4.2.2 beta.

Last but not least, WinSCP needs more intervals for speeds. Everything leading up to 64 is too slow, and 128 is too fast. There isn't an inbetween. You can't satisfy everyone with preset numbers like that, I suggest letting the user choose the value manually. Also, it would help if "KBps" was specified to reduce confusion. 64 could mean anything. 64kbps, 64bps, 64MBps... nobody knows until they trial and error it, which is what I had to do.

AFAIK, everywhere you can change a speed, you can enter the number manually. Where do you miss the option?

Hi, I wasn't sure whether to post about this in the support/bug reports section of the forum or the feature requests part, because it might involve implementing a change to WinSCP.

First of all, I rent a server for Unreal Tournament 3 which requires me to upload lots of custom maps/files to an FTP. I prefer to do a background transfer so that I may continue uploading files to different folders. In other words, I need to be able to browse the FTP while transferring files to the FTP. That's not a problem.

When I leave the FTP idle for more than 1 minute, it loses connection. I have keepalive enabled for that specific connection, but it doesn't seem to work. Again, that's not really the problem. The problem is, a small window pops up asking me what to do when I lose connection to the server. It tells me I have lost connection to the FTP Server and presents me with an OK button, a Reconnect button and a Help button. If I press OK, it closes WinSCP which consequently ends all background transfers, what an annoyance! If I press Reconnect, it simply reconnects me to the FTP as expected, but it's only a matter of time until it disconnects again, so this disconnect window will just keep reappearing every 60 seconds unto infinity.

What REALLY makes matters worse is, this disconnect window monopolizes WinSCP. I can't just move it aside and continue using the program, I have to click reconnect and then continue using the program. I can't access any of the File Edit View menus, I can't scroll the background-transfer portion of the main window. I am "forced" to reconnect to the FTP if I want to do anything.

So that's where I make a feature request: can the disconnect window be made less annoying? Perhaps, make it a toolbar that pops down inside the remote-side portion of the WinSCP window that says, "You have been disconnected" with the usual "OK", "Reconnect" and "Help" button (Similar to Firefox's Yellow toolbar that drops down at the top when asked to save passwords for a website). Also, can a warning be displayed (when pressing "OK") that all background transfers will be interrupted if the user continues? With the toolbar method, I could continue using the program normally having access to scroll bars, file/edit/view menu or the local side file manager. This would (above all) enormously reduce the annoyances of the program.

Also, this is another annoyance I discovered when using WinSCP. I have to transfer lots of files to my server. By default, WinSCP will queue up files to be uploaded and will only transfer 2 sets of files at a time. If I want to limit my upstream, I have to manually right click the active uploads and specify an upload rate of 64 for each individual upload. That seems to work, until one of the queued uploads begins, and then I have to manually set the upload rate of that as well.

Well, I have Comcast and when my upstream is being maxed out, it makes browsing the net, watching online videos, playing online video games, or just about any task that requires the internet EXTREMELY laggy. I have to babysit my WinSCP to make sure it never maxes out my upload and it doesn't help that queued files are unaffected when I try to manually specify upload rate.

I suggest implementing a "global" upload restriction. One that affects SESSIONS as well. For instance, if I set my upload rate to 64, it should affect all active sessions, not just the "one" I just so happened to restrict. This upload restriction should be configurable from the preferences of WinSCP, or a dropdown menu always-viewable from a toolbar on the main program.
Last but not least, WinSCP needs more intervals for speeds. Everything leading up to 64 is too slow, and 128 is too fast. There isn't an inbetween. You can't satisfy everyone with preset numbers like that, I suggest letting the user choose the value manually. Also, it would help if "KBps" was specified to reduce confusion. 64 could mean anything. 64kbps, 64bps, 64MBps... nobody knows until they trial and error it, which is what I had to do.

I do admit that I have limited experience with this program, and if you find yourself shouting the answers at me because I didn't take the time to fully learn the program, then you would be right. I don't have the time to figure out the inner workings of an entire program, I'm just an end user. So, please go easy on me. I appreciate any help provided. :)

Thanks,
-Neil