Am I the only one having problems due to lack of OLE support?

[Robin Tucker]

It seems that all of the interfaces, such as IDataObject etc. from basic OLE
are no longer supported in .NET, although they are implemented
(differently). I have an OLE object type and am having to make lots of
detours and compromises (and, to be frank, hacks) to get my .NET code to
work with it. For example, because I can't get an IDataObject interface
from my basic OLE object (even though it implements IDataObject), I'm having
to write out temporary files and mess around with a hacked automation
interface instead.

It would have been better, in my opinion, for .NET interop to have supported
vanilla OLE interfaces as well as purely automation interfaces. There are
many instances where one wishes to use OLE but doesn't have a convienient
type library or automation interface.

Rant over.

(p.s. When we have time, we are going to implement a proper Automation
interface for the objects I'm trying to use, but they already work fine
using basic OLE!).

[Jay B. Harlow [MVP - Outlook]]

Robin,
How are you using IDataObject, that the built-in .NET support for the COM
version of IDataObject is not working for you?

If you using the System.Windows.Forms.Clipboard or Windows Forms Drag &
Drop, .NET will translate the COM IDataObject into
System.Windows.Forms.IDataObject, I suspect via a Proxy pattern internal to
the System.Windows.Forms assembly.

It would have been better, in my opinion, for .NET interop to have supported vanilla OLE interfaces as well as purely automation interfaces. I suspect you are missing something, as the entire point of .NET interop is
to support all vanilla OLE interfaces, scientifically better then VB6 can.

I have used .NET interop on both IStorage & Extended MAPI, both vanilla OLE
interfaces.

Granted you may have to sit down and write the interface & helper functions
yourself. I find using Adam Nathan's book ".NET and COM - The Complete
Interoperability Guide" from SAMS press to be invaluable in this regard.

Hope this helps
Jay

"Robin Tucker" <id*************************@reallyidont.com> wrote in
message news:bn*******************@news.demon.co.uk...
It seems that all of the interfaces, such as IDataObject etc. from basic OLE are no longer supported in .NET, although they are implemented
(differently). I have an OLE object type and am having to make lots of
detours and compromises (and, to be frank, hacks) to get my .NET code to
work with it. For example, because I can't get an IDataObject interface
from my basic OLE object (even though it implements IDataObject), I'm having to write out temporary files and mess around with a hacked automation
interface instead.

It would have been better, in my opinion, for .NET interop to have supported vanilla OLE interfaces as well as purely automation interfaces. There are
many instances where one wishes to use OLE but doesn't have a convienient
type library or automation interface.

Rant over.

(p.s. When we have time, we are going to implement a proper Automation
interface for the objects I'm trying to use, but they already work fine
using basic OLE!).

[Robin Tucker]

Thanks for the reply Jay.

Well, I've got an object supporting IDataObject, but sure as hell I cannot
get an interface object for it from VB.

I load the object like this:

Dim theObject As Object = GetObject ( "helloworld.tgw" )

