Your opinion about the Background Transfer Manager

[ghisler(Author)]

I don't think that we wil lcome to an agreement here. Therefore I would like to propose something in between: TC could clear the overwrite flag when the queue in the background transfer manager becomes empty. This way, the user-selected overwrite method becomes active for the current batch, but not for any later batches when the user has forgotten what he chose.

[gdpr deleted 6]

I don't think that we wil lcome to an agreement here. Therefore I would like to propose something in between: TC could clear the overwrite flag when the queue in the background transfer manager becomes empty. This way, the user-selected overwrite method becomes active for the current batch, but not for any later batches when the user has forgotten what he chose.

I think that could work, considering that you probably have many other things on the table and the TC8.50 release is looming on the horizon.

[gdpr deleted 6]

Argh... i found just the next neck-snapper with the BTM.

Say, you have a copy/move job running in a BTM with many or larger files.

What would you do? Right, staring at the BTM until the operation is finished.
Erm... no, of course not. The BTM will be pushed into the background and should do its bidding.

All the while, you will do other things; writing comments in this forum, for example.

However, and that is the bummer, when the BTM wants to prompt regarding a file to overwrite, it will STEAL the keyboard focus.

Now imagine that happens right in the moment when i want to type "Argh..." in my forum comment.

Frankly, right now and here i can imagine the mood of a user going like "Woot? FU!"


EDIT: Bug report about this issue here

[MVV]

But some kind of flags indication would be helpful. Also, currently all BTM windows are nameless. If we name them (e.g. BTM1, BTM2 etc) TC will be able to specify BTM id in copy dialog to show user which BTM will be used.

[white]

I don't think that we will come to an agreement here. Therefore I would like to propose something in between: TC could clear the overwrite flag when the queue in the background transfer manager becomes empty. This way, the user-selected overwrite method becomes active for the current batch, but not for any later batches when the user has forgotten what he chose.

I have thought about that solution from the beginning of the discussion, but it's hardly sufficient. Several insecurities that can have disastrous consequences still remain. See for example the post I mentioned earlier. Another example: When the user presses the Delete key or drags a file on the F8 Delete button, a confirmation dialog is shown before deleting the file. But if the user drags and drops a line in a paused BTM, which may very well be accidental, there is no confirmation dialog although it can cause ten thousands of files to be deleted and replaced by other files without warning.

I think you know the risks. What argument of yours outweighs the user's loss of data? Do you feel you share responsibility for users losing their data? Could you be sued for it?

Also, currently all BTM windows are nameless. If we name them (e.g. BTM1, BTM2 etc) TC will be able to specify BTM id in copy dialog to show user which BTM will be used.

The BTM id can change at any given moment as I explained at the bottom of the post I mention above. It's like having an Overwrite all option in the copy dialog which may get enabled automatically at any time, for example at the moment you click the F2 Queue button. Hence why I called it Russian roulette.

[gdpr deleted 6]

I have thought about that solution from the beginning of the discussion, but it's hardly sufficient. Several insecurities that can have disastrous consequences still remain. See for example the post I mentioned earlier. Another example: When the user presses the Delete key or drags a file on the F8 Delete button, a confirmation dialog is shown before deleting the file. But if the user drags and drops a line in a paused BTM, which may very well be accidental, there is no confirmation dialog although it can cause ten thousands of files to be deleted and replaced by other files without warning.

I think you know the risks. What argument of yours outweighs the user's loss of data? Do you feel you share responsibility for users losing their data? Could you be sued for it?

I wholeheartedly agree. While i first agreed with Ghisler's suggestion, it becomes clear that i underestimated the number/scope of issues the BTM has...

[MVV]

The BTM id can change at any given moment as I explained at the bottom of the post I mention above. It's like having an Overwrite all option in the copy dialog which may get enabled automatically at any time, for example at the moment you click the F2 Queue button. Hence why I called it Russian roulette.

But TC wlll be able to show an error if BTM3 is already closed and you're trying to add job to it (using 'F2 Queue: BTM3' button). So you will be sure that job will be added exactly to BTM3. It would be even nicer to show list of BTMs to choose from (e.g. via Shift+F2 or right button part with little arrow like in Win7 open dialog).

[gdpr deleted 6]

But TC wlll be able to show an error if BTM3 is already closed and you're trying to add job to it (using 'F2 Queue: BTM3' button). So you will be sure that job will be added exactly to BTM3.

Hmm, but somehow you would have to remove the "BTM3" entry from the choices given for F2. Otherwise, you might end up with this dialog always showing the names of BTMs long gone. I think you mean the user should not given a choice of "BTM3" in the first place, if "BTM3" is not open anymore, correct? It still might be confusing to the user regarding the numbering of the BTM windows, like @white pointed out...

[white]

The BTM id can change at any given moment as I explained at the bottom of the post I mention above. It's like having an Overwrite all option in the copy dialog which may get enabled automatically at any time, for example at the moment you click the F2 Queue button. Hence why I called it Russian roulette.

