24545 Picture Compare Next/Previous Difference Files can close tab

[chrisjj]

1 In Folder Compare compare two folders of 300 .JPGs (and no other files) with each pair non-matching
2 Double-click the first pair to open the Picture Compare
3 Press and hold CTRL+M - Next Difference Files

Expected: PC tab goes to next file pair repeatedly until end of list , whereupon ctab closes
Observed: PC tab goes to next file pair between a dozen and a few dozen times, whereupon tab closes despite not at end of list.

Note: Once all pairs have been compared, the expected behaviour is observed.

Windows 7.

[Aaron]

When launched from a parent Folder Compare into a child File view/session, the Next Difference Files command is available and allows the user to go to the next different file within the same subfolder as the original child view was launched from. It will close the tab and revert to the main view if it hits the last file in the current subfolder (or the last file in the base folder level if acting on there). It's a little bit of a learning curve, but it is how the command has always functioned since at least BC2.

[chrisjj]

Thanks but note my " tab closes despite not at end of list."

[Aaron]

Is it hitting an archive on either side? This would also cause it to return to the folder view to deal with the archive file (in Treat as Folder, or Treat as Folder if Expanded modes). When it stops and bounces back, what file is selected, and is it an archive or a non-image file?

[chrisjj]

Is it hitting an archive on either side?

No. Report edited to clarify.

When it stops and bounces back, what file is selected, and is it an archive or a non-image file?

A pair of .JPGs is selected. There is no other type of file in the folders.

Have you been unable to reproduce this?

[Aaron]

No, but I am seeing another odd behavior, where holding the button doesn't populate the center column, perhaps because the comparison isn't fully loading before going to the next file pair. This command can be executed and interrupt the current load, just like you can decide to close a tab while it is loading.

There may be other timing issues in play if you are holding the key down, which isn't the intended use, as it is expected to let the comparison load if it was requested to load next. I'll open a tracker entry to investigate, but this is an edge case to tell the program to Load but Discard before Loading as quickly as possible.

[chrisjj]

Doesn't populate could be due to WM_PAINT interruption.

> if you are holding the key down, which isn't the intended use

What's unintended about it? It is simply operating the program fast. If the program has a speed limit, that ought to be enforced. What we have at the moment fast operation yielding incorrect final results.

[Aaron]

Sorry, not sure I follow. What I'm seeing is not a painting interruption. For a simpler example, if you were opening a several hundred meg file pair which takes a long time to load, you can cancel this load by closing the current tab. You could also cancel the load by executing this command to go to the Next Difference File instead. If the user gives the command, BC4 will stop the current load; holding down the key will be faster than a file comparison can load depending on the size of the comparison. By holding down the key, you are telling the program to cancel the load and move on before it can finish, and only if the comparison is very fast is it able to complete anyway.

In order to allow Next Difference File to "go really fast" like you describe, what should the program do? Would we have to lock you into the current comparison and prevent you from leaving, even if you execute the command to leave and go to the next file? This is something we could consider, but I'm not sure it's desirable behavior. Since the comparison itself takes time to load, holding down the key would then go much slower, since the comparison has to finish in order to fully build and have comparison results before moving onto the next pair.

[chrisjj]

Sorry, not sure I follow. What I'm seeing is not a painting interruption.

OK, sorry, my mistake.

You could also cancel the load by executing this command to go to the Next Difference File instead.

That's complete news to me ... and to the documentation.

By holding down the key, you are telling the program to cancel the load and move on before it can finish

Actually I am not. I'm By holding down the Next Difference File key I'm telling it to do Next Difference File:

Opens the parent folder session's next pair of files with differences. (Child sessions only.)"

In order to allow Next Difference File to "go really fast" like you describe, what should the program do?

When it finishes the current work, execute the command.

Would we have to lock you into the current comparison and prevent you from leaving

If I want to leave, I can leave. By e.g. closing the tab.

even if you execute the command to leave and go to the next file?

There's no such command. The command in question is supposed to not leave - until then end.

Since the comparison itself takes time to load, holding down the key would then go much slower

Yes doing the work requested takes longer than not doing it. I think that's obvious and acceptable to most users.

But regardless, at the moment the sequence is exiting before list end, whereas it is supposed to continue to list end.

[Aaron]

I suspect not traveling to the list end is a timing issue. I haven't seen this behavior yet, but I'm sure there are some hardware or file list combination that could cause it if the key is held.

The rest of my description is why holding the key is not expected or intended behavior. BC4's content comparison column is behaving as expected, however: go to Next Difference File can cancel the current load and instead load the next file. As my example above, if your file were exceptionally large, BC4's file view could be loading it for lets say a couple of minutes. A user might decide they've waited long enough (or, in other file views, read enough of what has partially loaded) and want to go to Next Difference File. They can then execute the Next Difference File command, which cancels the current load and goes to the Next Difference File. As a cancelled load, it doesn't have a comparison status, so no final comparison status can be assigned to the middle content comparison column in the parent Folder view, as the rules-based scan didn't complete.

BC4 is capable of running some scans very fast, so even if you hold the button, we'll sometimes be able to complete the scan before the user input is received, but by holding the key you are attempting to race against this. As I mention, we could consider "locking" until the load completes to prevent this case, but that would also lock in cases when dealing with large files or over slow connections: the rules-based scan during the file load has to complete to show the results.

For not traversing to the end of the list, it is something we can look into, but isn't a high priority fix.

[chrisjj]

I haven't seen this behavior yet, but I'm sure there are some hardware or file list combination that could cause it if the key is held.

Great. Please confirm my report has been passed to the devs.

The rest of my description is why holding the key is not expected or intended behavior.

Holding a key is not program behaviour. It is user behaviour. If you mean your description shows this is not expected or intended by the program, then I disagree. It doesn't. It simply

BC4's content comparison column is behaving as expected, however: go to Next Difference File can cancel the current load and instead load the next file.

I see no basis for this cancel being expected behaviour. Nothing in the UI or docs suggests it.

Next Difference File command, which cancels the current load

There's your problem.

BC4 is capable of running some scans very fast, so even if you hold the button, we'll sometimes be able to complete the scan before the user input is received, but by holding the key you are attempting to race against this.

Incorrect. By holding the current key I am expecting the command to reexecute upon each completion. I am not expecting it to cancel a random selection of the executions, giving wrong results in the Comparison column - but that's what it does.

[Aaron]

It doesn't give the wrong results, it is a shortcut to close the current comparison and load a new comparison into it. If you tell the program to load Next Different Files into the current window without giving it time to complete that load, then the cancelled results are incomplete and do not populate the result column.

I'll open a tracker entry to investigate the initial issue reported that it unexpectedly stops and doesn't go to the end of the current subfolder without hitting an archive.

[chrisjj]

It doesn't give the wrong results, it is a shortcut to close the current comparison and load a new comparison into it

Not according to the documentation. Nor with common sense. If I ask for two Next Difference Files result, I expect two - not the one I'm getting.

If you tell the program to load Next Different Files into the current window without giving it time to complete that load, then the cancelled results are incomplete and do not populate the result column.

Yup. Needs fixing.

I'll open a tracker entry to investigate the initial issue reported that it unexpectedly stops and doesn't go to the end of the current subfolder without hitting an archive.

Thanks.