XYplorer Beta Club

So... I am not currently a customer. Since I was forced to "upgrade" to Win7, I've been using Explorer++, because I liked that it was F/OSS. But it's got some major blocking bugs, and I don't like that its sole active developer, kinda... isn't anymore. So I've been looking around at alternatives recently, even paid ones. Although in general I feel like xyplorer's menus are a little bit cluttered, it certainly does have a lot fewer necessary components of a file manager half-implemented (like search, and file undo/redo) compared to e++, and a bunch more neat-but-not-required features that actually seem useful. It does bug me that there seem to be issues with TortoiseSVN's context menu shell integration (probably resulting from the x64 issue I saw mentioned in the faq), that you can't hide the tab bar when only one tab is present but have it available when you create second one (like Firefox and most other programs that support tabs-in-windows), and that there don't seem to be any ways of removing annoying keyboard shortcuts you don't want (like alt-up hiding the menu) if you don't buy the full version (and I'm guessing there isn't any way to disable double-clicking traversing up a directory even if you buy the full version?), but in general, this does seem pretty feature-complete and bug-free.

There's one issue, though, that drives me crazy on a daily basis with e++, that you also have, as does pretty much every other replacement file manager. It wouldn't surprise me if there just wasn't a solution, if MS doesn't want you to know how to fix it, but if you did figure out how to fix it, I just might switch immediately. This is the issue:

If you open Visual Studio (2008 or 2010; probably other versions too, but those are the ones I use at work), have xyplorer set as the default file manager, and then right-click an open file in VS and "Open the containing file", the folder is opened in xyplorer, but unlike if Explorer is the default file manager, it doesn't scroll to the file. Additionally, for about 20 seconds or so, VS just acts weirdly: in 2008, the "open the containing file" command is greyed out; in 2010, all keyboard use is disabled, and when it's done behaving weirdly, it lets you know by popping up a messagebox stating "unable to open the folder. It might have been deleted or existing permissions might be unsufficient."

Figure out why it does that, and you just might have a customer. :p

Durp. I just noticed, yes there is a way to disable the double-clicking blank space function, and you can shrink the UI a bit (it's still not quite as pretty as e++, but it's a lot closer.) And I know an x64 build is scheduled. So fix this and you totally have a customer.

(Though I still would also like to have the tab bar visible in a window when that window contains two or more tabs, and hidden otherwise.)

Run the attachment will correct this problem.

neminem wrote:It does bug me that there seem to be issues with TortoiseSVN's context menu shell integration (probably resulting from the x64 issue I saw mentioned in the faq)

As long as both the 32 and 64 bit shell extensions are installed there shouldn't be problems. I use TortoiseCVS just fine in XY on Windows 7 x64.

neminem wrote:you can't hide the tab bar when only one tab is present but have it available when you create second one (like Firefox and most other programs that support tabs-in-windows)

If you can create a habit of opening and closing all your tabs via scripts (shortcut keys, toolbar buttons, and catalog) then it would be possible to do this. Understandably that's a bit of a hack.

It shouldn't be difficult for Don to implement this if you can make the compelling argument and convince him.

neminem wrote:there don't seem to be any ways of removing annoying keyboard shortcuts you don't want (like alt-up hiding the menu) if you don't buy the full version

Indeed that is a perk of the Pro version. Of course if you don't mind the time and effort you can get around this with something like AutoHotkey. (sorry Don!)

neminem wrote:any way to disable double-clicking traversing up a directory even if you buy the full version?

Tools > Configuration > Jump to Setting...
Filter by and select "Dbl-click on empty space goes up (Extended - Mouse)"
or
Tools > Configuration > Extended > Mouse > Dbl-click on empty space goes up

Unchecking that option will disable the behavior. Alternately there is an INI-tweak to change the behavior to mimic the back in history button.

Sadly... the original point of this thread, the VS issue: I ran your registry edit, shalongbus, and it didn't seem to change the behavior specified in any way...

EDIT: Then again, it looks like it's supposed to, among other things, edit the contents of "HKEY_CLASSES_ROOT\Folder\shell\explore\command" to contain hex of some flavor? After running it, that key still just has the default value "%SystemRoot%\Explorer.exe /e,/idlist,%I,%L", and no other values. Possibly that would be why? (I know a bit about HKCR, but not a large amount.)
Edit 2: nope, that was actually what it was supposed to do, it was just encoded cause it's unicode. Silly Windows.

