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
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 am currently using an in-process COM server (Outlook Redemption) in my application and I need to convert it to work out-of-process, I'm using C++ Builder.
From what I've read so far, I believe I need to create the new COM server as a .exe, but how do I do that? and how do I make all the the existing functions visible? Can that be done automatically via the existing TLB or do I have to create wrappers around all the functions that I will need?
Any guidance to put me on the right track would be really welcome.
Edit: If anyone is able to explain the process for Delphi instead, I'm sure I'd be able to adapt it.
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 have seen many links that talk about 32feet.NET library. I need to know how to use this in C#. Pretty much everything uses Visual Basic but I am not too familiar with that language. I do prefer to do it C#. As additional information, the application will be sending data similar to a serial interface. This means that it will be sending bytes to a device that will respond with bytes as well. I am trying to use the built-in bluetooth but I cannot find the port associated with that nor am I able to detect it using other examples online, I have tried the Power Shell example as well.
The thinking was when I wrote the documentation was that there were a lot of VB users using the library, and that all C# users would be able to read the VB code, even if they weren't able to write VB themselves. See http://32feet.codeplex.com/wikipage?title=Visual%20Basic%20Samples for some help.
Have a go at looking at the examples and see if you can pick out the real code in there -- I myself find it hard to ignore the If, Then, End etc words but can manage it. I've just updated the main pages to include C# versions of the samples, when I have some more free time I'll do some more. :-)
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.