I have a plugin for a c++ MFC app. I'm working with the developer of another plugin for the same app, that's trying to get notifications of events in my code. Both plugins are in the form of c++ dlls.
How can I pass messages from my plugin to his plugin? The solution needs to be robust to mismatched versions of our two plugins, as well as the host app. The notifications are during control point movement, so several times a second.
I could set up a callback mechanism, where upon load his plugin calls a function in my plugin with a function pointer. We're not guaranteed any loading order, but we could probably just check periodically.
I know Win32 has a messaging system, but I'm not sure how it works, really. We could add a hook, and I could send messages, but I'm a bit fuzzy on how we'd synchronize what the message id is, or any details other than what I said, really.
Any other ideas on how to do this?
I'm a bit fuzzy on how we'd synchronize what the message id
Use the RegisterWindowMessage API.
Take a look at this article here, it shows the available IPC mechanisms in windows. I might try COM, Mailslots, Pipes or Shared Memory (file mapping) in your case, in addition to windows messages which you already mentioned.
Related
I know I can use QSharedMemory to transfer information between applications (I've used it successfully). But I'd like to trigger a function on another application. Ex: App1 has a button that when pressed triggers a function on App2 that prints "HelloWorld".
I've checked IPC solutions' page and I see that linux supports D-Bus communications and Qt uses it to extend signals and slots to IPC level, which is essentially the kind of thing I want. But I'm working on Windows for now and need a solution that is compatible with both OSs.
I also see that perhaps I could use TCP/IP solutions in Qt library to establish a server/client communication, but given that I'm not so versed in it I'd prefer something simpler. But maybe TCP/IP is quite simple and with a few variables and functions calls I could get it done. Please tell me if that's the case.
I've also thought of using a boolean variable on QSharedMemory that is set by the master app and is regularly checked and cleared by the slave app when a timer, running on a loop, runs out. But that means more overhead. It's not at all a clean solution, but it would work ok in my case.
I have a legacy Win32 application (WndProcs, etc) that needs to consume a COM object. With the use of a little ATL headers and some smart pointers that was a snap, however what I'm currently struggling with is how best to sink the events coming off that COM object?
My current working plan has been to build a second COM object (as a dll) that handles all the sinking and uses windows messages to communicate with the legacy application. This is "ok" but there's a lot of cruft moving messages back and forth to make the legacy application do what I want.
Is there a readily accessible way to get the Win32 legacy application to sink COM events directly vs running through the second "sinker" com object?
Before I go to far down this process I wanted to see if anyone else ran across this before and had a working solution.
Thanks!
Stumbled across this excellent write up by the always brilliant Raymond Chen.
http://blogs.msdn.com/b/oldnewthing/archive/2013/06/12/10425215.aspx
As WhozCraig indicated above, all I needed was the Interface pointer and to setup the Advise, handle the Invoke.
Nice and clean.
Thanks!
I am running Mozilla Firefox on Windows 7 and would like to be able to send simple commands (New Tab, Minimize, Close Tab) to it from a C++ program.
The usual question of inter-process communication, when both processes are a part of the same user program, seems to be answered by Boost.Interprocess.
But what about actually controlling the GUI window of an entirely independent application (Mozilla)?
You can use Spy++ to debug what messages each action will produce, then replicate those messages in your program.
You can use Ranorex http://www.ranorex.com, Quick Test Pro http://www8.hp.com/us/en/software-solutions/unified-functional-testing-automation/index.html#.UpvC8OJO7tw
Will give you this ability
The general answer to controlling any Windows program through its user interface is by sending it Windows messages. There are also some rather specific Windows APIs that allow you to send specific kinds of inputs directly to the keyboard, mouse or other input device.
Assuming simple requirements, you should be able to control Firefox by sending it some combination of the messages WM_[SYS]KEY[DOWN|UP], WM_[L|R]BUTTON[DOWN|UP] or similar. You may also need to use FindWindow and other things to find where to send messages. And liberal use of Spy++ to figure out what to send and where to.
Actually, what I would do is start with AutoHotKey. It can do all this stuff and then some, and it has a massive community. It's GPL so you can find out how it does stuff and there are people there to ask for help.
I'm trying to understand event hooks in C++. I know what an event is, I've used them a lot in Java, C# and Javascript.
What I'm having trouble with is finding the documentation, and tutorials on stuff like global hooks, dll injection, global hooks without a DLL.
Lets say that I wanted to iterate through the browser tabis in FireFox .. would I need to hope that FireFox has an API for C++? Or lets say I wanted to do something when a user opens a new tab would I need to use a hook that FireFox would provide in their API?
The above is just an example so people know what I'm trying to learn/understand. Am I thinking on the right ines?
I seen a post on a forum and for the past 2 hours I've took an interest. I always say that a tricky challange, or a new challange, makes a stronger programmer.
Any resources, or any help, would be very much appreciated.
C++ itself does not have events or hooks, but a lot of C++ libraries and frameworks implement them. For an example of generic events library, see Boost.Signals.
Some of the implementations allow their events to be seen by other applications, but the API is application-specific (e.g. for Firefox, see XPCOM).
Windows has a mechanizm of hooks that allows to monitor various events in its windowing system. However, it is an OS feature, not related to C++. As it's a system mechanizm, all Windows applications are affected even if they don't do anything for it. The documentation for Windows hooks can be found here. Also, since you mentioned "global hooks without a DLL", see SetWinEventHook, which is a higher-level API than Windows hooks linked above and can be used with hook functions both implemented in DLLs or EXEs.
Look up MSDN for SetWindowsHookEx. It should be your entrance in Windows hooks. If you ar etargetting a parituclar window for mthe system then a less intrusive option is SetWindowLongPtr. For the first API you are going to need some Dll injection - which gets automatically for you by the system. Just follow these steps:
Create a Dll that exports a HOOKPROC function (actual type dependent upon the hook tpe - read in the docs)
Load that Dll in your application and retrieve a pointer to the HOOKPROC function. LoadLibrary / GetProcAddress APIs may be used for this.
From your application, make a call to SetWindowsHookEx feeding in the appropriate parameters - this will inject the dll in the target process. So, the dll is now loaded into both your app's process and in the target process. So you will need a mechanism to IPC between the two processes probably. Lots of ways here - sockets, pipes, shared segment in DLL, filesystem, windows messages, COM servers + events, etc etc.
The former API, while less powerful, does not require DLL injection.
Choose wisely & good luck!
I dont think firefox would be having a C++ aPI to find the open tabs....
If you want to find out open tabs or whenever a new tab is open , you can basically hook the firefox window and get all events happening on that window to your hook procedure.
If you open spy++ in VC++ and track firefox window , you can see a new MozillaContentWindowClass gets created every time whenever a new tab is opened. So you can basically iterate through window handles and get information about open tabs.
You can use SetWindowLongPtr to set the subclass procedure for that window.
In Windows when you create a window, you must define a (c++)
LRESULT CALLBACK message_proc(HWND Handle, UINT Message, WPARAM WParam, LPARAM LParam);
to handle all the messages sent from the OS to the window, like keypresses and such.
Im looking to do some reading on how the same system works in Linux. Maybe it is because I fall a bit short on the terminology but I fail to find anything on this through google (although Im sure there must be plenty!).
Is it still just one single C function that handles all the communication?
Does the function definition differ on different WMs (Gnome, KDE) or is it handled on a lower level in the OS?
Edit: Ive looked into tools like QT and WxWidgets, but those frameworks seems to be geared more towards developing GUI extensive applications. Im rather looking for a way to create a basic window (restrict resize, borders/decorations) for my OGL graphics and retrieve input on more than one platform. And according to my initial research, this kind of function is the only way to retrieve that input.
What would be the best route? Reading up, learning and then use QT or WxWidgets? Or learning how the systems work and implement those few basic features I want myself?
Well at the very basic level you have the X Window protocol http://en.wikipedia.org/wiki/X_Window_System_core_protocol, which we can be pretty complex to handle if you want to do any application. Next on the stack there's Xlib http://en.wikipedia.org/wiki/Xlib which is a "convenient" wrapper around the X protocol, but still is complex for "real life" applications. It's on top of Xlib that most other frameworks are built, trying to simplify application development. The most know are: Xt, Gtk, Qt, etc.
Like in window you have a "event loop", and if you want you can implement on top of it a GetMessage/DispachMessage metaphor to mimic the windows behavior. That way you may have a WNDPROC, but natively X doesn't provide such thing.
Before reinventing the wheel is preferable to take a look at similar applications, what they are using.
If you need something simple you can try SDL http://www.libsdl.org/, which is a cross platform library to aimed to develop games/simple applications. Another alternative is Allegro game library http://www.talula.demon.co.uk/allegro/.
In principle it is absolutely the same. However, it has nothing to do with communication with the OS (nor does it on win32, using user32.dll is entirely optional)
A GUI application has an event loop somewhere, which processes messages from a queue at some level.
There are a lot of libraries typically used to "hide" this behaviour - you can use them (and indeed, you should). If anything, the Xlib event system is even more perverse than Win32's user32.dll one, and is less widely understood, therefore fewer people use it directly.
In Linux or in Windows, applications can use the low-level GUI, or can use a library. Most use a library. Applications can also choose to do neither and operate without a GUI (server applications typically do this). Applications can create multiple threads, one of which sits in an event loop, and others work differently. This is a popular approach too.
Most GUI applications use a higher level library for their GUI
Non-interactive applications, e.g. server applications, don't use the GUI at all and don't use the libraries (e.g. XLib, user32.dll)
Applications which don't lend themselves to an "Event loop" (e.g. Games) typically use a separate thread to process their event loop.
These things are largely true on Win32 and Linux.
It's totally and utterly different. That window procedure is 100% specific to the Windows OS. For linux, it will depend on the window manager (gnome, kde - as you've already mentioned). If you wish to do cross-platform development, you might want to look at things like QT.
You may wish to take a look at the following URLs:
http://www.qtsoftware.com/products/appdev
http://en.wikipedia.org/wiki/Qt_toolkit
As stated by xhantt, what transport the equivalent messages you are looking for is the X Window System. Which, indeed, can be a bit complex.
With XLib you will need to handle the events registering and dequeuing in your main loop. See the XLib manual for a complete description on how to proceed. But don't forget that you will only catch window and inputs events this way. Not every OS messages.
You can also look for XCB which is a newer, and probably easier, library.
If you build your application on top of those two library, it will run smoothly under (almost, we can never be too sure) every WM. And you won't require any dependency that most linux user don't already have on their installation. If you go with Qt, GTK, etc... It will be easier and work under any WM, but they may not have library installed.