XYplorer Beta Club

j_c_hallgren wrote:So if XY doesn't know about tabs for BC, why does each tab's BC show only the parts of hierarchy related to that tab?

Because of the clever way the BC is constructed based on the history.

Ok...fine...but what I consider an issue still remains: Which is...when a different level folder (up or down from current) from an inactive tab BC is used to inject that folder into another tab, why does the source BC end up with the injected folder checked and disabled when the current folder for source tab is still unchanged and at a different level? Sorry if that question was a bit convoluted, but it's best way I can describe it.

For example, in folder structure C:\AAA\BBB\CCC\DDD\EEE, if source tab is at DDD level, and BBB level is injected to destination tab, source tab BC should have DDD checked after inject, but BBB is checked and disabled instead...that is proper for destination tab, but not for source also.

I'm not trying to be obstinant, just that we may have a communication problem, so trying to clarify as much as possible.

j_c_hallgren wrote:For example, in folder structure C:\AAA\BBB\CCC\DDD\EEE, if source tab is at DDD level, and BBB level is injected to destination tab, source tab BC should have DDD checked after inject, but BBB is checked and disabled instead...that is proper for destination tab, but not for source also.

I already said I will change that here: http://www.xyplorer.com/xyfc/viewtopic. ... 0511#10511

Sorry! I interpreted some comments a slightly different way, which led to an incorrect understanding of what would happen...
Hey, even though English is my language, I can still misread it sometimes...especially when the discussion centers more on one point, and my mind is more on the other point...again, apologies, ok?

j_c_hallgren wrote: Sorry! I interpreted some comments a slightly different way, which led to an incorrect understanding of what would happen...
Hey, even though English is my language, I can still misread it sometimes...especially when the discussion centers more on one point, and my mind is more on the other point...again, apologies, ok?

No problem. And does it work now as you think it should work?

admin wrote:And does it work now as you think it should work?

AFAIC it does, thanks!

YES, the handling of checkmarks and such works exactly as I had hoped!

The only minor thing that I still have trouble with is making sure my mouse is on icon and not filename...when I have tip of mouse pointer arrow set exactly on lower right corner of folder icon, I get normal context menu, so placement of cursor is very picky and critical...as stated before, wish there was some minor visual delimeter between icon area and rest... and thus would make icon area maybe just a tad bit bigger.

j_c_hallgren wrote:...when I have tip of mouse pointer arrow set exactly on lower right corner of folder icon, I get normal context menu...

On my system the "hot" area for the mouse appears to be offset by four pixels to the left and up relative to the bottom right corner of the icon. It also effects the tooltip for the tabs, which are also offset, but only by two pixels. Hence, with the mouse two pixels inside a tab the tooltip for the tab to the left is still displayed. Four pixels is the default hot area for double clicking (at least on XP) so this is possibly the reason. I expect it also depends on pointer type and other display related parameters.

It may therefore be a system function rather than anything Donald can change, unless he can define a larger area than the actual icon for the "hot" area.

Gandolf wrote:

j_c_hallgren wrote:...when I have tip of mouse pointer arrow set exactly on lower right corner of folder icon, I get normal context menu...

On my system the "hot" area for the mouse appears to be offset by four pixels to the left and up relative to the bottom right corner of the icon. It also effects the tooltip for the tabs, which are also offset, but only by two pixels. Hence, with the mouse two pixels inside a tab the tooltip for the tab to the left is still displayed. Four pixels is the default hot area for double clicking (at least on XP) so this is possibly the reason. I expect it also depends on pointer type and other display related parameters.

It may therefore be a system function rather than anything Donald can change, unless he can define a larger area than the actual icon for the "hot" area.

Oh yes, you are right! And, of course I can change it: it's my tab control.

BTW, of course I could also make the path parts clickable, but I'm still waiting for a good idea for what todo with truncated/ellipsed parts and with renamed tabs.

