Variant data types in .Net

[Gordon Garnsey]

I have a COM addin running under Excel. It uses variant data types to read and write arrays of data to the screen at high speed. I am investigating upgrading to .Net via the 'Visual Studio Tools for the Microsoft Office
System'. I understand that .Net does not allow the variant data type. Is this a problem and if so, is there a workaround?

 

[Cindy M -WordMVP-]

Hi =?Utf-8?B?R29yZG9uIEdhcm5zZXk=?=,

I have a COM addin running under Excel. It uses variant data types to read and write

arrays of data to the screen at high speed. I am investigating upgrading to .Net via the
'Visual Studio Tools for the Microsoft Office

System'. I understand that .Net does not allow the variant data type. Is this a problem

and if so, is there a workaround?NET does not provide a Variant datatype; when the datatype is uncertain, it must be
declared as an OBJECT.

If you're considering re-writing, however, you can use and pass arrays as array or
arraylist objects. This is something VB(A) doesn't have, and it's pretty cool Also
very easy to use. (Arrays are much like the arrays you're already familiar with; array
lists are more like collections)

If speed is an issue for you, it's only fair to warn you that automating a COM
application (such as any Office app) through .NET is going to be much slower. The things
NET has to do within the framework could be a lot faster than you're getting in your COM
Addin. But anything that has to be done on the COM side will probably be much slower.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Sep 30 2003)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or reply in the
newsgroup and not by e-mail

 

[Gordon Garnsey]

Thanks Cindy
Could you please clarify the final paragraph where you describe ''the things .NET has to do within the framework" as opposed to things that have "to be done on the COM side"
Am I correct in assuming that the things on the COM side are the various procedures found within the designer module, whereas things in the framework are in relation to my code proper
Gordon

 

[Cindy M -WordMVP-]

Hi =?Utf-8?B?R29yZG9uIEdhcm5zZXk=?=,

Could you please clarify the final paragraph where you describe ''the things .NET has to

do within the framework" as opposed to things that have "to be done on the COM side"?Anything your code does that doesn't need to "communicate" with the COM application you're
automating ("within the Framework") vs. controlling something in a COM interface.

As long as you're processing your arrays, and displaying the result in (for example) a
Windows Form, you're within the Framework. As soon as you would write the values to an
Excel sheet (for example), you're going through COM.

The first will be fast; the second will be comparatively slow (slower than using a COM
Addin written in VB6).

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Sep 30 2003)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or reply in the
newsgroup and not by e-mail