Here's a quick one.
I'm starting out with using hooks in in Windows, and I notice that there's a hook type called a "CBT" hook. Though I know how it's used from the documentation, what does CBT stand for, exactly? I'm having a bit of trouble finding that in the docs...
CBT stands for "Computer-Based Training". In addition to its original, intended purpose of enabling instructional software, a CBT hook is most commonly used to provide notification when a window is created, destroyed, activated, resized, moved, minimized, etc.
See the CBTProc Callback Function docs on MSDN for more information.
It stands for Computer Based Training.
I believe it is "Computer Based Training": it's intended to be used in (very basic level!) instructional software that shows the user how to move and click the mouse.
Related
I am not sure how to ask the question so here is a picture of some idea that came to mind
So for example, when you run my "custom launcher" it displays a window with a couple buttons on the side which you can assign values to. When you click on a button, the appropriate program will run in the big panel on the right (in window mode).
This is all from the user's perspective of course. They will just see that the program they want to run appears in that panel. The actual implementation may have nothing to do with "one program running inside another program"
My own use case is limited to windows desktop platforms only, but if it is possible to generalize it that would be nice as well.
Is this actually possible? Can I write such a program that will run another program inside a panel? The program that's launched may be someone else's, such as MS paint or calculator.
Just to expand on my comment above, here is an approach that may work for you: Fake it :)
When you launch the program, intercept all windows messages to the program that control it's position on screen. That way it 'appears' to be fixed in place, but in reality it's still attached to the normal Windows desktop.
Here's some light reading for you:
Windows Event Hooks
A hook is a mechanism by which an application can intercept events,
such as messages, mouse actions, and keystrokes. A function that
intercepts a particular type of event is known as a hook procedure. A
hook procedure can act on each event it receives, and then modify or
discard the event.
I would recommend against it in a commercial application because you are modifying the behavior of software you don't own - that software may make assumptions about what its parent window is, but for experimentation there's the SetParent Win32 function.
Related to my question here, is it possible to create a window hook that will monitor if an application has been opened or not?
Most that I have found about hooks seem to focus on user input (keyboard press, mouse events), but I could not confirm if it is possible to know that the "double click" the user made is to open an application, or just to highlight a word.
Thank you.
Indeed, window hooks would not be sufficient. In fact for the task you are asking about you could use various strategies, such as:
enumerating the processes to find the one you're looking for (Tool Help API or PSAPI)
enumerating the top-level windows on the desktop (but you're limited to your desktop then)
check for a global or local event, mutex (or other kernel object) to deduce from that that some instance of the application is running
... or even from kernel PsSetCreateProcessNotifyRoutine
probably there are variations on the above plus some more.
In essence the question is whether you want to check for the process or for some other indicator that signifies whether the program you want to check for has been started.
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'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.