Issues with the BC3 window & Active tab

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Aldebaran
    Visitor
    • Nov 2009
    • 8

    Issues with the BC3 window & Active tab

    Hello,

    First of all, I would like to say that your software is great ! I use it every day with my colleagues (more than 10 licenses bought).

    We use BC3 as an external diff tool through WinCVS, in particular to see local changes before commiting them onto the server (with text comparison 2-way). We often have several hundreds of files to diff, so we prefer to use the tabs rather than the windows.

    Here are the two issues that we encounter:

    - When we run a diff on several files (>50 for instance) (very often), as this process can take several minutes, we would like to be able to do something else on the computer than waiting for BC3. Unfortunately, this is not possible: when we try to reduce the BC3 Window, each time that a new diff is opened, the BC3 Window is set as active and restored to the screen. It would be better for us that the new tabs be opened without modifying the state of the BC3 Window - so keeping it as not active and minimized.

    - A similar issue happens when we are requesting the diff on many files and that we try working in BC3 while new tabs are opening. We have configured BC3 to open new tabs at the last position. The problem is that the new tabs are not opened in background: each new tab is set as the current one and so it is not possible to work with already opened files. Precisely, this behavior happen as soon as we have changed the first active tab.


    We would be very grateful if someone could help us . Maybe there are some options somewhere which could change these behaviors. Otherwise, we would be happy to see the possibility to configure that in a next BC3 upgrade. Maybe it could be usefull for some other customers.

    Thank you very much for your attention,
    Aldebaran
  • Aaron
    Team Scooter
    • Oct 2007
    • 16026

    #2
    Hello,

    Are you using the latest version of BC3 (3.1.7)?

    Are you using BComp.exe instead of BCompare.exe?
    http://www.scootersoftware.com/suppo...?zz=kb_vcs.php

    Are you closing any tabs before opening all 50 is complete?
    Aaron P Scooter Software

    Comment

    • Aldebaran
      Visitor
      • Nov 2009
      • 8

      #3
      Hello Aaron,

      thank you for your answer.

      Yes, we are using the latest version of BC3.
      We call the BCompare.exe from WinCVS because there is no need to wait the end of the process. However, I have just tried to use the BComp.exe and I can notice the same behaviour.

      During the opening of the 50 files (about one opening each 5 seconds due to network process), the problem happens when we try to select one particular tab: when a new tab is opened, it is set as the current one, and stays active until we select another tab. Yes, sometimes, we can close some tabs, but it is not necessary to close one tab to have this issue.
      About my first point with the window which is (re)set active, there is no need to do particular thing: only open the 50 files and try to reduce the window.

      Thank you for your support,
      Aldebaran

      Comment

      • Aaron
        Team Scooter
        • Oct 2007
        • 16026

        #4
        Hello Aldebaran,

        I talked with our developers about this, and this situation is difficult to detect. If we don't take focus when launching 50 different tabs individually, then we wouldn't take focus if you started another comparison using the shell extension and wanted it to take focus, or other situations where you wanted it to take focus then would not.

        If you need to launch all 50 at once, I recommend letting it finish launching the tabs, and then minimize.
        Aaron P Scooter Software

        Comment

        • Aldebaran
          Visitor
          • Nov 2009
          • 8

          #5
          Hello Aaron,

          Thank you for your answer.

          Originally posted by Aaron
          I talked with our developers about this, and this situation is difficult to detect. If we don't take focus when launching 50 different tabs individually, then we wouldn't take focus if you started another comparison using the shell extension and wanted it to take focus, or other situations where you wanted it to take focus then would not.
          Yes, I understand the problem. However, could it not be possible to take the focus only when the first tab is created and not for the others ? So the application would get the focus for the first tab, and if it had been set to another application by the user, the focus would not be lost.

          Originally posted by Aaron
          If you need to launch all 50 at once, I recommend letting it finish launching the tabs, and then minimize.
          Currently, we are using this solution, but this is wasted time. I have mentioned 50 files, but we often open more than 200 files in your product , so waiting the end of the process takes a looong time.

          Finally, about my second point of my previous message:

          Originally posted by Aldebaran
          During the opening of the 50 files (about one opening each 5 seconds due to network process), the problem happens when we try to select one particular tab: when a new tab is opened, it is set as the current one, and stays active until we select another tab. Yes, sometimes, we can close some tabs, but it is not necessary to close one tab to have this issue.
          Did you succeed to reproduce this problem ? This problem is more serious than the first one because when we are opening 200 files, as soon as the current tab has been closed or that any tab has been selected, each new opened tab will be set as active, so it is not possible to continue working on already opened files. So we need to wait the opening of all the files, which can take up to 20 minutes, some times a day.

          If at least this second point could be fixed, we would be very grateful

          Thanks for your help,
          Aldebaran

          Comment

          • Michael Bulgrien
            Carpal Tunnel
            • Oct 2007
            • 1772

            #6
            Personally, I would like an option (and have expressed it before in a different thread) where BC3 opens subsequent files launched from the command line as new tabs at the right of the tab control, and at the bottom of the windows stack. As tabs are closed, the next tab to become active would be the next one added by the command line process (FIFO) instead of the last one added by the command line process (LIFO). This option could be put on the Tweaks dialog so that those that prefer the LIFO tab order don't get affected by the change. I believe it would also address the issues raised in this thread.
            BC v4.0.7 build 19761
            ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

            Comment

            • Michael Bulgrien
              Carpal Tunnel
              • Oct 2007
              • 1772

              #7
              Originally posted by Aaron
              ...this situation is difficult to detect. If we don't take focus when launching 50 different tabs individually, then we wouldn't take focus if you started another comparison using the shell extension and wanted it to take focus, or other situations where you wanted it to take focus then would not.
              Considering my prior suggestion in light of your feedback, BC3 already has a /solo parm that can be used to launch a stand-alone instance of BC3 if you don't want to lose a paticular session at the bottom of the stack. I would suggest adding a /topmost parameter that could be used to force a session to the top of the stack (thus taking focus). This would allow a user to choose how to open the session, at the bottom of the stack (with suggested tweak in place) or at the top of the stack (with parameter override). BC3 could also leverage the /topmost parameter when opening sessions from the shell extension.

              Another option is to not have a tweak at all, but to provide both a /top and /bottom parameter and let the user specify, in their particular implementation, which end of the stack to place new sessions on simply by their choice of parameter. If the default is topmost, maybe you only need one parameter to put the session at the bottom of the stack.
              Last edited by Michael Bulgrien; 19-Nov-2009, 01:08 PM.
              BC v4.0.7 build 19761
              ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

              Comment

              • Aldebaran
                Visitor
                • Nov 2009
                • 8

                #8
                Originally posted by Michael Bulgrien
                Personally, I would like an option (and have expressed it before in a different thread) where BC3 opens subsequent files launched from the command line as new tabs at the right of the tab control, and at the bottom of the windows stack. As tabs are closed, the next tab to become active would be the next one added by the command line process (FIFO) instead of the last one added by the command line process (LIFO). This option could be put on the Tweaks dialog so that those that prefer the LIFO tab order don't get affected by the change. I believe it would also address the issues raised in this thread.
                yes, exactly . In fact, the behavour you describe is the one we would expect to have "by default" because it is implemented so in any software with dynamic tabs (IE, FireFox...). As you say, when the active tab is closed, the next tab to be activated is the one which was on the right of the previous active tab.

                Comment

                • Aldebaran
                  Visitor
                  • Nov 2009
                  • 8

                  #9
                  Hello Aaron,

                  do you have some good news for us ?
                  We downloaded the latest version, but no change about these points

                  Could you tell us when they could be fixed ? It could also be a new option which could change the behaviour if checked, keeping the current one by default

                  Thanks a lot for your attention,
                  Aldebaran

                  Comment

                  • Aldebaran
                    Visitor
                    • Nov 2009
                    • 8

                    #10
                    Hello,

                    Do you have some news about this topic ?

                    This is a very important point for us and such a little thing to do

                    Regards,
                    Aldebaran

                    Comment

                    • Chris
                      Team Scooter
                      • Oct 2007
                      • 5538

                      #11
                      Sorry, we don't have any news on this topic right now.
                      Chris K Scooter Software

                      Comment

                      • Aldebaran
                        Visitor
                        • Nov 2009
                        • 8

                        #12
                        Hello Chris,

                        It has been two years that these two bug fix/enhancements (the first one about windows, the second one, about tabs) have been requested and we are very frustrating that these issues have not been fixed/implemented yet. These problems happen several times by week for each of us in our company and so represent an important amount of wasted time whereas the solution would need only a short time.

                        Could it be possible to submit these problems to the R&D team in order they can test, reproduce and fix them ? It would be very great for us and for all people that use your product intensively in the same way than our.

                        Thank you for your attention and understanding,
                        Aldebaran

                        Comment

                        • Aaron
                          Team Scooter
                          • Oct 2007
                          • 16026

                          #13
                          Hello,

                          Our lead developer will be investigating this soon. We've reproduced the behavior, but there hasn't been a quick or obvious fix.
                          Aaron P Scooter Software

                          Comment

                          • Michael Bulgrien
                            Carpal Tunnel
                            • Oct 2007
                            • 1772

                            #14
                            Originally posted by Aaron
                            We've reproduced the behavior, but there hasn't been a quick or obvious fix.
                            The obvious fix is to support a configuration for FIFO tab activation instead of always forcing LIFO tab activation as expressed earlier in this thread.
                            BC v4.0.7 build 19761
                            ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

                            Comment

                            • Zoë
                              Team Scooter
                              • Oct 2007
                              • 2666

                              #15
                              Originally posted by Michael Bulgrien
                              The obvious fix is to support a configuration for FIFO tab activation instead of always forcing LIFO tab activation as expressed earlier in this thread.
                              BC already does FIFO activation. The only time it's an issue is if you're switching away or closing tabs while new ones are going in, and for the case Aldebaran mentioned initially (working with other apps while BC is loading), there's no difference between that and repeatedly launching comparisons from Explorer.

                              I can look into changing it so closing a specific tab or switching between tabs no longer clears the "launching multiple comparisons" state, but that's really it.
                              Zoë P Scooter Software

                              Comment

                              Working...