I have this problem. I want to open two same windows which behaviour is mirrored. So if I click on first window same action is executed on second window (mirrored behaviour). Is it possible? How can I do this? My application is in C++ and I use WinApi.
Thanks.
Well, you can comunicate between them using socket, shared memory or something like that... Another way is to send all windows messages you recieve from one window to another.
Related
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
I want to develop Windows program who can stick into other
window.
I searching fastest-way to do this. I can get by WinAPI all
information about target window and move my window into good location
and after it Sniffing Windows Messages of target window to searching resize or move window and after this doing move my window again. But i don't know what is a simplest good working way (maybe somewhat on .NET? But i don't preffer answers in .NET i like free framework's).
I want to stick on the top, bottom, left, right of the target window, but this maybe never mind.
Can anyone help me something with this problem?
Thanks.
I used DLLInjection to get into target windows process, created some hooks using winapi calls and by XML over Message Pipe transporting this values to other application who stick to this windows.
You basically need to do two things:
Get a list of all windows to which your app is supposed to stick, and their locations/dimensions.
Listen to your application's main window's move event and if at any point your window gets close enough to any of the relevant windows from #1 you move it yourself so that they align.
You can do both in Win32 API or with .Net. You just need a good criterion for #1. Like, for example, all top level visible windows that are within the desktop's boundaries.
Might want to include the desktop itself in the list above, so that your app sticks to the edges of the desktop as well.
Short version:
How can I receive input messages in Windows with C++/C when the window is not active?
Background information:
I'm currently working on an Input System that should not depend on any window, so it can e.g. be used in the console as well.
My idea is to create an invisible window only receiving messages, which is possible using HWND_MESSAGE as hWndParent. It only receives input messages when it's active though, and I don't want this. It should always receive input (unless the application requests it no longer does so, e.g. because it lost focus).
I know this is possible somehow, many applications support global shortcuts (e.g. media players (playback control) or instant messengers (opening the contact list)), I just don't know how. Do you know?
Options:
RegisterHotKey if you need to register just one or a few hotkeys
SetWindowsHookEx with WH_KEYBOARD / WH_KEYBOARD_LL. Use when you need to filter many or all keyboard events. However, the hook code needs to be implemented in a DLL (which is loaded into other processes). You need separate 32 bit and 64 bit versions of the DLL
You need to setup windows keyboard input hook. Here is an example how to do it; it is even easier to do in C++
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
I have a written a Visual C++ console application (i.e. subsystem:console) that prints useful diagnositic messages to the console.
However, I would like to keep the application minimized most of the time, and instead of minimizing to the taskbar, appear as a nice icon on the system tray. I would also like to restore the console when the system tray icon is clicked.
How should I change my program to do this?
This is going to be an ugly hack.
First, you have to retrieve the hWnd / hInstance of you console application. Right now, I can only come up with one way:
Create a Guid with CoCreateGuid()
Convert it to a string
Set the title of the console window to this guid with SetConsoleTitle()
Find the hWnd of the your window with the Guid as the tile with FindWindow()
And you can do it from the usual way from this point. See http://www.gidforums.com/t-9218.html for more info.
Don't forget the rename your console window to the original title once you're done.
As you can see, even though this is possible to do, it's a horrible and painful solution. Please don't do it. Please do not minimize console applications to the system tray. It is not something you are supposed to be able to do in the Windows API.
You might want to write a separate gui to function as a log reader. You will then find it much easier to make this minimize to the tray. It would also let you do some other stuff you might find useful, such as changing which level of logging messages are visible on the fly.
To learn the console's hWnd you have two choices:
On Windows 2000 or later you can use the GetConsoleWindow() function. Don't forget to define _WIN32_WINNT as 0x0500 or greater before including windows.h to have access to this function.
If you want to run your program on earlier Windows versions as well then you must use something like the GUID trick described above.
Probably your best bet is to create a "Message-only window" (a message queue without a visible window) to receive the Notification Area messages.
The answer with a GUID is completely ridiculous (no sense at all)
The Console hWnd is of course given by GetConsoleWindow() (!)