[FIXED] Activating XY when clicking on tabs.

[TheQwerty]

This is driving me nuts today.

I'm working in one program (so XY is not active/focused) and I go to return to XY.

I click on a tab, XY updates to display that tab but is never activated. It doesn't matter if I click on the active tab or not, it won't activate XY.

This is with XP SP2 and XY v6.80.0084.


(Also, am I the only one that finds it rather annoying that if I try to activate XY by clicking the status bar I force an info pane toggle? Could we have the option of having that only happen when the status bar is clicked while XY is active?)

[admin]

Interesting observations! Was not aware of this. Might be hard to tackle. I'll check...

[TheQwerty]

Not that it helps in diagnosing the problem but I was thinking about it and thought perhaps this was related to the problem described in another thread ( http://www.xyplorer.com/xyfc/viewtopic. ... 7479#17479 ).

And maybe they point to a larger problem with the activating of XY, as opposed to just being an issue with the tab bar, or perhaps there's a similarity in the controls.


It might be interesting to run that test from the other thread again and see if anything changes when dropping on controls other than the list, but I just don't have the time/motivation for that now.

[admin]

Not that it helps in diagnosing the problem but I was thinking about it and thought perhaps this was related to the problem described in another thread ( http://www.xyplorer.com/xyfc/viewtopic. ... 7479#17479 ).

No, these things are not related AFAIK. The issue with the tab/window activation comes from the SetCapture call that I need to control the mouse-over effects of the tabs. Apparently SetCapture does prevent window activation -- strange but true. However, I found a way to handle the problem.

[TheQwerty]

No, these things are not related AFAIK. The issue with the tab/window activation comes from the SetCapture call that I need to control the mouse-over effects of the tabs. Apparently SetCapture does prevent window activation -- strange but true. However, I found a way to handle the problem.

Well that's good, but darn! I was kind of hoping they'd be related and reveal a fix for both.

[jacky]

Thread hijacking: Ok this has nothing to do with the issue here, but I just wanted to say this cause I wondered about it :

When XY doesn't have focus, I can click on the TB and it works (mouse hover, clicks, the drawing as well as resulting actions), I can even use right-click, and I can do things that affect List (eg. (un)set a VF, show/hide folders, or even change locations!) without causing for XY to get the focus.

Do you know why, and can you reproduce it ? Cause if so, maybe that could be used, when initiating drag&drop operations, to have XY not to become focused either.

This isn't really a wish, just a curiosity thing, cause over here XY is maximized 100% of the time, and so is almost every other window of every other app, but I was just wondering...

[admin]

Thread hijacking: Ok this has nothing to do with the issue here, but I just wanted to say this cause I wondered about it :

When XY doesn't have focus, I can click on the TB and it works (mouse hover, clicks, the drawing as well as resulting actions), I can even use right-click, and I can do things that affect List (eg. (un)set a VF, show/hide folders, or even change locations!) without causing for XY to get the focus.

Do you know why, and can you reproduce it ? Cause if so, maybe that could be used, when initiating drag&drop operations, to have XY not to become focused either.

This isn't really a wish, just a curiosity thing, cause over here XY is maximized 100% of the time, and so is almost every other window of every other app, but I was just wondering...

I thought about it as well. As I said in the other post, it's the SetCapture call. But drag-n-drop is tricky business. SetCapture + drag-n-drop could be hell. I don't want to get into hell now (or ever).

A right-click menu on a non-foreground XY cannot be cancelled by ESC. These are things that tell me: don't mess around with it.

[jacky]

I thought about it as well. As I said in the other post, it's the SetCapture call. But drag-n-drop is tricky business. SetCapture + drag-n-drop could be hell. I don't want to get into hell now (or ever).

Okay, thanks. Was just curious, I'm personally fine that way it is now anyways. And I sure don't want you to go in hell either!

A right-click menu on a non-foreground XY cannot be cancelled by ESC. These are things that tell me: don't mess around with it.

I usually don't, but either way it's easy to close it : click anywhere else, can be on XY, can be anywhere else. I think it's just a keytrap thing, I can't use Up/Down either then to choose a menuitem...

[TheQwerty]

With 6.80.0085, it's fixed (Good job!), but I'm not sure if it's an ideal fix.

It seems to do the activate after switching tabs and displaying/updating the list, correct?

If so that could still cause problems if you click on a background search tab, as it will change tabs and start the search before activating the window. Fortunately, you're able to activate the window while it is searching but as I said the situation is not ideal.


That said, the fix works fine otherwise, and when you implement search caching this might not be an issue. Maybe you don't need to spend more time on this, but make a note to check it again after caching is in place.

[admin]

With 6.80.0085, it's fixed (Good job!), but I'm not sure if it's an ideal fix.

It seems to do the activate after switching tabs and displaying/updating the list, correct?

Correct. I change this in the next version.

[TheQwerty]

With 6.80.0085, it's fixed (Good job!), but I'm not sure if it's an ideal fix.

It seems to do the activate after switching tabs and displaying/updating the list, correct?

Correct. I change this in the next version.

Much better!

Great job as always, Don!

[admin]

(Also, am I the only one that finds it rather annoying that if I try to activate XY by clicking the status bar I force an info pane toggle? Could we have the option of having that only happen when the status bar is clicked while XY is active?)

No, me too. I did something (it could only done this way): now the click duration (time between MouseDown and MouseUp) must be smaller 500 msec to trigger an info pane toggle.

[TheQwerty]

(Also, am I the only one that finds it rather annoying that if I try to activate XY by clicking the status bar I force an info pane toggle? Could we have the option of having that only happen when the status bar is clicked while XY is active?)

No, me too. I did something (it could only done this way): now the click duration (time between MouseDown and MouseUp) must be smaller 500 msec to trigger an info pane toggle.

ehh.. I'm not so sure that's better.

While it works fine for switching to XY when it is inactive I think more people are going to find it annoying to work with normally.

Is it possible to change that time based on whether XY is active or inactive?
If not, maybe it should become an INI tweak with a default of what it was previously.


Or maybe just leave it as it is and see if anyone complains.

[admin]

Or maybe just leave it as it is and see if anyone complains.

Yep. The whole statusbar clicking business is non-standard stuff -- I might remove it altogether if the complaints come in too heavy...

[John Bee]

Yep. The whole statusbar clicking business is non-standard stuff -- I might remove it altogether if the complaints come in too heavy...

As an option, I hope, cause "I" use it that way ALL the time.

John