DAS1108

Hi,

I want to create an C# COM server which will be visible at "Insert Object" in Excel. I found many examples how to create an C# class and use it from VBA. But what I have to do that I can insert such a C# class within an Excel sheet directly without VBA

Of course I need to implement some additional interfaces, but which ones and how in C#.

Thanks.

Daniel




Re: Visual Studio Tools for Office C# COM server visible in Excel "Insert Object..."

Ji Zhou ¨C MSFT

Hi,

Could you be a little more specific about what you want to achieve. Create your own file type that can be listed in Insert Object Dialog Based on my experience, I did not think there is any interface can help use to custom that, via VSTO.

But what about create your own ActiveX control, which can display your file

Thanks

Ji






Re: Visual Studio Tools for Office C# COM server visible in Excel "Insert Object..."

DAS1108

Hi Ji,

first of all I have to support Office 2000 to Office XP and further, so I think VSTO is not the right solution, isn't it

Using "Insert Object ..." allows you to insert ActiveX objects onto your Excel sheet or into your Word document, e.g. a bitmap, a PDF or calendar control.

I managed to build an ActiveX control with C# and insert this control in VS ActiveX Container application. But this control is not visible at "Insert object..." in Excel/Word (like many other controls too). What is the "magic" that makes an control visible at "Insert object..."

Especially I want to create a business chart control which visualize cells in Excel. Then I want to send this Excel file to other persons around the world. Perhaps they don't have installed my business chart ActiveX, But they should see the chart (as bitmap ). But this is step two!

Please let me know if you need some addtional information.

Thanks

Daniel






Re: Visual Studio Tools for Office C# COM server visible in Excel "Insert Object..."

Cindy Meister

I don't know the details (but then, you are way off-topic here as the forum is specific for VSTO), but it has to do with the Registry. If you take a look in the Class Root part of the Registry, you'll see that everything in that list is registered in a certain way. All the entries have to OLE Servers, for one thing - there has to be an application available to support OLE automation.

A better place to pursue this might be the dotnet.framework.interop newsgroup where you'll find people who deal with ".NET in the COM world".

http://msdn.microsoft.com/newsgroups/default.aspx dg=microsoft.public.dotnet.framework.interop&lang=en&cr=US






Re: Visual Studio Tools for Office C# COM server visible in Excel "Insert Object..."

DAS1108

Hi Cindy,

thanks for that hint, but I was moved into this group by another MSVP. It wasn't my idea. Sorry.

I will check the INTEROP newsgroup

Daniel






Re: Visual Studio Tools for Office C# COM server visible in Excel "Insert Object..."

X4U

Hello Daniel,

as I know it isn't possible to Create a "Real" Active-X Control with .Net technology.

We had a disscussion about this here.

http://www.outlookcode.com/threads.aspx forumid=5&messageid=13227

http://blogs.msdn.com/johnrdurant/archive/2005/08/10/net_to_activex.aspx

To make a COM ActiveX Control visible to other applications you have to create some additional Registry Keys.

The Control has to be signed and some attributes [COMVisible] set for the class.

Then when you got it managed to see your control in the insert Dialog, and insert it into an "OldStyle" unmanaged application, you will reveive an exception as soon as the control is resized, because the behavior of an ActiveX Control and an .Net Control is different.

But the best approach for you I think is:

Create an AddIn, and then get the Cell hWnd and use that as Parent for your .Net Control.

You can pass a Parent wnd for a .Net Form as IWin32Window Interface.

see

http://www.outlookcode.com/codedetail.aspx id=1427

This should work.

Hope this helps,

greets, Helmut






Re: Visual Studio Tools for Office C# COM server visible in Excel "Insert Object..."

Geoff Darst - MSFT

Hi Helmut and Daniel,

To jump in here, it is absoutely possible to create a true ActiveX control (or an in-place active COM server) using .Net code. It is a tremendous amount of work, but it can be done. In fact, Windows Forms controls are ActiveX controls and may be hosted in the Visual C++ control container or in Internet Explorer. If they hadn't missed implementing a few interfaces, they would have worked just fine in Office as well. (But they did miss interfaces and a few other things as well, which is why you shouldn't ever try to use them outside of the two supported containers).

