I am writing a native COM/Ole/ActiveX wrapper for a scripting language.
I need some advices to implement events/callback (like onreadystatechange from Microsoft.XMLHTTP object)
I noticed that some COM objects can call my custom object through an IDispatch interface. Is it the only way to manage events ?
If you're asking the more general question about how COM events work (from any client, not just IE which has some specific requirements around security, etc.) and how to expose your objects' events, then there's a good CodeProject article, Understanding COM Event Handling, which has lots of details about how COM event handling works. Plus a C++ sample (which doesn't depend on ATL or MFC) to illustrate how to host events. Warning: this is a pretty complicated article, but if you can get through it and understand it, you'll have a good background on how COM events work.
If you're specfically asking how to expose your COM objects into javascript so they can be called from Internet Explorer, then how to create an activex control that fires events to javascript (without using ATL) is a good blog post that discusses exactly what you need to (as the title suggests) expose your COM objects to javascript, including all the IE-specific goo.
BTW, unless you have a good reason not to, I'd suggest using ATL to handle your COM support, exposing your events, etc. You can do it in plain, no-dependency C++ (as the article above does) but ATL makes things easier. A reasonable starting point is MSDN's ATL Events section, but I'd definitely read the CodeProject article first for some general background info before diving into the MSDN stuff.
Answering your specific question about IDispatch and events: events don't have to use IDispatch, and clients can talk directly to your C++ event-handler implementation. But most if you want your events to be handled by IE, by javascript, by VB6, and other automation-only apps ("automation" is the COM term for clients using only IDispatch to call properties, methods, and events on COM objects). Most event-sending apps, for this reason, use what are called "dual interfaces" which (in their C++ implementation) inherit from both IDispatch and your custom events interface, and end up calling the same code under the covers. ATL makes it really easy to build such a dual-interface COM component.
Related
I have a photosensitive device frontend from Thorlabs (KPA101) of which I am trying to get the signals values through a call of a method (ReadSumDiffSignals) of a COM/ActiveX object (APTQuad).
Thorlabs give an example of how to do that using VC++ but I cannot get a licence for VC++/VS for various reasons I will not bore you with. Is it possible to do that in any other IDE (say, Code::Blocks?), and if so, how?
I've searched a lot for that lately, in vain.
I need to do an object browser/manipulator, similar to the one available in TestComplete, that is, list all the objects and their properties in any running foreign application, and being able to alter their properties, all of this during runtime, of course.
While MSAA/IAccessible can read objects, it can only return the visible objects, and not alter their properties as far as I know.
Using the WinAPI I couldn't read objects with no handles, in example, labels.
Ideally, I would like this done in Delphi, but any other language suggestions are acceptable.
Example of what I want to be able to do (This was done in TestComplete):
The task is not an easy one. If you want to do this, you need to use specific approaches of getting the data for every application framework you want to work with (.NET, MFC, VCL, etc.). While some of these approaches are quite plain (e.g. Reflection for .NET and Java), some other can be more complex and not documented like in case of VCL. TestComplete loads its own hooks into the target process memory and retrieve information about this application via these modules.
Besides, as far as I know, TestComplete can read various types of debug information for tested applications and use it when exposing objects along with their members.
Using IAccessible and Win API is an easier way, though not so effective in some cases. You mentioned that you were unable to get any information from labels using Win API. This happens because TLabel objects in VCL applications are not window objects.
I'm starting to develop a Windows service. I want to use some classes from my own, that has little dependencies to some MFC classes like CString, CSocket, CArchive, CMemFile and CObject. MSDN says you need to be very careful about which pieces of MFC you use in the Windows service, but don't specifies it and don't describes the problems that can occur.
My questions are:
what pieces of MFC can be used?
what problems can I expect, by using MFC?
which parts of Windows service are critical for MFC use?
is it advisable to use ATL instead of MFC for Windows service?
I'm not sure what they mean in teh MSDN article. As long as you don't use any of the GUI functionality you'll be fine - but that's a general design issue when developing services.
That being said, ATL has functionality specifically designed for building services IIRC so you may be better off using that.
To answer your questions (to the best of my knowledge):
1) the ones you specify are no problem.
2) I guess they mean synchronization issues with UI components. As long as you don't use any CWnd-derived classes you'll be fine.
3) don't understand the question.
4) See before, plus ATL is more lightweight so you'll have to distribute less, and provides build-in functionality that'll make it less of a pain to develop the service. See e.g. CAtlServiceModuleT. You'll still be able to mostly use your own classes, as CString is shared between MFC and ATL nowadays and ATL has classes for socket programming and memory file mapping itself. It doesn't have an equivalent for CArchive, and I'm not sure what functionality you use in CObject so I can't say whether there's an equivalent in ATL. So to conclude, I'd say 'yes' to this question.
(I know this answer is a bit late and this question was already answered but MFC in services is a sore spot for me...)
CSockets, far as I recall, require a Window. It makes an invisible one in the background. I found out this the hard way when I tried include some pre-exisiting MFC code into a windows service. Maybe this was only required if you accepted socket connection - I can't recall? But it did not work! (How exactly I wasted so much time doing this w/o realizing this limitation is a long story)
CObject? If you need the runtime class id stuff use RTTI (dynamic_cast, etc...)
CString, I like CString, I know it's shared with ATL now, not sure if you pull it in w/o MFC or ATL included... You could use std::string. Also, I recall someone created a derived std::string that provided the same methods as CString.
(EDIT: found the code - man!! that's a blast from the past...)
CArchive, CMemFile: do you really need these?
Anyway, as Roel said, ATL may be more helpful. I wouldn't use MFC in a server-side application (ever!) ATL? Maybe. If I needed COM, defiantly. No COM but for CAtlServiceModuleT, etc... maybe....
And another bad thing about MFC in services that I have just experienced while trying to turn a regular MFC-ATL app into a service: The use of AfxConnectionAdvise() is actually useless without a Window procedure. The threads in my service are just regular non message-pumping threads. I believe this is why I never get events fired from another COM server I have developed. That other COM server hangs on Fire_xxxEvent(), causing a big mess in the whole system.
I have a problem I'm trying to solve involving interfaceing a C++ program with Excel (an import interface, specifically). The SheetSelectionChange sounds like it will get me most of the way to where I need to be, but I can't find any good documentation or examples on registering the event, using its Range parameter when it's fired, and unregistering when done. My code currently doesn't use the COM wrapper classes; it issues QueryInterface calls to pick up pointers to the interfaces in Excel.
You need to implement the Excel events interface, and then advise on the Excel connection point. Look at Office Automation Using VC++, more specifically point 7. You can also look at Handle Events for Excel using Visual C++.Net
I'm about to take on a project that requires a Firefox addon to issue call to COM dll's installed on the client Windows machine and I'm having a hard time estimating the complexity of this undertaking.
I have quite a bit of experience with COM, so I'm not frightened by it. I have less experience with Firefox addons, but I don't think that's where my problems are going to be.
Has anybody done anything like that?
Does Firefox allow its addons to communicate freely with the outside world?
Is there a plugin or sample code somewhere that does something like this (Google turned up little useful results)?
Update: Naturally, I would prefer a solution that doesn't require building an extension in C++, if that's at all possible.
Create an XPCOM in C++ to talk to your COM objects as usual. The XPCOM extensions can then be made available to Javascript to do the rest of the extension (GUI mainly, I guess). However, that's about all I understand about it :-)
You might be interested by IE Tab extension, which is open source. I haven't looked but I guess it does Com access to use IE's display.
If you do this you'll almost certainly need to use XPCOM. Take a look at Shanti Rao's JSDB, which supports COM/ActiveX within Javascript. The ActiveX stuff is in a file called wrap_com.cpp. It supports most IDispatch interfaces; the Invoke method of IDispatch is the magic that makes this work.
How complex this is depends on how "easy" you want this to be from Javascript. If you implemented an XPCOM thing called IDispatchObject where you had to pass in the names of methods & an array of arguments, then it's probably not too hard. If you want to create a general method for doing dynamic bindings to COM objects & referring to them directly, then that's tougher... not sure if the techniques used in JSDB will carry over to XPCOM.