The object loads - its container application is running - now without a type
library I'm somewhat screwed. I know it supports IDataObject, I know it
embeds with Office documents (and anything else supporting OLE), but how the
hell do I get an IDataObject interface pointer? I've tried various methods
including QueryInterface etc. - but I always get exceptions. I don't have a
type library (well I do now, but its a hack and doesn't provide me with
features such as IDataObject would - for example, I've written a DLL to pass
me in HGLOBALS etc, which seems to work, but is very inefficient.

"Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> wrote in message
news:Oq**************@tk2msftngp13.phx.gbl...

Robin,
How are you using IDataObject, that the built-in .NET support for the COM
version of IDataObject is not working for you?

If you using the System.Windows.Forms.Clipboard or Windows Forms Drag &
Drop, .NET will translate the COM IDataObject into
System.Windows.Forms.IDataObject, I suspect via a Proxy pattern internal to the System.Windows.Forms assembly.

It would have been better, in my opinion, for .NET interop to have supported

vanilla OLE interfaces as well as purely automation interfaces.

I suspect you are missing something, as the entire point of .NET interop

is to support all vanilla OLE interfaces, scientifically better then VB6 can.

I have used .NET interop on both IStorage & Extended MAPI, both vanilla OLE interfaces.

Granted you may have to sit down and write the interface & helper functions yourself. I find using Adam Nathan's book ".NET and COM - The Complete
Interoperability Guide" from SAMS press to be invaluable in this regard.

Hope this helps
Jay

"Robin Tucker" <id*************************@reallyidont.com> wrote in
message news:bn*******************@news.demon.co.uk...

It seems that all of the interfaces, such as IDataObject etc. from basic

OLE

are no longer supported in .NET, although they are implemented
(differently). I have an OLE object type and am having to make lots of
detours and compromises (and, to be frank, hacks) to get my .NET code to
work with it. For example, because I can't get an IDataObject interface
from my basic OLE object (even though it implements IDataObject), I'm

having

to write out temporary files and mess around with a hacked automation
interface instead.

It would have been better, in my opinion, for .NET interop to have

supported

vanilla OLE interfaces as well as purely automation interfaces. There are many instances where one wishes to use OLE but doesn't have a convienient type library or automation interface.

Rant over.

(p.s. When we have time, we are going to implement a proper Automation
interface for the objects I'm trying to use, but they already work fine
using basic OLE!).

[Jay B. Harlow [MVP - Outlook]]

Robin,
Sorry for the delay, I was hoping to try and find time to come up with a
more complete example...

You do know that you can define the COM IDataObject interface directly in
VB.NET instead of using type library?

With something like (just a start):

Option Strict On
Option Explicit On

Imports System.Runtime.InteropServices

< _
ComImport(), _
Guid("00000000-0000-0000-0000-000000000000"), _
InterfaceType(ComInterfaceType.InterfaceIsIUnknown ) _

_ Public Interface IDataObject

Sub GetData( _
<[In]()> ByRef ciidExclude As FORMATETC, _
<[Out]()> ByRef pmedium As STGMEDIUM)

...

End Interface

Because it has the InterfaceType attribute, .NET will treat it as an IUnkown
interface, the Sub will automatically convert HRESULT into exceptions. You
will need to define FORMATETC & STGMEDIUM structures. Within the
System.Runtime.InteropServices the MarshalAs attribute is invaluable as it
indicates what type to marshal a field as (such as strings). Also the
Marshal class is invaluable as it has functions to convert HGLOBAL handles
into .NET objects.

Once you have the above interface fully defined, you can simply assign (with
DirectCast) theObject to a variable of the IDataObject type.

Don't forgot to supply the actual IDataObject quid in the above Guid
attribute.

The In & Out before the two parameters above tell the marshaller that the
structures are to be treated as input & output respectively, rather than as
both ways...

As I stated in my earlier email Adam's book is invaluable for implementing
the above.

I find using Adam Nathan's book ".NET and COM - The Complete
Interoperability Guide" from SAMS press to be invaluable in this regard.

Hope this helps
Jay

"Robin Tucker" <id*************************@reallyidont.com> wrote in
message news:bn*******************@news.demon.co.uk... Thanks for the reply Jay.

Well, I've got an object supporting IDataObject, but sure as hell I cannot
get an interface object for it from VB.

I load the object like this:

Dim theObject As Object = GetObject ( "helloworld.tgw" )

The object loads - its container application is running - now without a type library I'm somewhat screwed. I know it supports IDataObject, I know it
embeds with Office documents (and anything else supporting OLE), but how the hell do I get an IDataObject interface pointer? I've tried various methods
including QueryInterface etc. - but I always get exceptions. I don't have a type library (well I do now, but its a hack and doesn't provide me with
features such as IDataObject would - for example, I've written a DLL to pass me in HGLOBALS etc, which seems to work, but is very inefficient.

<<snip>>