Is there a ready-to-use API (C / C++) in Windows Mobile ecosystem that I could use to generate a GUID? I am looking for simple one-shot API to do this. If there is a need to write a whole algorithm or use some extra 3rd-party modules, I will do away without this.
Background. To display notification to the user I use SHNotificationAdd, which requires a GUID for it. Examples in MSDN and other sources show that GUID is hard-coded. However, I want to wrap the SHNotification* within a class that blends well within the overall design of my application. MSDN is very shy on details on what SHNOTIFICATIONDATA->clsid represents. The "class" mentioned raise more questions than it answers.
Use CoCreateGUID() for Windows Mobile...
You don't need to generate a GUID for SHNOTIFICATIONDATA.
You only set the clsid if you want WM to notify a COM object that implements IshellNotificationCallback interface.
Quote from MSDN:
When loading up the SHNOTIFICATIONDATA
structure, you can specify either the
notification class (clsid), the window
to receive command choices (hwndSink),
or both. If you specify the clsid,
your COM component must implement
IshellNotificationCallback. If you
specify the clsid and an hwndSink,
both COM and Window Message-style
callbacks will be generated.
I've never personally used the COM callback, I always use the windows message callback. It's a lot easier to setup and use and you don't need to generate a GUID.
You could also use UuidCreate (which CoCreateGuid eventually calls).
Related
I'm currently attempting to developing a small application / dll that will read a remote directshow filter graph and glean information from it for display in a "now playing" style plugin or script. After a few days of reading and subsequent testing, I realized that after getting the filter graph address from the ROT I was failing to convert it from the IUnknown interface pointer to IFilterGraph until I had registered "proppage.dll" which came with Windows SDK.
So what I am asking is, is there no other way to glean any information from a remote filter graph without having to register proppage.dll?
You can't call a COM interface from another address space unless you marshall the interface pointers and parameters/return values to and from the other process. For COM, you need to register a marshalling object for each interface that you want to be able to use cross-process. The standard implementation for that is in proppage.dll.
I don't think there is a simple way to access the interface without providing marshalling. If you don't want to use proppage.dll, you can build marshalling code from the IDL files supplied with the SDK and compile that into your own app.
G
I'd like to keep track of the ActiveX controls created by some process. To simplify the problem, I'd first like to monitor the current process only. I want to do this so that I can check whether any ActiveX control supports IOleWindow and if so, whether a given HWND belongs to that ActiveX control (so that I can map HWNDs to ActiveX controls).
Does anybody have experience with this? My first idea was to use API hooking to monitor CoCreateInstance invocations, but I read that this doesn't work in all cases. Some Google research revealed http://www.pocketsoap.com/sf/activation.html which talks about installing a custom class factory - how would this work?
You may find you can find out what you need to know using the UI Automation and Active Accessibility APIs:
http://msdn.microsoft.com/en-us/library/dd317978(VS.85).aspx
If you are sure you need to do this, be aware of the following. CoCreateInstance is essentially a convenience function, which wraps CoGetClassObject and IClassObject::CreateInstance.
If you are going to use that technique you will therefore have to hook CoGetClassObject too, as the process may use it directly.
And of course there is no law saying any library or DLL cannot provide it's own convenience functions which bypass the COM registry altogether. The registry itself is a convenience - if you know where the DLL is you can use LoadLibrary, GetProcAddress to find DllGetClassObject and retrieve the class object without involving the COM libraries, and indeed without the DLL being registered at all.
I ended up hooking CoCreateInstance and CoGetClassObject to track all COM objects being created.
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.
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.
I have a VB6 application that I don't have source code. This application uses third-party ActiveX controls. I want to automate these ActiveX controls. Is it possible to get the IUnknowns or Object references? For some of these, I can get the underlying HWNDs, but from what I can tell there isn't a generic way to convert these HWNDs to the ActiveX control.
Some testing software allows you to script VB6 applications with ActiveX controls. How do they do it?
Are these ActiveX controls in a separate DLL? If so, you can use OLE View (an VS 6.0 tool) to open the dll and view all the interfaces, coclasse and etc.
You might be able to using DLL injection via Microsoft Research Detours library. Basically you'd want to hook the cocreate for those specific controls. You will need to be ultra careful especially if you do anything cross-thread/cross-process (COM threading rules are vitally important).
On whole Detours is easy to use... but I've never tried it with COM routines. You might want to look at a different solution.
Also note that Detours has some licensing restrictions on it that may affect your ability to distribute it.
Testing software may well just send the appropriate WM_XXX messages to the particular windows in question (eg. WM_MOUSEMOVE).
Sorry to say but the VB6 EXE don't contain the manifests needed to pull out the COM objects it uses. You best bet is trying some of rbobby's suggestions especially about sending WM_XXX messages.