Visual Studio -> Open Containing Folder (and other stuff...)

[admin]

Hi and welcome,

XY only processes the command line. No DDE messages.

Don

[KieSeyHow]

Hi and welcome,

XY only processes the command line. No DDE messages.

Don

Thank you

I cannot make it clear to you how much I admire your coding skills and all the incredible features you have managed to get into XYplorer. It is similar to going into a hardware store for a simple tool, but when you get there you find all these amazing other tools. You have to learn their use, and keep rediscovering them when you go to grab something from your toolbox and you go "AHA! I can use that for this task. I could not even do this before because I had no idea this tool existed!"


So, I am wondering, is it possible for a future release of XYplorer to handle DDE? *looks hopeful*

[admin]

Hardly. That DDE is used for this "Open Containing Folder" is only a theory (I have no other). But on the other hand, DDE smells deader than a dodo to me. Not a fascinating thing to support.

[KieSeyHow]

Hardly. That DDE is used for this "Open Containing Folder" is only a theory (I have no other). But on the other hand, DDE smells deader than a dodo to me. Not a fascinating thing to support.

It seems to me, that many of the really useful GUI advancements that Microsoft makes they forget, or leave out because of moronic middle managers who constantly try to reinvent the wheel instead of building upon a solid idea base.

Windows 7 removed some really excellent ideas implemented in the Windows GUI, and Windows 8 is just pathetic.

[Filehero]

..., and Windows 8 is just pathetic.

<OT>
Nope, it's not - at least for the so-called "poweruser".

The Desktop is still the Desktop (whatever it was and is good for...), and with Win 8 Pro you additionally get
- storage spaces
- File History
- much better Task Manager
- native Iso Mounting
- Hyper-V supervisor inbuild
- much better Repair and Recovery
- much better Windows Defender

Yes, on the negative side there's
- no more Aero Glass - I always wondered why "powerusers" were fond of that (though I think it was aesthetically pleasing)
- no more visible start button
- no more classical start menu
- no more desktop gadgets (they always were performance hogs and security flaws anyhow - someone remember Active Desktop?)
- no more inbuild Media Center and DVD-Player (was a free update until 31st Jan 2013, however)
- some (all?) inbuild Games have been removed (never cared for...)

After have been running Win 8 Pro for 9 months now, I think it's the right step. But the step might has been too huge, especially on the the visual side, though. But for those thinking that pressing the Windows-key to get to the desktop after boot is too much to ask for, installation of something like Pokki make these annoyances cured as well.

Don't get me wrong, with the release of Windows 8 Microsoft has been challenging even their most loyal customers quite hard. But with a little patience and willingness to "experience" the changes, Win 8 is an improvement - after resurrecting my last Win 7 partition for one week, at least to me.
</OT>

Welcome to XY.


Cheers,
Filehero

[neminem]

Wow. I can't believe it's been a year since I switched to xyp (during which time e++ still hasn't come back from its seemingly-permanent hiatus). Anyway, I'm bumping this thread because VS2012, sadly, apparently dropped support for macros. We just switched to 2012 here - in a lot of ways, VS2012 seems better than 2010, but I'd been using a macro as a workaround for this issue, and now that workaround is no longer available, so this is going back to driving me crazy.

If DDE is really "deader than a dodo", then why would VS2012 still be using it to open folders when you ask it to? This really is going to drive me completely insane, that every time I want to open the containing folder from VS, I'm going to have to manually find the file I wanted, and then wait several seconds for VS to become responsive again (and then close a meaningless dialog telling me there was an error.)

[TheQwerty]

That it was using DDE was only ever a guess.

Over at DOpus they investigated the issue a bit more and found:

Looking into it, VS2012 uses SHOpenFolderAndSelectItems for files (e.g. right-click a document tab), but does a ShellExecute with the "explore" verb when opening a folder (e.g. right-click a project).

They also created two little test programs.

Running those programs while WE is the default results in notepad.exe and write.exe being selected, and the programs closing.

Setting XY as the default file manager and running those test programs results in XY launching and navigating to the correct directory, but the files are not being selected. Additionally, the test programs do not exit, as they are presumably waiting for some message from the shell or XY about completion.


So it's possible that in setting XY as the default explorer there are additional registry entries that it should be modifying - and since it sounds like this is fixed in DOpus one could compare and attempt to locate them. It's also possible that DOpus is being more invasive in hooking into Windows to allow it to better replace WE.

However, while you wait for Don to return from vacation or for someone to compare registry modifications and determine what might be missing here are two workarounds I can think of:
1) Add XYplorer as an external tool to Visual Studio - combine this with scripting and it could become even more powerful than the current command.

2) Create a Visual Studio Extension to replicate the "Open Containing Folder" function but work with any executable. Essentially create an extension that does the same as the external tool.


And I'd add that this feature removal binge that Microsoft has been on, especially with regards to Visual Studio, is becoming incredibly annoying.

[neminem]

1) Add XYplorer as an external tool to Visual Studio - combine this with scripting and it could become even more powerful than the current command.

Well frack me. I totally did not know that was a thing you could do. That works completely, and is way less ugly and prone to breakage than the macro solution was. Didn't even know you could add new external tools, let alone add them and then add them to context menus. Opens a little faster, too. Thanks a ton!

And I'd add that this feature removal binge that Microsoft has been on, especially with regards to Visual Studio, is becoming incredibly annoying.

True, but I can also see why: because there are already so many features that neat ones like the one I just discovered above get totally lost.

[TheQwerty]

Well frack me. I totally did not know that was a thing you could do. That works completely, and is way less ugly and prone to breakage than the macro solution was. Didn't even know you could add new external tools, let alone add them and then add them to context menus. Opens a little faster, too. Thanks a ton!

Then I should apologize since I lead you astray with suggesting a macro previously when the external tools were (I believe) always a possibility. Sorry!


At least this points to a satisfying workaround, but there is still a bug in how XY becomes the default file manager since the normal command should work (as evident by DOpus).

[admin]

So it's possible that in setting XY as the default explorer there are additional registry entries that it should be modifying ...

I'm ready whenever those mystery keys are revealed.