j_c_hallgren wrote:..so..maybe could there be a VERY narrow separator between icon and path, so the dividing line would be visible but not in-your-face? Somewhat like exists between column headers? Given that a couple of pixels of mouse pos left or right would cause two quite different results on right-click...

Back on page 2 of this thread, and about a week ago, it seems, I wrote the above when I had suggested using a highlight of icon on hover, which was not accepted...don't recall seeing any real replies to it...so would this solution be possible? ...and acceptable to others?

j_c_hallgren wrote:

j_c_hallgren wrote:..so..maybe could there be a VERY narrow separator between icon and path, so the dividing line would be visible but not in-your-face? Somewhat like exists between column headers? Given that a couple of pixels of mouse pos left or right would cause two quite different results on right-click...

Back on page 2 of this thread, and about a week ago, it seems, I wrote the above when I had suggested using a highlight of icon on hover, which was not accepted...don't recall seeing any real replies to it...so would this solution be possible? ...and acceptable to others?

No, I don't like it. I just fixed mouse-over-tab-headers-calculation, which incredibly was 2 to 4 pixels wrong and only Gandolf's eagle eyes spotted that. You will find that now it's much easier to get the right menu popping up, because now the laws are respected.

admin wrote:I just fixed mouse-over-tab-headers-calculation, which incredibly was 2 to 4 pixels wrong and only Gandolf's eagle eyes spotted that.

with the help of Fatbits - a very good screen magnifier.

admin wrote:Oh yes, you are right! And, of course I can change it: it's my tab control.

So it wasn't a display oddity. It works perfectly now and I should have know better than to imply that you might not be able to change it.

admin wrote:BTW, of course I could also make the path parts clickable, but I'm still waiting for a good idea for what todo with truncated/ellipsed parts and with renamed tabs.

Why don't you do it like Xplorer2 does. So far as I can see, all he has done is to put a narrow panel just above the tabs, which contains the full path of the selected tab. Then you can do the BC via it because you can click on any part of it to go there.

ie. C:\FirstFolder\NextFolder\ThirdFolder etc.

You just click on the text of the folder/drive you want to go to quickly.

Its harder to explain than to do. If VB is like Delphi, you have your listview in a panel, so it would be easy to add that narrow pane above the tab control.

Geez, I don't know whether that helps or confuses, but it would solve the ellipse shortened and renamed tabs. Doing it this way, it wouldn't matter.

John

John Bee wrote:

admin wrote:BTW, of course I could also make the path parts clickable, but I'm still waiting for a good idea for what todo with truncated/ellipsed parts and with renamed tabs.

Why don't you do it like Xplorer2 does. So far as I can see, all he has done is to put a narrow panel just above the tabs, which contains the full path of the selected tab. Then you can do the BC via it because you can click on any part of it to go there.

ie. C:\FirstFolder\NextFolder\ThirdFolder etc.

You just click on the text of the folder/drive you want to go to quickly.

Its harder to explain than to do. If VB is like Delphi, you have your listview in a panel, so it would be easy to add that narrow pane above the tab control.

Geez, I don't know whether that helps or confuses, but it would solve the ellipse shortened and renamed tabs. Doing it this way, it wouldn't matter.

John

That costs space. The other idea was to use the AB (address bar) for it, i.e. toggle AB between edit box mode and clickable mode. It's all on heavy rotation in the back of my mind and one day the solution will come up.

admin wrote:I just fixed mouse-over-tab-headers-calculation, which incredibly was 2 to 4 pixels wrong and only Gandolf's eagle eyes spotted that. You will find that now it's much easier to get the right menu popping up, because now the laws are respected.

Yes, it's a bit easier! But exactly how many 'spacer' pixels are there between icon right edge and left edge of file name? Cause I'd maybe add one pixel, if needed, so the gap can be split in half a bit more so I could be just a hair off the right side of icon and still get BC...

BTW, even though I'm not an AB user, I can see that toggle working as you described...and saving space also!