TheQwerty wrote:If you can create a habit of opening and closing all your tabs via scripts (shortcut keys, toolbar buttons, and catalog) then it would be possible to do this. Understandably that's a bit of a hack.

It shouldn't be difficult for Don to implement this if you can make the compelling argument and convince him.

The argument is: there are people like me, who normally only have one tab open, and having the tab bar open most of the time is nothing but a distraction and a waste of screen real estate. But occasionally I do have a reason to open multiple tabs in a window, and it would thus obviously be useful to show them, and it would be nice to do that automatically. Plus, most other things with tabbed interfaces (like, say, every browser ever) have that option. (And I always turn it on. :p)

I never open/close tabs with anything other than ctrl-t/ctrl-w or occasionally the context menu item on a folder, though, so if you could script that, it'd presumably be easy enough to assign a script to that.

Though, on that note, I just checked, and I don't see a "open in new tab" item in folders' context menus? Is there one somewhere I'm missing, and/or in the full version can you add script items to context menus?

TheQwerty wrote:

neminem wrote:there don't seem to be any ways of removing annoying keyboard shortcuts you don't want (like alt-up hiding the menu) if you don't buy the full version

Indeed that is a perk of the Pro version. Of course if you don't mind the time and effort you can get around this with something like AutoHotkey. (sorry Don!)

