I would like to have the ability to process Win32 messages in a console app and/or inside a standalone DLL.
I have been able to do it in .NET with the following article and it works great in C# inside a console app and standalone DLL
http://msdn.microsoft.com/en-us/magazine/cc163417.aspx
Is there a way to do the equivalent with C/C++ Win32 APIs? I have tried doing RegisterClassEx(...) and CreateWindow(...) even passing in HWND_MESSAGE to hWndParent but the trouble is that after the "invisible" window is created messages are not being processed probably due to the lack of a message pump.
Where would the message pump go if you had a DLL entry point? I have tried creating another thread in a DLL and put while(GetMesage(..)) there but that did not work either.
Any ideas?
You need a message pump yes. The window also has thread affinity so it needs to be created on the same thread that you're running the message pump on. The basic approach is sound, if you include more code it may become clear what the problem is.
In addition to what Logan Capaldo said, you also have the problem that, as a DLL, you don't know at compile time what kind of process is going to be loading you at runtime.
If you are being loaded by a console application (/SUBSYSTEM:CONSOLE), then creating a hidden window of your own and setting up a message pump on that same thread will work fine (as long as you are the first window created).
If you are being loaded by a windows app (/SUBSYSTEM:WINDOWS) then you might run into problems getting messages. They will be sent to the top-level window in the hierarchy, which you didn't create. You'll need to get the hWnd of the main process and subclass it (if you aren't already).
If you are being loaded by a service, then you aren't going to get window messages at all. You instead need to use the RegisterServiceCtrlHandlerEx Function
Related
I have recently migrated a project of mine to WebView2 and the last part I can't figure out is how to intercept the Windows Messages for the webview. My code is very similar to webview/webview but I was unable to find help on their GitHub.
Previously, I was able to find the hWnd for the webview and use SetWindowSubclass to add my own wndproc to the webview. However, I've used Spy++ and tried SetWindowSubclass on all the windows that showed up there (see below) but none of them had any windows messages in my wndproc other than some window management ones I did not think were useful - The best I got was WM_PARENTYNOTIFY, but I am interested in WM_MOUSEMOVE and WM_NCHITTEST - neither of which I could find.
My goal is to create a borderless, draggable, resizeable WebView2 based app.
The problem is, that the real window that controls and gets all this input is in another process. You just see a window that shows the output in your process.
Look into Spy++. Everything below Chrome_WidgetWin_0 belongs to a new process (MSEDGEWEBVIEW2) and is not part of your process. So you can't subclass such a window with the normal techniques.
So if you want to subclass this window. You need to inject a new DLL into this new process. This DLL might subclass the real window. And this DLL might communicate with you hosting program via any IPC.
ive recently started to work with the win32 api and im trying to do a couple of things.
I have a project that is gonna use about 4-5 windows. I want to seperate each of these into a different cpp file where each has its own message Loop. How do i pass information from window to window?(is there some sort of entry point?) at the moment im creating all windows during case WM_CREATE: and I am showing them as required.
I am trying to have a nice OOP design but having trouble with that, my main issue is the communication between windows. I have a fair amount of experience in C# and C++ and other than this the win32 api is not being a problem.
Thanks for your help!
I don't think you want a per-window message loop, unless you want each window in its own thread. You probably need a window procedure instead.
Each window class has its own window procedure, which you register by setting lpfnWndProc field of WNDCLASS structure before passing it to the RegisterClass. Once you've done that, you can use that class when creating a new window with CreateWindow.
In your case, you'll probably want to implement the window procedure so it accepts custom messages (WM_APP + x), and then pass custom messages between windows using PostMessage (for asynchronous communication) or SendMessage (for synchronous communication). If necessary, you can create separate window classes and window procedures for your different windows. A single message loop is capable of pumping messages to all these procedures.
The classic way of inter-window communication is sending / posting messages:
SendMessage
PostMessage
First of all: Is this even possible?
I have a third party dll that interfaces some hardware. It's written in MFC. I received (from the dll vendors) a sample Visual Studio 2010 solution which has only one project: An MFC application (.exe) which calls the third party dll in question. It works fine.
When I try to use the third party dll from my dll (which is plain C++, no MFC, no .NET), I can call its functions fine, but there's a catch: the sample MFC app seems to "override" MessageProc in order to capture certain messages that the third party dll generates. And though the dll has a function called "RegisterFuncCallback" and I use it, my callback never gets called.
So here's the problem: How can I capture those messages without creating an MFC app? (Is it even possible?)
Alright, I made it. Here's how:
Create a class which inherits from CWnd
Declare a message map associating the desired messages and their handlers
When creating the Window, use the CreateEx function (I did it in my class's constructor), and pass it the HWND_MESSAGE flag in the last but one parameter. This will create the window as a "Message Window", that is, invisible.
Once I'm done initializing the window and the MFC dll, I call RunModalLoop on my hidden window, in a separate thread, since it's blocking. This fires up the message pump, and starts receiving the MFC dll's messages.
Edit: I could finally do it using just Win32 API. Here's my story, code included:
Programate Algo Blog. Don't worry, it's in English.
If the DLL works with Win32 messages you won't get around them. But you do not neccessarily need MFC for that, a simple WinAPI solution would suffice. MFC just wraps the Win32 API. If those messages aren't Win32 messages, you do not need a Win32 application.
im learning to make things to other windows like resize the ie or any type of window. the only problem i don't know how i can get or give messages to other windows.
so like i pressed a key in ie i would like to get that message to my program too!
any idea
To get the messages that are sent to windows programs you have to install a hook in order to listen to the messages you want. You do this via the SetWindowsHookEx function.
However, I believe that you should read a book about this kind of behaviour, since there are certain rules you have to apply. For instance, before returning from your callback function, you have to call CallNextHookEx in order to let the other hooks handle the message. This is the first hit in books.google.com when searching for setwindowshookex.
Normally your application won't receive Windows messages for other applications (this can be a security problem, for example with keylogger spyware). However, the CBT Hook method can be used to install a hook that receives other window message inputs.
However, note that a Windows feature called UIPI can cause problems with CBT hooks.
i got to do a task that is to find out process /exe/application running in the background.
ie:the process is running but do not have any UI/ Window visible although its an windows GUI application . i thot of reading EXEheader. The header contains a field called 'Subsystem'and application is to run under and the type of interface it requires.
but it returns Windows GUI and it is so. but i want teo detect if that application haves any window or not. also this application is not a service as if it is a service i can easily read the info.
i will be glad if any of you genious put some light on the pronblem stated.
Warm Greetings..
Sarfu
If I understand your question correctly, you want to know if a running application has any visible windows.
To do this, you can call EnumWindows to get all top-level windows. For each window, call GetWindowThreadProcessId to get the process ID and GetWindowLong(hwnd, GWL_STYLE) to get the window style. Test the style for WS_VISIBLE to see if the window is visible. Run through all the windows and see if your process owns a visible one. If you don't have the process ID, you can get them all with EnumProcesses.
The "subssytem" GUI doesn't tell you that the application has a window. In fact, the opposite is closer to the truth. A console application gets a console window. A GUI app is responsible for creating its own windows, if and when it needs them. A GUI process that hasn't called CreateWindow() won't have any windows.
Apparently, you do know the executable you're looking for. In that case, call EnumProcesses() to find all processes, and for each process call EnumProcessModules(). On Windows, "modules" are DLLs and EXEs. Each process will have exactly one EXE module. So, if the one EXE module of any process is the executable you're looking for, then your application is running.