Another question for "Interop GURUS"
-
OK, here is the following situation I hoped .NET is capable of resolving simple and elegantly: I'm using COM Interop while exposing my WinForm User Control as an ActiveX control to the system. So, I defined my custom [default] and [default, source] interfaces, placed all methods and events in there and created CoClass like that: [GuidAttribute("C776B7B8-F928-442A-AFB1-2864ECC98166")] [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)] public interface IIn { .... } [GuidAttribute("D776B7B8-F928-442A-AFB1-2864ECC98166")] [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)] public interface IOut { ..... } // Attributes of the class: specify GUID if needed [GuidAttribute("B776B7B8-F928-442A-AFB1-2864ECC98166")] [ComSourceInterfaces(typeof(IOut))] // default source interface [ClassInterface(ClassInterfaceType.None)]// no need for AutoDual, public class ActiveXNet : UserControl, IIn { .... } As you can see, everything is great and it's working, the problem is that exported Type Library has the following sequence in CoClass declaration: [ uuid(B776B7B8-F928-442A-AFB1-2864ECC98166), version(1.0), custom(.....) ] coclass ActiveXNet { interface _Object; interface IComponent; interface IDisposable; [default] dispinterface IIn; <== It's placed at the bottom!!! [default, source] dispinterface IOut; }; So, what a big deal you may ask? The big deal is that another MSFT product which is Developer Studio V6.0 as well as newest V7.0, both still have "small" bug --> when creating ActiveX Control wrappers using MFC (remember those CWnd Derived classes with CreateControl and alot of Invoke Methods). Unfortunately, instead of creating Wrappers for [default] interface those MSFT products are still creating wrapper for the first Interface in the CoClass definition: So, in case of above described ActiveXNet CoClass -- I'm getting wrapped methods of _Object interface... and of course they are of no interest to anybody. If I change class attribute to: [ClassInterface(ClassInterfaceType.AutoDual)] <== AutoDual here: Then I'm getting right layout of CoClass definition in typelibrary: [ uuid(B776B7B8-F928-442A-AFB1-2864ECC98166), version(1.0), custom(.....) ] coclass ActiveXNet { [default] interface _ActiveXNet; <== see here it's the first Interface interface _Object; interface IComponent; interface IDisposable; [defa
-
OK, here is the following situation I hoped .NET is capable of resolving simple and elegantly: I'm using COM Interop while exposing my WinForm User Control as an ActiveX control to the system. So, I defined my custom [default] and [default, source] interfaces, placed all methods and events in there and created CoClass like that: [GuidAttribute("C776B7B8-F928-442A-AFB1-2864ECC98166")] [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)] public interface IIn { .... } [GuidAttribute("D776B7B8-F928-442A-AFB1-2864ECC98166")] [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)] public interface IOut { ..... } // Attributes of the class: specify GUID if needed [GuidAttribute("B776B7B8-F928-442A-AFB1-2864ECC98166")] [ComSourceInterfaces(typeof(IOut))] // default source interface [ClassInterface(ClassInterfaceType.None)]// no need for AutoDual, public class ActiveXNet : UserControl, IIn { .... } As you can see, everything is great and it's working, the problem is that exported Type Library has the following sequence in CoClass declaration: [ uuid(B776B7B8-F928-442A-AFB1-2864ECC98166), version(1.0), custom(.....) ] coclass ActiveXNet { interface _Object; interface IComponent; interface IDisposable; [default] dispinterface IIn; <== It's placed at the bottom!!! [default, source] dispinterface IOut; }; So, what a big deal you may ask? The big deal is that another MSFT product which is Developer Studio V6.0 as well as newest V7.0, both still have "small" bug --> when creating ActiveX Control wrappers using MFC (remember those CWnd Derived classes with CreateControl and alot of Invoke Methods). Unfortunately, instead of creating Wrappers for [default] interface those MSFT products are still creating wrapper for the first Interface in the CoClass definition: So, in case of above described ActiveXNet CoClass -- I'm getting wrapped methods of _Object interface... and of course they are of no interest to anybody. If I change class attribute to: [ClassInterface(ClassInterfaceType.AutoDual)] <== AutoDual here: Then I'm getting right layout of CoClass definition in typelibrary: [ uuid(B776B7B8-F928-442A-AFB1-2864ECC98166), version(1.0), custom(.....) ] coclass ActiveXNet { [default] interface _ActiveXNet; <== see here it's the first Interface interface _Object; interface IComponent; interface IDisposable; [defa
If the IDL has a [default] attribute at the wrong place, I would reopen it using OLEViewer, grab the IDL definition, change it, and recompile the tlb.
-
If the IDL has a [default] attribute at the wrong place, I would reopen it using OLEViewer, grab the IDL definition, change it, and recompile the tlb.
You are "joking", Right?... You mean each time i'm creating ActiveX Assembly supporting COM Interop with AutoDual.None, I should manually after the build go in there grab IDL, goto OleView, export it, edit it, save then run MIDL, then rerregister (possibly resign?)... You are joking, I'm sure! I resolved it by using ICreateTypeLib2, eventhough it was tricky. But my point was: MS talks about perfect CLR future, while still having inherited since about 10years ago bugs here and there, that haven't been fixed. I was surprised recently, that even kernel FindResource function behaves differently on NT, 2000 and XP and doesn't follow documentation. Yes, MSFT fixed IPersistStreamInit interface of WinForm Controls in .NET 1.1 -- however IPesristMemory still doesn't work. IOleObject::SetClientSite returns E... NOT_IMPLEMENTED. BTW: thanx for defending me about 1 year ago from one of the racist IDIOTS. Regards, Igor
-
You are "joking", Right?... You mean each time i'm creating ActiveX Assembly supporting COM Interop with AutoDual.None, I should manually after the build go in there grab IDL, goto OleView, export it, edit it, save then run MIDL, then rerregister (possibly resign?)... You are joking, I'm sure! I resolved it by using ICreateTypeLib2, eventhough it was tricky. But my point was: MS talks about perfect CLR future, while still having inherited since about 10years ago bugs here and there, that haven't been fixed. I was surprised recently, that even kernel FindResource function behaves differently on NT, 2000 and XP and doesn't follow documentation. Yes, MSFT fixed IPersistStreamInit interface of WinForm Controls in .NET 1.1 -- however IPesristMemory still doesn't work. IOleObject::SetClientSite returns E... NOT_IMPLEMENTED. BTW: thanx for defending me about 1 year ago from one of the racist IDIOTS. Regards, Igor
That was an idea to solve the issue. It's true that what you say : "You mean each time i'm creating ActiveX Assembly..." brings a different perspective since it implies you are writing many ActiveX components. The proposed solution is fine if you just do it once. This was more or less implied anyway. igor1960 wrote: I was surprised recently, that even kernel FindResource function behaves differently on NT, 2000 and XP and doesn't follow documentation. I am not surprised, those are 3 rather different codebases. But of course, one feels like insulting MS when the thing to be used doesn't behave the same depending on the underlying OS, and as such requires significant time and work to get around. I am afraid it's got to worsen. Guess what's going to happen when your boss says let's make a Windows.CE compatible version of the software. At the end of the day though, that's what differentiates real great developers from others. Great developers get around those things, because they have the necessary background. igor1960 wrote: BTW: thanx for defending me about 1 year ago from one of the racist IDIOTS. Quite honestly, I don't remember this at all.
-
That was an idea to solve the issue. It's true that what you say : "You mean each time i'm creating ActiveX Assembly..." brings a different perspective since it implies you are writing many ActiveX components. The proposed solution is fine if you just do it once. This was more or less implied anyway. igor1960 wrote: I was surprised recently, that even kernel FindResource function behaves differently on NT, 2000 and XP and doesn't follow documentation. I am not surprised, those are 3 rather different codebases. But of course, one feels like insulting MS when the thing to be used doesn't behave the same depending on the underlying OS, and as such requires significant time and work to get around. I am afraid it's got to worsen. Guess what's going to happen when your boss says let's make a Windows.CE compatible version of the software. At the end of the day though, that's what differentiates real great developers from others. Great developers get around those things, because they have the necessary background. igor1960 wrote: BTW: thanx for defending me about 1 year ago from one of the racist IDIOTS. Quite honestly, I don't remember this at all.
I'm not that often here, but yesterday I've suddenly rediscovered that thread and found your message: http://www.codeproject.com/csharp/CommandBar.asp?target=pavel&df=100&forumid=4006&fr=76#xx273072xx[^] Thanx Anyway, I have not related question. Because it looks like you are more frequent here: How long usually it takes to place an article on CP? I mean, not article you enter youself, but the one you submit through email? The reason I'm asking is: I've emailed my article, which is here: http://members.cox.net/igor.tebelev/ActiveXDeployer.htm[^] about 2 weeks ago... I've got conformation from Chris, but since then nothing happens. I understand it's summer time and etc. Maybe you have any knowledge on how long it usually takes? Regards, Igor
-
I'm not that often here, but yesterday I've suddenly rediscovered that thread and found your message: http://www.codeproject.com/csharp/CommandBar.asp?target=pavel&df=100&forumid=4006&fr=76#xx273072xx[^] Thanx Anyway, I have not related question. Because it looks like you are more frequent here: How long usually it takes to place an article on CP? I mean, not article you enter youself, but the one you submit through email? The reason I'm asking is: I've emailed my article, which is here: http://members.cox.net/igor.tebelev/ActiveXDeployer.htm[^] about 2 weeks ago... I've got conformation from Chris, but since then nothing happens. I understand it's summer time and etc. Maybe you have any knowledge on how long it usually takes? Regards, Igor
igor1960 wrote: yesterday I've suddenly rediscovered that thread and found your message Oh, that was a spicy thread ! ;) igor1960 wrote: How long usually it takes to place an article on CP? It usually takes one week. Unfortunately, Chris is currently in Redmond (if I understood well) so the article processing gets somewhat deferred one week or so. Once the article gets in the pipe, that is once Chris has reached your email out of his billions emails, then you will be sent an automated email. Once you have this email, it takes a few days before it gets edited by the editors and actually gets posted. Should be posted soon now.