Yeah, I got that - just seems a bit silly that there would be new, potentially unwanted (because they're different from Explorer) shortcuts added that you can't remove without paying more. Seems different from the ability to add new shortcuts yourself somehow. If I do decide to buy, I'd probably take advantage of that deal next week and buy the pro version anyway, though.

I do know AutoHotkey, though, that was my first thought - I experimented with it to fix some things I hated about Win7's native Explorer, before eventually just giving up and looking to alternatives. (I do still use it at home to remap some keys on my laptop keyboard.)

And yeah, I figured out the option to disable the double-clicking thing. Thanks for the help!

neminem wrote:The argument is: there are people like me, who normally only have one tab open, and having the tab bar open most of the time is nothing but a distraction and a waste of screen real estate.

So do you then put "Search results" in same tab? That, for me, causes a minimum of two tabs open because I need a working tab and a search results tab to best function efficiently.

But occasionally I do have a reason to open multiple tabs in a window, and it would thus obviously be useful to show them, and it would be nice to do that automatically.

I tend to max out at about 4 tabs per pane myself...I use dual single-pane mode so that I have either tab set 1 or 2 which gives me effect of 6-8 tabs but separated into two groups.

j_c_hallgren wrote:So do you then put "Search results" in same tab? That, for me, causes a minimum of two tabs open because I need a working tab and a search results tab to best function efficiently.

So... I'm having a hard time imagining a situation where I'd need search results open all the time. Usually when I'm searching for something, I search for it, I find it, then I close the search window. I also bought a third-party search program a while ago, cause Win7's search blows even more than the rest of its UI, and the search in the freeware I replaced explorer with was even worse still. I do kinda miss having the ability to open a search pane in-place as opposed to launching a new window, but I don't think I'd want it to open in a tab, anyway.

(And at this point I'm not giving up my dedicated awesome search program I paid for anyway, so moot point there. Explorer++ being open source, I just linked my copy's F3 directly to that other search program right in the source... but presumably I could accomplish the same thing in xyplorer with a script associated to F3.)

I like having multiple windows open, grouped by reason. So, if I have a window open for moving files between a handful of places, I'll have them all open in one window as tabs, but if I have an unrelated window open for editing other unrelated files, I'll just open a new window for them, and alt-tab between them.

I'm not sure I could get used to the dual-pane thing. Though I'll probably try it out for a bit once I have it, too - I didn't think I'd get used to having tabs in my file browser, either, until I had that ability the first time.

EDIT: And good to know about tortoise. I would have assumed it'd get confused having both shell extensions installed at once; glad to hear otherwise. That's fine then.

neminem wrote:I never open/close tabs with anything other than ctrl-t/ctrl-w or occasionally the context menu item on a folder, though, so if you could script that, it'd presumably be easy enough to assign a script to that.

One thing I completely neglected to mention is Scripting is yet another good reason to go Pro.

So indeed a smarter tab bar in the Home edition requires Don to add it. I'll second the request that it would be nice to have an option to only show the tab bar if either visible pane contains more than 1 tab.

neminem wrote:Though, on that note, I just checked, and I don't see a "open in new tab" item in folders' context menus? Is there one somewhere I'm missing, and/or in the full version can you add script items to context menus?

Enable Configuration > Extended > Context Menus > Custom items in shell context menu.
Then you can enable the specific items you want by clicking Folder Tree... and File List...


Sorry that none of this has actually helped the topic of the thread though.

TheQwerty wrote:

neminem wrote:Though, on that note, I just checked, and I don't see a "open in new tab" item in folders' context menus? Is there one somewhere I'm missing, and/or in the full version can you add script items to context menus?

Enable Configuration > Extended > Context Menus > Custom items in shell context menu.
Then you can enable the specific items you want by clicking Folder Tree... and File List...

Perfect! Not only the answer to that question, also the answer to a question I hadn't bothered asking, because it was only bugging me a little bit, which was how to get rid of various other options in that context menu that would just be distracting.

I do look forward to either shalongbus or this mythical Donald person getting back about the original reason for this thread, though, yes. Preferably before the 5th of next month.

neminem wrote:Figure out why it does that, and you just might have a customer. :p

You will be faster figuring out convincing other reasons to become a customer anyway.

I think Visual Studio is trying to use DDE to accomplish this, but that's beyond me.

Don, does XY listen for DDE messages?

TheQwerty wrote:I think Visual Studio is trying to use DDE to accomplish this, but that's beyond me.

Don, does XY listen for DDE messages?

Nope.

From the looks of it I think you'd be better off creating an add-in or macro for Visual Studio to open XYplorer.

The hardest part of that is training yourself to not use the built-in "Open" items.

Well dang. I suppose that would explain why it doesn't work, then. (And probably also why e++ doesn't work, if e++ presumably also just isn't listening.) I did look up what the hex meant, and turns out reg files just encode that particular type of unicode key as hex, and it was supposed to look just like what it did.

Yes, there are other reasons I would want to switch over from e++ to this (working undo/redo, or just the fact that it's actively being maintained at the moment), but this was the one huge annoyance. Lack of undo/redo annoyed me maybe a couple times a week; this annoys me several times a day. :p

I'll probably take advantage of that sale next week anyway, though, in the hopes that maybe this will be looked at eventually? (And I would then get the fix for free. Neat sales model, incidentally.)

And hm. That is probably not a bad idea, actually, Qwerty. I don't know anything about VS extensions, but I know that it's possible for an extension to add a new item to a tab's context menu, which presumably would also give it access to that item's path and name. And indeed, I just tried: the command-line arg does let you specify a file as well as a folder, nifty. Yeah, probably the best way.

Now I'm curious whether shalongbus actually tried his fix and it worked for him, though, if, as it sounds like, there's no reason it should have. :p

edit: Yep, that totally worked. Bit of a hack, but perfectly fine for my use, given I generally am just coding on a couple computers ever, so I could just give them the one macro and never change it. (Turns out VS lets you just edit the context menu manually, for instance, to add a macro to it that calls a program and gives that program an argument. )

The behaviour that neminem mentioned is easily reproducible. It may be a bug

I have noticed that XYplorer does not handle the standard target command that any Windows program may send to the installed file manager. If you install the shell utility "Target Context Menu" (available below) and you right click any shortcut (lnk); on the context menu select "Open Containing Folder". In Windows Explorer this opens the folder, and highlights the actual file. This is the default Windows method of handling the data sent by that command. This command is used in various Windows apps, including the aforementioned Visual Studio.

Here is the basic Target Context Menu shell utility it works with WinXP and Vista32 The DLL may be decompiled and inspected for clues. https://skydrive.live.com/redir?resid=8 ... 9VBMqHXb8A

In XYplorer, the folder only is opened, and the remaining data is truncated or ignored. I hope this provides a clue as to why. Having the ability to target a specific file is very useful for IT managers, or web designers or software developers. Some folders may have thousands of files in them, and this is an old and basic Windows GUI command.



XYplorer is the best, no-contest, file manager there is... I do have a wishlist, but that is for another time.