Mathimagics
10-21-2003, 08:56 AM
====================================================
A useful tool PLUS a (hopefully) educational demo program
====================================================
A recent post has had me struggling to come up with a solution.
Every time an application opens a File Open/Save dialog using the "Explorer-style" option, it always starts in a "List" mode view.
I want it to start in "Details" mode.
Yes, it seems that this has been causing regular irritation not just for myself, but others. A recent post from KarahaNa prompted me to try and nail this one down.
We want this to work for dialogs in OTHER applications, like my text editor, or the VB browse dialogs.
Not a simple job as it turns out - everywhere you turned to ask "how do I get that" seemed to come back to the need to run cross-system hooks. In the end, the method of "Find", "click" and "click again" was adopted, no hooks. And it works pretty well.
Method
1. A Timer regularly checks the active window to see if it is a newly started Explorer-dialog. If so it selects the correct Toolbar, of which the View option is the last button. It determines the right location, simulates a mouse-click, finds the popup menu (which can be any of 4 possible docked positions!), and calculates the right spot to select the Details option.
(Note: it'd be much simpler if we could simply "read" the menu and send the appropriate WM_COMMAND to the window, as per normal practice. But while we do have the window handle, I have been unable to find any trace of the menu handle, and from my search of the web, nobody else has either! Hence the "primitive", but effective, method of calculating by screen position)
2 It keeps a table of what dialogs it has already "tickled", so it will never do the same one twice (that would be annoying!). This table doesn't grow over time because it garbage-collects expired dialog handles as it goes.
3. It uses the same version of drMemory (module to allocate cross-process buffers) as in the ToolBar scanner I posted in this Library recently. This module is required for the TB_messages to work across processes, although in this program only the TB_GETBUTTON message requires this special handling (it tells us the button ID's).
Interface
It sits as an icon in the Tray, left-click to see the little info panel with a start/stop toggle button, minimise the panel to hide it. Right-click on the icon and you can toggle the start/stop status from a popup menu.
There will, no doubt, be the chance of some unpredictable behaviour as it gets tried on different platforms and in different circumstances!
Please report any funnies, problems, queries, brickbats, etc...
:cool:
A useful tool PLUS a (hopefully) educational demo program
====================================================
A recent post has had me struggling to come up with a solution.
Every time an application opens a File Open/Save dialog using the "Explorer-style" option, it always starts in a "List" mode view.
I want it to start in "Details" mode.
Yes, it seems that this has been causing regular irritation not just for myself, but others. A recent post from KarahaNa prompted me to try and nail this one down.
We want this to work for dialogs in OTHER applications, like my text editor, or the VB browse dialogs.
Not a simple job as it turns out - everywhere you turned to ask "how do I get that" seemed to come back to the need to run cross-system hooks. In the end, the method of "Find", "click" and "click again" was adopted, no hooks. And it works pretty well.
Method
1. A Timer regularly checks the active window to see if it is a newly started Explorer-dialog. If so it selects the correct Toolbar, of which the View option is the last button. It determines the right location, simulates a mouse-click, finds the popup menu (which can be any of 4 possible docked positions!), and calculates the right spot to select the Details option.
(Note: it'd be much simpler if we could simply "read" the menu and send the appropriate WM_COMMAND to the window, as per normal practice. But while we do have the window handle, I have been unable to find any trace of the menu handle, and from my search of the web, nobody else has either! Hence the "primitive", but effective, method of calculating by screen position)
2 It keeps a table of what dialogs it has already "tickled", so it will never do the same one twice (that would be annoying!). This table doesn't grow over time because it garbage-collects expired dialog handles as it goes.
3. It uses the same version of drMemory (module to allocate cross-process buffers) as in the ToolBar scanner I posted in this Library recently. This module is required for the TB_messages to work across processes, although in this program only the TB_GETBUTTON message requires this special handling (it tells us the button ID's).
Interface
It sits as an icon in the Tray, left-click to see the little info panel with a start/stop toggle button, minimise the panel to hide it. Right-click on the icon and you can toggle the start/stop status from a popup menu.
There will, no doubt, be the chance of some unpredictable behaviour as it gets tried on different platforms and in different circumstances!
Please report any funnies, problems, queries, brickbats, etc...
:cool: