I am trying to write a very limited taskbar replacement without the start menu and the standard desktop.
But now i wonder how explorer.exe works internally.
1.) How does the taskbar catch minimizing windows?
2.) How do the taskbar get to know when a window opens or closes or somthing? (Is there an api?)
3.) How does explorer.exe enable visual styles? (If it doesn't run all styles are disabled and it looks like win9x)
Review the SetWindowsHookEx() documentation in the MSDN Library. The important hook type here is WH_SHELL.
SetWindowsHookEx with a WH_CBT or WH_SHELL hook (I'm not sure if WH_SHELL works 100% on all systems when explorer is not running)
As far as #3 goes, I don't think I have seen that problem.
Explorer uses a lot of undocumented functions, you should take a look at some of the open source replacement shells or google RegisterShellHook, ShellDDEInit and ARW_HIDE
Check RegisterShellHookWindow, I believe Microsoft added it to avoid having to maitain a 32-bit and a 64-bit hook on newer x64 OS versions.
Related
Given a program process (say Visual Studio 2012), how can I access it's menu items programmatically?
I'm not at all sure what APIs I would use or how to even Google this.
Thanks in advance.
Start with GetMenu(): http://msdn.microsoft.com/en-us/library/windows/desktop/ms647640(v=vs.85).aspx and over on the left are all the other menu functions. (Assuming you're talking Win32 API.)
Since it appears you have the process ID, you can find the main window's HWND from here: Win32 - Get Main Wnd Handle of application
unfortunately, more and more programs don't use the traditional "menu" subsystem. The answer given by Graham will work for some simple application, as calc.exe and notepad.exe, but not for VS2012.
I suggest using UIautomation.
The Windows SDks come with an "accessibility" tool, Inspect, that will show you if you can expect good support of UIAutomation by applications.
Microsoft now recommends using Accessibility Insigths instead:
https://learn.microsoft.com/en-us/windows/win32/winauto/inspect-objects?redirectedfrom=MSDN
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).
TL;DR - How does the Spy++ tool really construct its process list?
Stage
We have an MFC desktop application (running on Windows XP) that is hanging in that it doesn't react to any user input anymore. It is redrawn when switching to it via alt-tab however. (It does receive WM_SETFOCUS, WM_ACTIVATE, etc. It apparently does not receive any mouse or keyboard messages.)
Since the app is hanging in some limbo, we pulled a few process dumps, but these were of little help so far. Enter:
Spy++
We used Spy++ to find the information I gave above about the window messages this application seems to be processing. We did this by Opening the Windows View and selecting our application Window and in the Messages properties selected Windows of same process and Messages to View : Select All.
However we first tried to view all messages of this process by opening the Processes View of Spy++ and our application is not shown in this process list. Cross checking on another PC where the app is running normally, the process is also normally shown in the processes list of Spy++.
Can anything about the misbehaving app be inferred from the fact that the process is not shown in Spy++'s Process View, but the main window of the app is shown in the Windows View. Why would a process with a main window that is visible not be shown in Spy++'s Processes View?
The process is listed in Task Manager and in the Attach Process Window of Visual Studio 2005. So these tools apparently use a different method to list processes than Spy++ ... ?
The system where the app is currently hanging is a Windows XP SP2 system and we've used the Spy++ Utility that comes with Visual Studio 2005.
The behavior does recur occasionally, but only after the App has been running for several days!
Running Vista or later? Your process is probably elevated and Spy++ is not. Newer versions of Spy++ require elevation. So, try elevating Spy++ explicitly and see if that helps.
Yes, of course things can be inferred from this. Don't take anything I say too seriously in this context, I'd have to go look at the code. But I believe that Spy goes off and looks at the EnumProcesses API. (http://msdn.microsoft.com/en-us/library/ms682629.aspx)
So, if your process isn't showing up there... hrm.
But, what is different between the system where it's working and the one where it's not?
Spy++ requires the following two values in the registry to be disabled (0) to display the processes/threads list AT ALL:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib
HKLM\System\CurrentControlSet\Services\PerfProc\Performance
Disable Performance Counters -> either 0 or not present
Was going insane trying to find out why it refused to display them. It's some kind of bad joke - this debugger requires itself a debugger to get it working! Not that WinDBG would display any meaningful info, MS doesn't even provide a symbol file on their symbol server, pfft.
Anyway, maybe it doesn't display processes that have their performance counters disabled, because I think, this can be set on individual basis, at least for services, like:
HKLM\SYSTEM\CurrentControlSet\Services\.NET CLR Networking\Performance
Disable Performance Counters
So it's basically always a value of the "Performance" subkey. All this stuff is undocumented, it makes use of advapi32.dll functions like "PerfRegQueryValue" and "PerfRegQueryInfoKey"... don't ask me.
I'd like to play animations on the Windows desktop without relying on 3rd-party products such as StarDock DeskScapes or Windows DreamScene. What APIs should I look into?
you can read this thread...
http://www.gamedev.net/community/forums/topic.asp?topic_id=113986
it is long, but in it, is a discussion of writing to the desktop...
hope this helps...
~Bolt
I've never done this, but here's the approach I'd take.
Inject a dll into explorer via SetWindowsHookEx.
Grab a handle by using GetDesktopWindow.
Subclass the Desktop using GetWindowLongPtr & SetWindowLongPtr.
Do all your fancy rendering in the new WndProc you've hooked up.
Be aware that breaking the Desktop window will probably lock up your machine, as all its decedent windows (read: every window for that User) will likely be adversely affected.
Also, given the um rich compatibility history of Windows, be on the lookout for dummies meant to absorb abuse. In particular, I wouldn't be at all surprised if GetDesktopWindow does not in fact return the Desktop window you're looking for. You might have to do some digging with Spy++ or the like, basically.
Using WinXP. What I need to do (pref in VB or c#) is to detect when another (closed source) program displays a notification balloon in the tray - and grab the details. Any help would be appreciated. Thanks
In similar situations, I have used the Microsoft tool Spy++ to grab the window information and then uses pinvoke calls to FindWindow to detect when the window is present.
I've not tried with a notification balloon, but I imagine that a pinvoke call to GetText would retrieve the contents.
I think you'll need to use pinvoke to do this from a .net language.
On the system I'm using now (Vista Business SP2), balloon windows always seem to have window class #32769 (reserved for desktop windows) and the windows style bit TTS_BALLOON set.
The following might work: Determine the parent window for all notification balloons by creating a temporary one, getting its hWnd, and calling GetParent() before deleting it. You could then periodically poll the children of this parent hwnd (using EnumWindows() or FindWindowEx()) looking for windows with the required class and style.
This seems highly non-portable to me, and likely to require a lot of testing on a variety of platforms.
pinvoke.net and spy++ might be useful.
Good luck!
You will definitely need to use Win API calls to achieve this. If this is the only thing you're trying to do, you'd be better off using straight C or C++ so you don't have to do a bunch of platform invoke for C# or VB.
Since andyjohnson identified that the window class for all notification balloons is #32769, and that they have the TTS_BALLOON style set, you could use a CBT hook (if you're not familiar with Win32 hooks, you might want to read up on them), to get a callback whenever a window is created, and check for windows of that class and with that style.
I'm not sure, though, if a new balloon window is created for second and subsequent popups or if the same one is just hidden and reshown. If this is the case, you might need a CallWndProc hook, to get WM_SHOWWINDOW messages.
Edit:
I should mention that the hooks that I've mentioned cannot be implemented in .NET. Except for the low-level keyboard and mouse hooks, global system hooks must be implemented in a native (unmanaged) DLL. Windows will load this DLL into other processes, and if a managed DLL gets loaded into a process that doesn't have the .NET CLR loaded, it will crash that process. (Even if the CLR is loaded, it might be at a different address, also causing a crash.)
So you must build your hooks in a native (unmanaged) DLL. It's possible to interface from here to a managed application, such as Michael Kennedy has done on Code Project, but to do it properly, and handle the hook types I've mentioned above, you'd need to use interprocess communication, a step that Michael Kennedy left out. All in all, for the purpose you've described, it would probably be easier to just build the whole thing in native code.