Announcement

Collapse
No announcement yet.

Issues with the BC3 window & Active tab

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

  • Aldebaran
    replied
    Hello Craig,

    Thank you for your answers

    From our point of view, the most annoying thing is the fact that the Beyond Compare window doesn't keep the state (minimized for instance) in which is it has been set at a given time when a new new tab is open in background and so the window is then restored. That is the cause of our problem : it is impossible to work on other applications than Beyon Compare when we loads several tens of files.
    Maybe what you are talking about could be a solution for a work-around, even if it does not completely solve the problem of working in BC when loading and then switching to another application.

    The problem with the tabs is also annoying because we loose the order of the files, but is not a waste of time as the above one.

    Thank you for this proposition. We can't wait the next version !

    Best regards,
    Aldťbaran

    Leave a comment:


  • ZoŽ
    replied
    3.3.4 (not 3.3.3, already in testing) should have this improved, though not fully fixed.

    I've changed it so that switching between tabs and closing tabs no longer clears the "launched as a batch" flag. It does reset if you close the most recently opened tab (the bottom one) or if you switch away from BC (since we can't tell whether you're starting a new batch of not). Basically, as long as you're working within BC, it should be much better.

    After playing with it, I do agree with Michael that a command line switch to open tabs in the background would be good. I'm currently thinking a /min switch (opens tab in background, and opens the window minimized if there isn't one already), with a matching /max (maximized) for completeness. That has the additional benefit that it re-adds support for the "Run: Normal/Minimized/Maximized" shortcut property, which we lost in BC3. Unfortunately the changes required for this are large enough that they'd be hard to merge over into the v3 branch, so that probably won't make it in until the next major release.

    Leave a comment:


  • ZoŽ
    replied
    Turn off the "When starting with file comparison, show quick compare dialog" option and it always works in FIFO order, if you leave it alone long enough to get stable. If you launch a number of comparisons they may occur slowly enough that it starts showing those dialogs (possibly multiple), which will affect both activation order and the "grouped from command line" state we're maintaining.

    Leave a comment:


  • Michael Bulgrien
    replied
    Originally posted by Craig View Post
    BC already does FIFO activation.
    That is a matter of interpretation. If I run a batch job to open a bunch of tabs, then select the first tab to begin working with it, closing that tab causes the LAST ONE loaded to open in the editor next. If that isn't LIFO, then I don't know what you call it. I want the next (as in 2nd) tab to open, not the last one loaded.

    Likewise, if I run a script to open 20 tabs from the command line, I want a configurable option that lets me load them to the bottom of the stack (which is truly LILO or FIFO) instead of to the top of the stack where each subsequent tab opens in the GUI replacing each prior one.

    If you are confused about the FIFO/LIFO terminology, just add a tweak that allows tabs to be opened at the bottom of the stack instead of at the top of the stack...which is, perhaps, a better way of defining what the "obvious fix" is.
    Last edited by Michael Bulgrien; 04-Oct-2011, 11:58 PM.

    Leave a comment:


  • ZoŽ
    replied
    Originally posted by Michael Bulgrien View Post
    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.

    Leave a comment:


  • Michael Bulgrien
    replied
    Originally posted by Aaron View Post
    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.

    Leave a comment:


  • Aaron
    replied
    Hello,

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

    Leave a comment:


  • Aldebaran
    replied
    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

    Leave a comment:


  • Chris
    replied
    Sorry, we don't have any news on this topic right now.

    Leave a comment:


  • Aldebaran
    replied
    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

    Leave a comment:


  • Aldebaran
    replied
    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

    Leave a comment:


  • Aldebaran
    replied
    Originally posted by Michael Bulgrien View Post
    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.

    Leave a comment:


  • Michael Bulgrien
    replied
    Originally posted by Aaron View Post
    ...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.

    Leave a comment:


  • Michael Bulgrien
    replied
    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.

    Leave a comment:


  • Aldebaran
    replied
    Hello Aaron,

    Thank you for your answer.

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

    Leave a comment:

Working...
X