But TC will be able to show an error if BTM3 is already closed and you're trying to add job to it (using 'F2 Queue: BTM3' button). So you will be sure that job will be added exactly to BTM3. It would be even nicer to show list of BTMs to choose from (e.g. via Shift+F2 or right button part with little arrow like in Win7 open dialog).

That may work, but the user would still need to be made aware of what options are used when copying using F2 Queue:BTM??. This seems impossible, because TC doesn't know the state of the BTM at the end of the queue. I still think it would be better to use the same options as when copying normally. It shouldn't matter to which BTM a copy operation is added. In this case it's not necessary to change the F2 button.

[MVV]

elgonzo,
Suppose you open copy dialog. It shows you which BTM window will be used, e.g. BTM3, so you expect it to be BTM3. If BTM3 closes before you start operation, TC should show some warning/error and optionally pass job to another BTM (maybe new one with flags from BTM3 - flags may be remembered when copy dialog is displayed).

white,
TC doesn't know exact state at the end of the queue. But you will know which BTM will get your job so it is up to you.

[gdpr deleted 6]

Suppose you open copy dialog. It shows you which BTM window will be used, e.g. BTM3, so you expect it to be BTM3. If BTM3 closes before you start operation, TC should show some warning/error and optionally pass job to another BTM (maybe new one with flags from BTM3 - flags may be remembered when copy dialog is displayed).

i was thinking about was having the BTM's in a list that's being updated in "real-time". But come to think of it, there might be situations were you want to select an item in this list just at the moment when it is being updated. It would be like playing "catch-me" with the list item you want to select. Long story short, i actually like your idea better...

TC doesn't know exact state at the end of the queue. But you will know which BTM will get your job so it is up to you.

Actually handling it like a normal F5 copy is more natural.
Think of having multiple F5 background copy actions running -- each having their own copy options. Now, the BTM should behave exactly the same, except that the copy actions do not run simultaneously but in sequential order. But yes, this would mean to change the way of how copyflags are implemented now in the BTM.

As long as the user could take a look at the BTMs to know their state, your idea might be good enough.

[white]

white,
TC doesn't know exact state at the end of the queue. But you will know which BTM will get your job so it is up to you.

• Assuming that the user knows that the state at the end of the queue is used,
• assuming the user can determine the state at the end of the queue (you need to know the state of the defaults at the time the BTM was started, you need to remember what copyflags lines have been processed and you have to remember all the choices you made perhaps hours ago),
• assuming that the user can decipher copyflags lines,
• assuming the user doesn't make mistakes while deciphering copyflags lines,
• assuming the user doesn't confuse BTM windows,
• even then the user should be warned about the consequences, same as confirmation dialogs before deleting or overwriting files.

If you can assume all that, surely you don't need confirmation dialogs before deleting and overwriting files.

TC doesn't know exact state at the end of the queue. But you will know which BTM will get your job so it is up to you.

Actually handling it like a normal F5 copy is more natural.
Think of having multiple F5 background copy actions running -- each having their own copy options. Now, the BTM should behave exactly the same, except that the copy actions do not run simultaneously but in sequential order. But yes, this would mean to change the way of how copyflags are implemented now in the BTM.

It simply means always sending 1 copyflags line before each operation and always sending all options through the copyflags line (don't use value 32768).

As long as the user could take a look at the BTMs to know their state, your idea might be good enough.

The state being the state at the end of the queue, which shouldn't be confused with the state of the operation currently being processed. I doubt if this can be done without confusing the user.

[nsp]

The state being the state at the end of the queue, which shouldn't be confused with the state of the operation currently being processed. I doubt if this can be done without confusing the user.

I also agree with this specially if you use BTM as a batch processor (even if it was not built for)....
Adding flag description (and decryption).
Adding an intermediate level called Operation with start/end markers inside btm that push/pop all flags is a safer way to manage operation than just resting flag when btm completely ended.
Anytime you add some new operation inside a running BTM, you will add it with enclosing markers and set flag according to the added operation (respecting dialog). You should be able to move without warning complete operation but be warned if you choose to change position of a single line outside of its local operation scope.

This is not a full solution but a good step toward better background operations.

[gdpr deleted 6]

The state being the state at the end of the queue, which shouldn't be confused with the state of the operation currently being processed. I doubt if this can be done without confusing the user.

Feeding an explicit copyflags line always before each operation, as you suggested, makes indeed more sense, and is perhaps also rather easy to implement, i guees.

I think both MVV and myself were thinking about some kind of a visual indicator (say label at the top of the BTM window) which indicate the flags for the next batch to be added, and which BTM will receive items queued by pressing F2. But come to think about it, that approach would still have some disadvantages that might lead to confusion (as you mentioned):
- The user would still need to look at the BTM windows to figure which is active and which options is used.
- Using a label or such to indicate the options active at the end of the queue might be confused by the user with the options active for the currently running job.
- Using no label but an explict copyflags line at the end of the queue as an indicator is not good either, as it might require the user to scroll down the queue list view to see this line.

I agree also about the flag 32768. It's really rather pointless as a "copyflag". (If not, i would have some colossal misunderstanding about that flag.)

[white]

In TC 8.50b7 a new INI file setting "BackgroundCopyFlags" has been added. Discussion about this setting can be found here.