Announcement

Collapse
No announcement yet.

24545 Picture Compare Next/Previous Difference Files can close tab

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 24545 Picture Compare Next/Previous Difference Files can close tab

    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.
    Last edited by chrisjj; 03-Jan-2020, 02:12 PM.

  • #2
    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.
    Aaron P Scooter Software

    Comment


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

      Comment


      • #4
        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?
        Aaron P Scooter Software

        Comment


        • #5
          Originally posted by Aaron View Post
          Is it hitting an archive on either side?
          No. Report edited to clarify.

          Originally posted by Aaron View Post
          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?

          Comment


          • #6
            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.
            Aaron P Scooter Software

            Comment


            • #7
              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.

              Comment


              • #8
                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.
                Aaron P Scooter Software

                Comment


                • #9
                  Originally posted by Aaron View Post
                  Sorry, not sure I follow. What I'm seeing is not a painting interruption.
                  OK, sorry, my mistake.

                  Originally posted by Aaron View Post
                  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.

                  Originally posted by Aaron View Post
                  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.)"
                  Originally posted by Aaron View Post
                  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.

                  Originally posted by Aaron View Post
                  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.

                  Originally posted by Aaron View Post
                  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.

                  Originally posted by Aaron View Post
                  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.

                  Comment


                  • #10
                    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.
                    Aaron P Scooter Software

                    Comment


                    • #11
                      Originally posted by Aaron View Post
                      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.

                      Originally posted by Aaron View Post
                      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

                      Originally posted by Aaron View Post
                      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.

                      Originally posted by Aaron View Post
                      Next Difference File command, which cancels the current load
                      There's your problem.

                      Originally posted by Aaron View Post
                      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.

                      Comment


                      • #12
                        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.
                        Aaron P Scooter Software

                        Comment


                        • #13
                          Originally posted by Aaron View Post
                          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.

                          Originally posted by Aaron View Post
                          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.

                          Originally posted by Aaron View Post
                          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.

                          Comment

                          Working...
                          X