To be sure doing this is non-trivial and you must have a very solid understanding of ActiveX, Com Interop, and P/Invoke, but it is possible. If you have the requisite skills to develop a native ActiveX control (by hand, not using the CDK), you shouldn't have too much trouble developing a managed ActiveX control. On the other hand, the amount of extra work required might prove to make the endeavor too costly when weighed against the benefits you expect to obtain by developing in .Net. For that reason, you should have a very clear understanding of what you expect to gain by developing in .Net rather than just building the component using native code.

In addition, the spec for Ole control containers wasn't tight enough, so you may well still encounter issues where your control works in one container, but not in others. This is why ActiveX controls never really caught on--controls that would work in VB 6, wouldn't work in Office and vice-versa. In the case of Helmut's Outlook example, I wouldn't expect WinForms controls to work, but if somebody wanted to make the effort, they could write a managed ActiveX control from scratch tailored to the Outlook container to solve the sizing issues. As I said, containers are the real problem and you might need to possess really outstanding debugging skills to enable your control to work on a container that you didn't own.

If you really want to try to write an in-place active COM server (or a full ActiveX control), your best bet would be to find a copy of Kraig Brockschmidt's book, "Inside OLE 2". Unfortunately, it is out of print, but it is absolutely the best resource on any of the more advanced OLE technologies such as in-place activation and OLE controls. It will enumerate all of the interfaces you need along with sample implementations.

To get an idea of the scope of the undertaking, here are the required interfaces.

IOleObject

IOleInPlaceObject

IOleInPlaceActiveObject

IDataObject

IViewObject2

IPersist[Storage | Stream | StreamInit]

IClassFactory[2]

You might also need:

IOleCache2

IRunnableObject

ISpecifyPropertyPages

IConnectionPointContainer

IDispatch

IProvideClassInfo

IOleControl

There are also a couple of interaces that got added in the OCX96 spec that I can't remember right now, but they would be required if you wanted to implement a windowless control, or optimize activation or redraws...

Anyway, you get the idea. Without Brockschmidt's book, you will have a tough go of it.

IIRC to get your component to show up in the insert dialog, you need to register it as Insertable. See: http://msdn2.microsoft.com/en-us/library/ms678483.aspx

Sincerely,

Geoff Darst

Microsoft VSTO Team





Re: Visual Studio Tools for Office C# COM server visible in Excel "Insert Object..."

DAS1108

Hi Geoff,

thank you very much for your helpful reply. That is really a good start. Now I have to go the next step and find a way to implement required interfaces in C#.

Thanks to all replies.

Cheers

Daniel






Re: Visual Studio Tools for Office C# COM server visible in Excel "Insert Object..."

Geoff Darst - MSFT

Hi Daniel,

You'll want to start with the Win32 SDK header files. ojbidl.h should have most of the interfaces, guids and structures that you need. You'll need to create P/Invoke declarations for all of them (which is why doing this in managed code is so much work). Once you get your P/Invoke declarations written, I would stub out the full control and start testing it immediately (you'll at least be able to start validating your P/Invoke declarations are correct). If you don't have source access for a control container, I would download the TESTCON sample and use it as the starting point for testing your control. You can find it here: http://msdn2.microsoft.com/en-us/library/f9adb5t5(VS.80).aspx

Depending on what you want to accomplish, you might also consider using Managed C++. With Managed C++, you can simultaneously reference both native and managed types. So you could have a mixed-mode assembly that had native stubs for these interfaces, but actually implemented them with managed code. If you are proficient in C++, this might be a good compromise because it would save you all of the overhead of creating the P/Invoke declarations.

Sincerely,

Geoff Darst

Microsoft VSTO Team





Re: Visual Studio Tools for Office C# COM server visible in Excel "Insert Object..."

DAS1108

Hi Geoff,

that is a great idea to build in Managed C++. In this Managed C++ class I could instantiate a C# .NET class, which is doing the most of the job. This Managed C++ code is acting like a stub then.

Geoff, thanks for your replies. This is like a kick in the right direction.

Regards

Daniel