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.
Related
I am looking for a lightweight solution that would allow me to detect which form/ dialog is open in an application, then emit some keystrokes / mouse moves and clicks. I do not have control over (nor the source-code for) the application.
I am familiar with MacroMaker, also testing products like SQA / Mercury offer similar functionality. The last time I had hands on exposure in this are is late 2004, I welcome any pointers to bring my knowledge up to date.
AutoIt is a scripting environment for Windows with a long history. It's quite easy to use and flexible to do things like detect the open window or dialog, change to another one, type something, etc. I would definitely recommend it.
In case anybody is curious, in the end I decided to use Microsoft UI Automation. Here is nice intro:
http://msdn.microsoft.com/en-us/magazine/cc163288.aspx
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.
This library does exactly what I am talking about on Linux systems: http://ichi2.net/pyosd/
My knowledge of Win32 API is limited but it seems to me that unless you create a window and enter the win32 main loop, you cannot do it. Some Googling also confirmed that.
Even so, are they newer GUI frameworks or technologies that would make it happen on windows?
Thanks
You don't need no stinkin' GUI frameworks. You can either:
Draw directly on the desktop. Of course, this is not generally considered a good idea, since it's mucking around with the internals of another application. Drawing this way is also quite fragile because your changes are erased each time the desktop repaints itself.
Create a transparent, layered window that you draw onto, which will appear over the desktop. If you specify that this window should be a top-level window, you could also have it appear over all of the other windows on the desktop.
There is absolutely nothing that forces windows to be rectangular gray-colored boxes, and since each window provides a device context that you can draw into, you can let your imagination run wild.
I've only ever done server, web, and database programming, never any desktop programming. I now want to learn and have a small project I want to attempt, but am not sure which library/framework to use.
I'd like to create a small cross-platform app that runs in the system tray (and whatever the OSX equivalent is), and listens for changes to windows on the Desktop. Specifically:
Windows XP, Vista, 7, Gnome, KDE, OSX. BSD, Android, and/or iOS would be nice too but not required.
Listens for when any window gains focus, loses focus, is opened or closed, or if the window title changes (for example when switching tabs in a tabbed browser). Any other information it can scrape from the window would be useful as well.
Can store these events, preferably in an embedded database like SQLLite.
The lighter-weight the better.
Includes an options GUI accessible via a right-click menu from the system-tray icon.
Preferably FOSS, but if you know any non-FOSS please list too.
Is there a single library or framework that can do all that across multiple platforms? QT? Python? Java? Something else? TIA.
Almost any GUI framework can easily let you know when your own application gains or loses focus (or the other operations you mention). However, listening for these events for other arbitrary applications is definitely platform-specific and may or may not even be possible.
One framework for doing this on Windows is the CBT callback hook. See the question CBT Hook not working in Windows Vista for information about possible limitations on using this technique.
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.