How can I change the "OK" text into "Great!" on all buttons in Windows 7's dialog windows?
The MessageBox function is documented as being in User32.dll. Modify that and you should be set.
A couple of caveats:
This is an important system DLL and Microsoft will have gone to some lengths to keep it from being modified. Not only will you have trouble modifying it, but if you succeed Windows might restore it from a backup as soon as it can.
If you screw up you might make your system unbootable.
If I ever find you doing this to any PC of mine, prepare to hide and hide well, because I will be looking for you.
Related
I've used ObjectDock in the past to replace the taskbar for a number of reasons. I had to reinstall Windows and apparently now ObjectDock is no longer free. One main reason I liked ObjectDock is because it completley replaces the taskbar, hiding the taskbar completely, not just autohiding it or hiding it till moving my mouse to the bottom, but actually completely removing it.
So clearly there is some way to hide it or move it so it doesn't show up in some way, but I've yet to find anything online that shows a way within Windows 7 or a programmatic way to do so. I've got most of my programs linked to hotkeys through AutoHotkey, and since my resolution is small I'd like the extra space.
Try using either Taskbar Eliminator or The Ultimate Windows Tweaker. They should allow you to remove it, this should remove it for you.
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.
The code below will send the keystrokes to the DHTML edit control on Windows Vista but not on windows xp.
DHTMLEdit1.SetFocus
MySendKeys ("zzz")
MySendKeys refers to a replacement for VB6 Sendkeys written by Karl Peterson for windows vista and beyond. But I don't think that's relevant because the following code does not work on xp either
DHTMLEdit1.SetFocus
SendKeys ("zzz")
On windows xp the DHTML edit control is "DHTML Edit Control for IE5" according to the project components window in vb6
On windows vista it's the "DHTML Editing Control" which does not come pre-installed with windows but is available from Microsoft.
Does anyone know how to make it work?
SendKeys() isn't so compatible anymore. DHTML editor likely has another method of inputting data that doesn't require you to hack something together like that. For the most part, it's usually a security risk.
Also, it's likely a different control altogether, and it might not even properly respond to key strokes.
Perhaps you can elaborate on what you're attempting - maybe there's a better solution than sending key strokes.
I ended up using this inelegant solution
Clipboard.SetText "zzz"
DHTMLEdit1.ExecCommand DECMD_PASTE, OLECMDEXECOPT_DODEFAULT
DHTMLEdit1.SetFocus
On vista and later it's effect is the same as sendkeys.
On xp it inserts the text correctly but doesn't leave you
with a blinking cursor (you have to manually click the control
to resume typing from the keyboard).
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 want to get the window handle of some controls to do some stuff with it (requiring a handle). The controls are in a different application.
Strangely enough; I found out that many controls don't have a windows handle, like the buttons in the toolbar (?) in Windows Explorer. Just try to get a handle to the Folder/Search/(etc) buttons. It just gives me 0.
So.. first question: how come that some controls have no windows handle? Aren't all controls windows, in their hearts? (Just talking about standard controls, like I would expect them in Windows Explorer, nothing customdrawn on a pane or the like.)
Which brings me to my second question: how to work with them (like using EnableWindow) if you cannot get their handle?
Many thanks for any inputs!
EDIT (ADDITIONAL INFORMATION):
Windows Explorer is just an example. I have the problem frequently - and in a different application (the one I am really interested in, a proprietary one). I have "physical" controls (since I can get an AutomationElement of those controls), but they have no windows handle. Also, I am trying to send a message (SendMessage) to get the button state, trying to find out whether it is pushed or not (it is a standard button that seems to exhibit that behaviour only through that message - at least as far as I have seen. Also, the pushed state can last a lot longer on that button than you would expect on a standard button, though the Windows Explorer buttons show a similar behaviour, acting like button-style checkboxes, though they are (push)buttons). SendMessage requires a window handle.
Does a ToolBar in some way change the behaviour of its child elements? Taking away their window handle or something similar? (Using parent handle/control id for identification??) But then how to use functions on those controls that require a windows handle?
If they don't have a handle, they're not real controls, they're just drawn to look like controls.
But of course, the toolbar buttons in Windows Explorer do have window handles, they're part of a toolbar. Use the toolbar manipulation functions to interact with them, not EnableWindow.
Or, better yet, use the documented APIs for things like search. Reverse-engineering Windows Explorer has never ended well for anyone, least of all the poor Windows Shell team, saddled with years of backwards-compatibility hacks for certain developers who thought that APIs are for everyone else. Whatever you do manage to get to work is very likely to break on the next version of Windows.
The controls you are talking about are using the ToolbarWindow32 class. If you want to interact with them then you'll need to use the toolbar control APIs/message. For example for enabling buttons you'd want to use TB_ENABLEBUTTON.
You can implement the controls yourself using GDI, OpenGL or DirectX. Try Window Detective on Mozilla Firefox and you will see that there is only one window. Controls in dialog boxes are not windows known to Windows.