On the Windows Vista taskbar, you can middle-click an icon to open a new instance of a program. In a Windows Vista explorer window address bar (the thing that shows the current file path as a bunch of clickable folders seperated by arrows,) you should be able to middle-click a folder and open a new window there. Is there anyway I could write code to modify Windows to do this?
Not an easy way. You could look into writing an Explorer BHO that subclasses the Windows Explorer window, in particular the address bar control.
Update: Should mention that while BHOs are always mentioned in the context of IE, they are also loaded by Windows Explorer, unless explicitly registered not to be.
Disclaimer: Do not write a BHO after consuming alchohol. Writing a BHO should not be done by pregnant women, small children under age of 18, and people with heart problems. Possible side effects include weight loss, weight gain, sleep deprivation, increased number of SO questions, depression, vomiting, nausea, can affect your work/life balance problem, and lead to severe problems with your life partner.
Related
A lot of the Windows style guidelines refer to 'Desktop Presence' in various places, e.g. http://msdn.microsoft.com/en-us/library/windows/desktop/dn742496(v=vs.85).aspx', but it's never defined anywhere that I can see.
Is there a definition for what exactly they mean by this?
Is it the presence of a normal window on the screen throughout the execution of the application? Do apps that occasionally appear on screen (with dialogs or notifications), but are predominantly hidden count? What about applications you can interact with on the desktop but only on demand, e.g. the wireless network connection menu?
Found an ok answer in the article I initially linked to, in the end (http://msdn.microsoft.com/en-us/library/windows/desktop/dn742496(v=vs.85).aspx):
"The taskbar is the access point for programs displayed on the desktop, even if the program is minimized. Such programs are said to have desktop presence."
I have a Windows shell extension that uses IShellIconOverlayIdentifier interface to display overlay icons on files and folders. My extension is a little like TortoiseCVS or TortoiseSVN.
Sometimes I need to make Windows Explorer redraw all it's icons. To do this, I call SHChangeNotify like this:
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, NULL, NULL)
This refreshes the desktop and right hand pane of any open explorer windows. It doesn't refresh the folder tree on the left hand side of any Explorer windows.
So I tried sending WM_SETTINGCHANGE like this:
SendMessage(HWND_BROADCAST, WM_SETTINGCHANGE, 0, 0)
on Vista this refreshes the folder tree, but not the right hand pane.
The combination of SHChangeNotify() followed by WM_SETTINGCHANGE seems to work quite well on Vista. But I still can't refresh the folder tree on XP if it is displayed.
Does anyone have any ideas how to do this better?
Is there a better solution for XP?
Sending SHCNE_ASSOCCHANGED is a bit like clubbing Explorer over the head. It causes the whole desktop to refresh quite violently and casues any open Explorer windows to loose there scroll position. Is there anything that's a bit less violent?
Does anyone have any ideas how to do
this better?
Personally I don't know. You mention the Tortoise programs which do a similar thing, so an excellent starting point would be to have a look at what they do in their source :)
These look to be the relevant source files that handle this problem:
TortoiseCVS - ShellUtils.cpp
TortoiseSVN - ShellUpdater.cpp (username: "guest", password: "")
I note in the RebuildIcons method in each of those will:
set the shell icon size or colour depth to a temporary value
updates all the windows by broadcasting the setting change
resets the shell icon size or colour depth to the original value
updates all the windows a second time with a broadcast of the setting change
Perhaps this is part of the trick to get things working in XP.
Use spy++ to see what WM_COMMMAND message gets sent when you press F5 in windows explorer or find what menu message is used for view/refresh
Then use FindWindow to get the explorer window you want and send the WM_COMMAND recorded earlier etc message to it.
This is a fun way to control all sorts of Windows programs.
You can also send a WM_KEYDOWN message with the F5 keycode to all open explorer windows. This is a bit of a hack though.
I want to enable users to view the windows Quick Launch bar via DLL call (I checked the registry modification option but it's the route around).
I know the functionality is stored in shell32.dll and it the DLL can be accessed by rundll32.exe.
rundll32.exe shell32.dll
My question is:
Can anyone point me to a through reference of the shell32.dll entry points and arguments, or knows of a program that extracts it from the DLL itself?
Raymond Chen from the Windows shell team discusses this in a blog article.
In short there is no documented, supported way to do this on XP. You'll need to continue using the hack you've found. In Vista you can use ITrayDeskBand. Windows 7 task bar is, of course, different again.
Raymond also points out that programs should not be changing the user's choice of visibility for the Quick Launch bar.
That's not something a program should be doing. Whether
the Quick Launch bar is shown or hidden is an end user
setting, and programs should not be overriding the user's
preferences. Explorer consciously does not expose an
interface for showing and hiding taskbar bands because it
would just be a target for abuse. Much like the program that wants to uninstall other programs, the taskbar would become a battleground among programs that each wanted
to force themselves on and force their opponents off. The user is the arbiter of what goes into the Taskbar.
I'm a Mac user and a Windows user (and once upon a time I used to be an Amiga user). I much prefer the menu-bar-at-the-top-of-the-screen approach that Mac (and Amiga) take (/took), and I'd like to write something for Windows that can provide this functionality (and work with existing applications).
I know this is a little ambitious, especially as it's just an itch-to-scratch type of a project and, thanks to a growing family, I have virtually zero free time. I looked in to this a few years a go and concluded that it was very difficult, but that was before StackOverflow ;)
I presume that I would need to do something like this to achieve the desired outcome:
Create application that will be the custom menu bar that sits on top of all other windows. The custom menus would have to provide all functionality to replace the standard Win32 in-window menus. That's OK, it's just an application that behaves like a menu bar.
It would continuously enumerate windows to find windows that are being created/destroyed. It would enumerate the child windows collection to find the menu bar.
It would build a menu that represents the menu options in the window.
It would hide the menu bar in the window and move all direct child windows up by a corresponding pixel amount. It would shorten the window height too.
It would capture all messages that an application sends to its menu, to adjust the custom menu accordingly.
It would constantly poll for the currently active window, so it can switch menus when necessary.
When a menu hit occurs, it would post a message to the window using the hwnd of the real menu child control.
That's it! Easy, eh? No, probably not.
I would really appreciate any advice from Win32 gurus about where to start, ideas, pitfalls, thoughts on if it's even possible. I'm not a Win32 C++ programmer by day, but I've done a bit in my time and I don't mind digging my way through the MSDN platform SDK docs...
(I also have another idea, to create a taskbar for each screen in a multi-monitor setup and show the active windows for the desktop -- but I think I can do that in managed code and save myself a lot of work).
The real difference between the Mac menu accross the top, and the Windows approach, is not just in the menu :- Its how the menu is used to crack open MDI apps.
In windows, MDI applications - like dev studio and office - have all their document windows hosted inside an application frame window. On the Mac, there are no per-application frame windows, all document windows share the desktop with all other document windows from other applications.
Lacking the ability to do a deep rework of traditional MDI apps to get their document windows out and onto the desktop, an attempt, however noble, to get a desktop menu, seems doomed to be a novelty with no real use or utility.
I am, all things considered, rather depressed by the current state of window managers on both Mac and Windows (and Linux): Things like tabbed paged in browsers are really acts of desperation by application developers who have not been given such things as part of the standard window manager - which is where I believe tabs really belong. Why should notepad++ have a set of tabs, and chrome, and firefox, and internet explorer (yes, I have been known to run all 4), along with dev studios docking view, various paint programs.
Its just a mess of different interpretations of what a modern multi document interface should look like.
The menu bar on a typical window is part of the non-client area of the window. It's drawn when the WndProc gets a WM_NCPAINT message and passes it on to DefWindowProc, which is part of User32.dll - the core window manager code.
Other things that are drawn in the same message? The caption, the window borders, the min/max/close boxes. These are all drawn while processing a single message. So in order to hide the menu for an application, you will have to take over handling of this message, which means changing the behavior of user32.dll. Hiding the menu is going to mean that you become responsible for drawing all of the non-client area.
And the appearance of all of these elements - The caption, the borders, etc. changes with every major version of Windows. So you have to chase that as well.
That's just one of about a dozen insurmountable problems with this idea. Even Microsoft probably couldn't pull this off and they have access to the source code of user32.dll!
It would be a far less difficult job to echo the menu for each application at the top of the screen, and even that is a nearly impossible job. When the menu pops there is lots of interaction with the application during which the menu can be (and often is) changed. It is very common for applications to change the state of menu items just before they are drawn. So you will have to replicate not only the appearance of the menus, but their entire message flow interaction with the application.
What you are trying to do is about a dozen impossible jobs all at once, If you try it, you will probably learn a lot, but you will never get it to work.
I have a Windows shell extension that uses IShellIconOverlayIdentifier interface to display overlay icons on files and folders. My extension is a little like TortoiseCVS or TortoiseSVN.
Sometimes I need to make Windows Explorer redraw all it's icons. To do this, I call SHChangeNotify like this:
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, NULL, NULL)
This refreshes the desktop and right hand pane of any open explorer windows. It doesn't refresh the folder tree on the left hand side of any Explorer windows.
So I tried sending WM_SETTINGCHANGE like this:
SendMessage(HWND_BROADCAST, WM_SETTINGCHANGE, 0, 0)
on Vista this refreshes the folder tree, but not the right hand pane.
The combination of SHChangeNotify() followed by WM_SETTINGCHANGE seems to work quite well on Vista. But I still can't refresh the folder tree on XP if it is displayed.
Does anyone have any ideas how to do this better?
Is there a better solution for XP?
Sending SHCNE_ASSOCCHANGED is a bit like clubbing Explorer over the head. It causes the whole desktop to refresh quite violently and casues any open Explorer windows to loose there scroll position. Is there anything that's a bit less violent?
Does anyone have any ideas how to do
this better?
Personally I don't know. You mention the Tortoise programs which do a similar thing, so an excellent starting point would be to have a look at what they do in their source :)
These look to be the relevant source files that handle this problem:
TortoiseCVS - ShellUtils.cpp
TortoiseSVN - ShellUpdater.cpp (username: "guest", password: "")
I note in the RebuildIcons method in each of those will:
set the shell icon size or colour depth to a temporary value
updates all the windows by broadcasting the setting change
resets the shell icon size or colour depth to the original value
updates all the windows a second time with a broadcast of the setting change
Perhaps this is part of the trick to get things working in XP.
Use spy++ to see what WM_COMMMAND message gets sent when you press F5 in windows explorer or find what menu message is used for view/refresh
Then use FindWindow to get the explorer window you want and send the WM_COMMAND recorded earlier etc message to it.
This is a fun way to control all sorts of Windows programs.
You can also send a WM_KEYDOWN message with the F5 keycode to all open explorer windows. This is a bit of a hack though.