Q: Why can't I put a download in the background as when copying?
A: Because an FTP server only supports a single file transfer through one connection, Total Commander needs to create a new connection for every background transfer. Therefore you need to check the option to download in background in the dialogue box which appears before the download starts.
I cannot understand the answer given in the FAQ to this subject. Yes, TC has to open a new connection but what has that anything to do with showing the progress info on which window?
TC is managing all windows and dialogue boxes. It should be possible to open the background transfer window and move the transfer progress info there and then open a new connection to the server, get the directory, feed that data in the panel where the connection was initially opened.
Am I missing something?
Thanks
Riz
Put a download in the background as when copying
Moderators: Hacker, petermad, Stefan2, white
It would be possible. The only required thing would be to implement locking of just one panel.
In a way, current behaviour makes sense. If you connect to FTP and start file transfer, you can no longer use current control connection for anything else, including file/directory browsing. You can in theory open a new one, but there's no guarantee that it will succeed (e.g. server can have connection limit for one user). So far author solved it by giving the responsibility to users. They can choose in advance if they want to use background transfer, i.e. open new connection. And if that doesn't work, it's their fault. :) If there was a background button, it would shift the responsibility back to TC. What if new connection could not be opened? Obviously user could not continue to browse in opened FTP panel. Now what?
But I don't think it's really a problem, just block the whole panel (and not even whole panel, just one tab if there are more) and problem is solved. And the same thing could be done not only for FTP, but also for other things. E.g. slow network drive taking half a minute to refresh, why I have to stare at dead TC the whole time? If it blocked only one panel, I could do something else in other one in the meantime. Or start something using toolbar button. Now I have to start another TC to do that and it's not user-friendly at all.
In a way, current behaviour makes sense. If you connect to FTP and start file transfer, you can no longer use current control connection for anything else, including file/directory browsing. You can in theory open a new one, but there's no guarantee that it will succeed (e.g. server can have connection limit for one user). So far author solved it by giving the responsibility to users. They can choose in advance if they want to use background transfer, i.e. open new connection. And if that doesn't work, it's their fault. :) If there was a background button, it would shift the responsibility back to TC. What if new connection could not be opened? Obviously user could not continue to browse in opened FTP panel. Now what?
But I don't think it's really a problem, just block the whole panel (and not even whole panel, just one tab if there are more) and problem is solved. And the same thing could be done not only for FTP, but also for other things. E.g. slow network drive taking half a minute to refresh, why I have to stare at dead TC the whole time? If it blocked only one panel, I could do something else in other one in the meantime. Or start something using toolbar button. Now I have to start another TC to do that and it's not user-friendly at all.
-
sqa_wizard
- Power Member
- Posts: 3896
- Joined: 2003-02-06, 11:41 UTC
- Location: Germany
Sorry, you cannot move a connection to background.
The background process is a new process
You have to open a new connection for this new process.
If you started a download in foreground, sending it to background has to terminate the active connection (and the download of course) and open a new connection.
The download may not be continued, but started again from scratch (depending on server capabilities).
That is the main reason, why you have to choose in advance if you want to use background transfer or not.
The background process is a new process
You have to open a new connection for this new process.
If you started a download in foreground, sending it to background has to terminate the active connection (and the download of course) and open a new connection.
The download may not be continued, but started again from scratch (depending on server capabilities).
That is the main reason, why you have to choose in advance if you want to use background transfer or not.
#5767 Personal license
Sorry, I don't believe you. :)
In some sense background transfer may be "different process", but in other it's still only one Windows process, only one running TC. There's no reason why background transfer would have to be tied to any specific window or anything. In other words, you just need to separate the "engine" from the user interface.
So there would be one thread in TC doing its business down or uploading some file and not caring about any user interface. It would just know the handle of one window to which it should send status/progress updates. If this was originally foreground transfer, then when user would press Background button, TC would try to establish new connection to server to use as new connection for browsing. If it failed, TC would say "sorry, can't put transfer to background". If it succeeded, it would create new background window and tell the original working thread to send status updates there. And the newly established connection would be used for foreground work.
I don't see any problem with that. And while I like my suggestion with blocked panels better (mainly because it could be used also for other things), this method would not be bad either and it should require less changes.
In some sense background transfer may be "different process", but in other it's still only one Windows process, only one running TC. There's no reason why background transfer would have to be tied to any specific window or anything. In other words, you just need to separate the "engine" from the user interface.
So there would be one thread in TC doing its business down or uploading some file and not caring about any user interface. It would just know the handle of one window to which it should send status/progress updates. If this was originally foreground transfer, then when user would press Background button, TC would try to establish new connection to server to use as new connection for browsing. If it failed, TC would say "sorry, can't put transfer to background". If it succeeded, it would create new background window and tell the original working thread to send status updates there. And the newly established connection would be used for foreground work.
I don't see any problem with that. And while I like my suggestion with blocked panels better (mainly because it could be used also for other things), this method would not be bad either and it should require less changes.
-
Balderstrom
- Power Member
- Posts: 2148
- Joined: 2005-10-11, 10:10 UTC
This is a problem with many of TC Dialogs currently: too many modal dialogs. Unfortunately Mr.Ghisler's response to this particular type of issue has been to suggest one open a second (or more) instance(s) of TC.
Which might be possible, except
---> TC doesn't automatically save it's active Tabs & Settings to file.
If you haven't manually done this prior to starting a new instance then TC will start up with it's state equivalent to whatever it was when you last opened TC, not it's current state.
Which might be possible, except
---> TC doesn't automatically save it's active Tabs & Settings to file.
If you haven't manually done this prior to starting a new instance then TC will start up with it's state equivalent to whatever it was when you last opened TC, not it's current state.
*BLINK* TC9 Added WM_COPYDATA and WM_USER queries for scripting.