Feature suggestion - Program Files (x86) toggle

[DougalScott]

Could you add a command to toggle the current path between Program Files and Program Files (x86) while maintaining the rest of the folder tree? I often need to switch between the 2 branches when checking x86/x64 installed apps. I know most subfolders only exist under one or the other, but there are some that are in both that I sometimes find myself working with eg Common Files, Office, SQL Server, etc.
Registry Workshop has similiar to allow switch between the HKLM, HKCU and HKLM\SysWOW64 branches at the existing sub node which is very convenient. It implements it by right click context menu to Jump to the alternate location.
I could probably implement via AHK script, but buiult in would be nicer.
Cheers

[nikos]

there's no way for me to do that but you can sort it out with 2 bookmarks for these 2 folders

[namsupo]

Really Nikos, no way at all? Seriously?

[pj]

Really Nikos, no way at all? Seriously?

When I have local and remote folders for a project, I set up dual bookmarks to show each while in dual pane mode. Add the bookmark to the toolbar and see them both simultaneously without switching.

Instead, if you still need to switch, the bookmarks to each can be added to the toolbar, so it's one click to switch.

-----------------------------------
PJ in (it's just TOO HOT) FL

[DougalScott]

Dual bookmark will work fine for switching between the Program Files and Program Files (x86) folders, but not subfolders. When I am in C:\Program Files (x86)\Common Files\microsoft shared\OFFICE14 and want to switch to C:\Program Files\Common Files\microsoft shared\OFFICE14 I have to use bookmark for C:\Program Files, then click back down through the same folder branches.
For now I will knock up an AHK script that will do it for me sometime.
Cheers

[pj]

Dual bookmark will work fine for switching between the Program Files and Program Files (x86) folders, but not subfolders.

Have you also enabled Mirrored Browsing? That *may* keep both panes on equal subfolders. It worked OK in my limited testing on a W7 computer.

[Kilmatead]

For now I will knock up an AHK script that will do it for me sometime.

As I would suspect such a request to be too niche for Nikos to consider for the wider public, scripting is (as usual) the scoundrel's last resort.

I don't expect anyone to use these things, but "just in case" you're bored and "want it now", I made this one just for fun. Source-code (AutoIt) included, of course.

Make the EXE into a user-command and add as toolbar button (or x2's context menu).

If the user command includes the $A token then the selected folder is the target location you want to goto in the "opposite node". If no folder is selected (or you do not use the $A token at all) then the currently browsed folder is the name-target.

As originally envisaged, no token should be used at all, so the folder will simply be whatever the user is currently browsing - this (to me) seems the most stable and predictable of environments, but the option is there if you need something more complex.

Basically, the logic is simple:

• If the object folder is not on either the x86 or x64 programme files path to begin with, then nothing happens.
  
  If the object folder exists in the opposite "node", then the current pane will switch to it (and toggle back if clicked again). Job done.
  
  If the object folder does not exist in the opposite node, the utility offers to create it (including all necessary folders in the path). If you're not running as admin then this will most likely fail, but there would be very little reason for anyone who is not admin to be messing with this sort of thing in the first place.
  
  • If the user selects "Yes", the new folder/path will be created (and switched to).
    
    If the user selects "No", the current address will switch to the "nearest" subfolder. Thus, if you are looking at "...(x86)\Test\Sub1\Sub2" but no "Sub2" exists in the x64 node, then it switches to Sub1 (if existing), or "Test", etc, etc, reductively.
    
    If the user selects "Cancel" then nothing happens.

This can handle any depth of browsed subfolders, obviously.

It also includes all the expected error-trapping, as needed. See source-code for details.

If you're just looking at Program Files itself, it'll just toggle back and forth until you get bored.

Like I said, I don't expect anyone to use this, but it will give you an idea of how such a command could be implemented/extended, instead of just being a mere toggly-thingy.

If you are using a token in the user-command it must be $A. Do not use $F as that one is evil and broken in Nikos' conception. Trust me. Just don't do it. Use either no token at all (recommended) or use $A. Nothing else.

[DougalScott]

I don't expect anyone to use these things, but "just in case" you're bored and "want it now", I made this one just for fun. Source-code (AutoIt) included, of course.

Thanks for the instant gratification Kilmatead.
For bonus points, is there an easy way to add the command to Xplorer2 context menu? I think Menu++ might do it, or maybe X2ResUpdater, but don't want to jump down those rabbit holes unless I have to?
Cheers

[Kilmatead]

...is there an easy way to add the command to Xplorer2 context menu?

The x2 context menu of which I speak is the one you get when you make sure Tools -> Advanced Options -> Global (tab) -> Don't add xplorer2 commands to context menu is unchecked.

See that? That's what we sophistimicated-types [sic] call a double-negative. You see, Nikos intentionally does this just to confuse people, because since x2 has an international audience, for many of whom English may not be their first love, he figures a technical programme coupled with my "posting-style" is not enough to do their heads in - he has to pull out all the stops and phrase many of the options in the negative tense. Which, of course, forces us to describe them in terms of double-negatives, which in turn is guaranteed to make the world a better place for a non-English technical audience. At least in his muddled mind. I always said he was a Muggle. Quod erat demonstrandum: Nikos and sarcasm are just two peas in a pod.

But he loves it. What can you do?

Anyway, this menu-item shows up at the top of the context menu in x2 when you right-click some files and folders, and it acts essentially as a toolbar that you can put any of the regular commands on, plus any user-commands you would make, just as you would a toolbar.

The long-and-short of it is that you click the "Organise" entry on this flyout menu and then hit <Spacebar> (or click the first button in the window's toolbar), then use Category -> Customise, wherein you should find your newly made user-command. Et voilà!

No one ever said this was a great solution, but it's not that bad once you get used to it. At least I think that's true. I'll let you know if I ever get used to it myself, first.

If, on the other hand, you want it "in the main context menu" like any other command, you'll have to use a utility like FileMenuTools which offers a whole world of fun just by itself. That said, it's free, trusted, and a rather useful thing once you figure out how to bend it to your iron will. Worth playing with, at least. You do have an iron will, don't you? In a world where Nikos is in charge of "options", the Good Lord knows we need to be made of tougher-stuff than regular folk.

Or, I could talk you through a simple registry-edit that would add the command to folders' context menus directly, but that's a little extreme unless you really use this kind of script on a daily basis. Your choice. And before you ask, no, there's no way to add it "only to the folders in the program files nodes themselves" - while that would be the best method, it's also the most complex, as it would have to be a shell extension proper.

Edit: Because a toolbar button or CM entry representing this script would be a waste of space if you're not already in your programs folder, it now switches directly to your native Programs folder (instead of showing an error) when it has nothing else to do, just like a bookmark. A small thing, but might be vaguely useful.

[DougalScott]

As usual, a font of knowledge, Kilmatead. I now remember seeing the X2 context menu in passing a while ago, that works, and will be fine for something that won't be used often. I may also be able to use this to replace some ugly registry class shell command scraps I use to get utilities and shortcuts I want, which are nearly always being launched from within X2. Although not sure about the extra menu layer.

I am interested in the registry method - I already tweak the shell command settings for several class types to launch specific apps with context menu, but not sure how that would work with a tool that expects to be launched by X2 - wouldn't the calling program be explorer.exe? Does you tool use the active window, or the top most Xplorer2 window when getting path and switching between nodes?

Thanks for the pointer to FileMenuTools, I will have to give it a look see, I think that will be useful for another problem I have (making WinRAR context menu include Open for other than exe files).

Cheers

[Kilmatead]

I already tweak the shell command settings for several class types to launch specific apps with context menu, but not sure how that would work with a tool that expects to be launched by X2 - wouldn't the calling program be explorer.exe?

If you already tweak shell commands on filetypes, then I wouldn't have anything to add to your knowledge - HKCU\Software\Classes\Directory\shell\Command and Icon entries should be old hat to you.

The "calling programme" is just the script itself - the shell is fairly agnostic when it comes to static context menu entry invocation, and we can conveniently exploit this. Thus, our programme just looks for the window handle to the "last active x2 instance" (in case there's more than one extant) - if it can't find one, then it just exits. Not very elegant but from your other thread, you can appreciate the painfulness of trying to launch a new x2 process "cold" without %X2DIR% being available. In this case, as long as x2 is already running (it doesn't even have to be the active process), it'll be invoked when needed.

Anyway, if the script finds a handle it likes then it just checks if the address-bar is visible, and reads that to get the current path if a "target" is not explicitly provided. While this method is not completely chipmunk-proof (there are ways to spoof anything if you try hard enough), for 99% of circumstances it's kosher enough for this, though it does expect x2 to be at least running - else why else would we be here?

If the target is derived from a selected object (such as from the context menu) then it will happily take objects even from scrap-containers too, and influence the x2 instance proper when switching.

It could be expanded to sense whether it's being invoked from WinExplorer or x2 and behave the same for both (i.e., not actually requiring x2), but that's a stretch of an evening.

making WinRAR context menu include Open for other than exe files

Doesn't anyone use the WinRAR options themselves? It's got ridiculously extensive (read: "too many") options for managing its own context menu entries built in. Unless, of course, you don't use WinRAR as the associated archive programme... that might cause weirdness... in any event FileMenuTools can do an entertaining number of things with context menus, once you get rid of its own "built-in" clutter.

As usual, a font of knowledge..."

I do so love the pleasant linguistic distractions in minutia which pop up from time to time...

[DougalScott]

Doesn't anyone use the WinRAR options themselves? It's got ridiculously extensive (read: "too many") options for managing its own context menu entries built in. Unless, of course, you don't use WinRAR as the associated archive programme... that might cause weirdness... in any event FileMenuTools can do an entertaining number of things with context menus, once you get rid of its own "built-in" clutter.

I am trying 7zNSE on Nikos' recommendation. However that means that the various archive and associated formats now open in the 7z folder extension by default. 7z always provides an Open archive menu choice regardless of the extension (which can be help and hindrance) - but WinRAR tries to be smart and only offers same for exe extensions, rar can only be opened using the default Open menu which has been taken by 7zNSE.

Maybe FileMenuTools can add an Open in WinRAR option to the WinRAR context menu for me, so I can use 7zNSE normally, but still have easy access to open in WinRAR. Adding an Edit command for SevenZipFolder class to my growing file association script works for now, but that is getting cumbersome to keep track of my association changes.

Font implies a still body from which wisdom can be sought.
Fount suggests knowledge spewing forth.
Do you think Oxford have a point?

[Kilmatead]

7z always provides an Open archive menu choice regardless of the extension (which can be help and hindrance) - but WinRAR tries to be smart and only offers same for exe extensions, rar can only be opened using the default Open menu which has been taken by 7zNSE.

7zNSE does not interfere with the items from the WinRAR shell context menu integration (nor, indeed, those of any other archive handler that I have tested with it).

Though it is true the default "Open" verb redirects to explorer browsing, that does not preclude WinRAR adding its own menu items (configurable under "Settings -> Integration -> Context Menu Items") to even filetypes currently associated with 7zNSE.

For example, the entries below are generated by WinRAR, though 7zNSE is the actual associate (hence the modified listview icon):



It should be remembered that 7Zip itself need not be installed alongside 7zNSE - it's not necessary unless you use it to create wonky archive types. WinRAR is more than capable of handling everything else, if that's your handler of choice, and 7zNSE itself is "self-contained".

As a method of last resort, you can always just click an archive with the "Open With..." menu item, and manually select the WinRAR executable, afterwhich it will always be available in that submenu. However, this should not be necessary (as noted above).

Font implies a still body from which wisdom can be sought.

Exactly, I am not a still body. I do manual labour for a living, my good man. "Real" work. Not that white-collar criminal stuff the other folk round here like Nikos do. Real honest-to-God spine-damaging kneecap-crunching head-cracking work. Just like the medieval kids did back when the world was a proper place. And I will no doubt die younger and in greater pain and with fewer teeth than others for it, but such is the grace of life (and a paid-for-yet-valiantly-spurned university education).

Fount suggests knowledge spewing forth.

While it would be argued by my lesser-admirers that I oft "spew" all sorts of nonsense (such as the preceding paragraph attests), even I myself would doubt the verisimilitude of any of it being classed intrinsically as "knowledge". On this side of the hemispherical dividing line, we just call it "waffling". (That others seem to find such effluence useful is a continuous source of amusement to me.)

[DougalScott]

That's odd, my WinRAR context menu doesn't include Open with WinRAR normally:

Screenshot - 24_06_2015 , 18_11_03.png

The Open in WinRar option is only there because I added it to the sevenzipfile class myself:

Screenshot - 24_06_2015 , 18_07_16.png

Without that extra shell handler I only get the Open with WinRAR menu choice on exe files types normally. I am using WinRAR 5.10 x64, maybe previous versions had extra menu option?

Using Open with and choosing WinRAR only works for rar types, not the various other odd formats that are also rar types, or it blocks the proper associated program. I often have to create specific formats for people who do not have all the available tools, so helpful to be able to open and edit in the native tool.

Maybe there is an option somewhere in WinRAR that hides the Open with from the main WinRAR context menu, will have to check, but I have all options I am aware of already checked:

Screenshot - 24_06_2015 , 18_19_12.png

Apart from the wealth of useful X2 information you provide, there is never any shortage of entertainment value also.

[Kilmatead]

Without that extra shell handler I only get the Open with WinRAR menu choice on exe files types normally. I am using WinRAR 5.10 x64, maybe previous versions had extra menu option?

For completeness, it should be noted that the current version of WinRAR is 5.21, though I don't believe the Context Menu integration has changed in aeons. You can always just run the installer again (it's safe to install over itself, plus it will conveniently leave any filetypes already associated with 7zNSE unchecked so they're not over-written). This might jiggle your context menu jangles back into their proper juggling order, having perhaps been corrupted along the line in daily use previously.

The "Open with WinRAR" item is submarked as being for "SFX archives" (meaning "self-extracting") - but ticking it gives me the appropriate entry on any type (including non-SFX), so I'm not one to argue with it.

All I can say is that if I were to have all those options checked (as in your screenshot above) I would end up with about a million things in the context menu, on all archive types, including all those currently handled by 7zNSE.



The trick with the "Open With..." on the filetype is when you select WinRAR you make sure the "Always use this programme to open" thing is unchecked. That will prevent WinRAR (or any other programme) from stealing the association, yet the WinRAR menu entry will forever remain in the popup menu, free from harm and taxation without representation. Again though, in this case, it shouldn't be necessary.

If you want to stick with your current homemade method (there's nothing wrong with it since it works), you might try adding a REG_SZ "Icon" value within your open_winrar key (and giving it the path to the binary), just so you get the icon in the menu (which helps make it look that much more special - like icing on a doughnut).

As you say your "additions" are getting a bit unwieldy to remember, you'll find that FileMenuTools can clean up a lot of that - for example, you can define a range of filetypes (and only those filetypes) for which certain commands will be displayed in the menu, which keeps things tidy (including "separators"). You can also hide commands (from other programmes) which you never use, which may not be static entries and thus resistant to your registry-wooing methods.

And (off topic) I notice you are a fellow Beyond Compare devotee - have you tried my one-click compare utility I made for it to specifically blend in with a dual-pane manager? It takes a bit of getting used to, but becomes second-nature once you figure it out. That said, based on page-views it's my least-popular project, but I use it daily, and there's always someone to love a lost and lonely puppy. Just a thought. And note that the current beta version of BC 4.1 is now natively x64 (yay!), which was long overdue. (Embarcadero finally got their act together and released x64 compilers for Delphi users, which breathes new life into projects which otherwise might have gone astray.)

And yes, Nikos, you'd be surprised at how many Delphi things are still in development! Not everyone jumped ship.