Creating OCX files

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Can anyone point me to a primer for creating OCX controls in VB .net? In particular, I want to access a web service in a VB6 application (not an easy thing to do). So, if I can write an ActiveX control that accomplishes this in .Net, then I SHOULD be able to add the OCX component to my VB6 app and use it. Unless someone knows why this wouldn't work....

Any and all help is appreciated.
 
¤ Can anyone point me to a primer for creating OCX controls in VB .net? In particular, I want to access a web service in a VB6 application (not an easy thing to do). So, if I can write an ActiveX control that accomplishes this in .Net, then I SHOULD be able to add the OCX component to my VB6 app and use it. Unless someone knows why this wouldn't work.....
¤
¤ Any and all help is appreciated.

You cannot create COM components with .NET. You have to use the SOAP toolkit with VB 6.0 to access
the web service:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/migrsoapwebserv.asp


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
Hi,

Paul Clement said:
You cannot create COM components with .NET
Click to expand...

This is not true. You can create COM components with .Net. CCW (COM Callable
Wrapper) is provided by .Net for COM interop. See:
http://msdn.microsoft.com/library/e...ingcomcomponentstonetframework.asp?frame=true.
Main interop problem with COM clients not aware about .Net (like VB6) is
that they don't call CorExitProcess (exported by MSCOREE.dll). That in order
means that CLR doesn't terminate properly and among other problems means
that Finalizers will not be run on unmanaged proccess terminate. Last is
because without a call to CorExitProcess, the CLR is only notified that the
process is shutting down from DllMain's process detach notification. The
loader lock is held at this point, so there is no way that finalization code
can safely run.
However, if you can live with out-proc COM calls - implement your .Net
object as descendant of System.EnterpriseServices.ServicedComponent and
register it to run in COM+ Server Application - the rest is as usual and
COM+ services would take care about correct termiation of CLR.

However, in the original question author is asking about OCXs...
To implement OLE control (which is OCXs really are) with .Net is much
trickier, but still doable and only requires you implementing all necessary
OLE interfaces on your .Net object. After that - it should be possible to
use you .Net object as OCX... but problem of OLE control container not
calling CorExitProcess still remains.

-Valery.

http://www.harper.no/valery
 
¤ Hi,
¤
¤ "Paul Clement" wrote:
¤ > You cannot create COM components with .NET
¤
¤ This is not true. You can create COM components with .Net. CCW (COM Callable
¤ Wrapper) is provided by .Net for COM interop. See:
¤ http://msdn.microsoft.com/library/e...ingcomcomponentstonetframework.asp?frame=true.

A COM callable wrapper is not a COM component. It is the interface communication (or interop) layer
between COM and .NET managed code.

¤ Main interop problem with COM clients not aware about .Net (like VB6) is
¤ that they don't call CorExitProcess (exported by MSCOREE.dll). That in order
¤ means that CLR doesn't terminate properly and among other problems means
¤ that Finalizers will not be run on unmanaged proccess terminate. Last is
¤ because without a call to CorExitProcess, the CLR is only notified that the
¤ process is shutting down from DllMain's process detach notification. The
¤ loader lock is held at this point, so there is no way that finalization code
¤ can safely run.
¤ However, if you can live with out-proc COM calls - implement your .Net
¤ object as descendant of System.EnterpriseServices.ServicedComponent and
¤ register it to run in COM+ Server Application - the rest is as usual and
¤ COM+ services would take care about correct termiation of CLR.
¤
¤ However, in the original question author is asking about OCXs...
¤ To implement OLE control (which is OCXs really are) with .Net is much
¤ trickier, but still doable and only requires you implementing all necessary
¤ OLE interfaces on your .Net object. After that - it should be possible to
¤ use you .Net object as OCX... but problem of OLE control container not
¤ calling CorExitProcess still remains.
¤

Well actually he wants to create an OCX control in VB.NET that he can use in VB 6.0. You can't
create (COM) OCX controls in .NET so this isn't possible.


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
Paul Clement said:
A COM callable wrapper is not a COM component.
It is the interface communication (or interop) layer
between COM and .NET managed code.
Click to expand...

Well, I believe that some historical overview should be provided here.

COM objects and components take their origins from OLE 2.0 spec. OLE 2.0
spec. was a mix of everything related to Object Linking and Embedding (OLE)
and (new for OLE 2.0) OLE controls architecture. Since OLE and OLE controls
are COM based, COM definition was given by the same OLE 2.0 spec as well.
About 2-3 years later an attempt was made to move basic parts of COM
technologies in their own COM specification, without mentioning all OLE and
controls related stuff. Approximately the same time another group inside
Microsoft worked with OLE controls 95 specification that first used word
"component". Some times later OLE Controls 95 was renamed to ActiveX
controls.



According to the COM spec, COM object definition could be given following
way:

COM object is a program unit that implements IUnknown interface. COM spec
also provided description of binary layout (just standard C++ vtables
structure of IUnknown) that actually meant implementation IUnknown interface
plus it defined extra rules for parameters conversion and similar.

OLE Controls 95 spec (the origins of ActiveX controls) defined lightweight
OLE controls with only requirement that contol must implements IUnknown. It
was a big difference to classical OLE controls that required more than a
dozen interfaces with non-trivial protocol implementation. The same OLE
Controls 95 spec first used word "component" for describing these
lightweight OLE controls. The only addition for allowing COM object to be
called "COM component" is requirement of it create-ability. Ie. it "COM
component" COM object should be implemented together with another COM object
that implements IClassFactory interface and retiring an instance of COM
component from its implementation of IClassFactory::CreateInstance method.



..Net COM callable wrapper provides implementation of IUnknown interface.
..Net interop also provides implementation of IClassFactory interface for
using it from COM clients. You can use Regasm utility for registering your
..Net component for use from COM client application. You can also register
your .Net object as COM+ component that by its definition is also COM
component.



Your statement that one can't create COM components in .Net was TOTALLY
WRONG.

Please, take my word of advice and not argue with me about the subjects
related to COM and OLE as you don't have sufficient knowledge for that. If
you need background information regarding my familiarity with the subject,
please make a simple search for my name in Microsoft DCOM and ATL mailing
list archives. As well as you can search developmentors DOTNET (retired)
mailing list archives for background information about my knowledge of .Net
and COM interop related.



-Valery.
 
...
Your statement that one can't create COM components in .Net was TOTALLY
WRONG.

Please, take my word of advice and not argue with me about the subjects
related to COM and OLE as you don't have sufficient knowledge for that. If
you need background information regarding my familiarity with the subject,
please make a simple search for my name in Microsoft DCOM and ATL mailing
list archives. As well as you can search developmentors DOTNET (retired)
mailing list archives for background information about my knowledge of
.Net and COM interop related.
Click to expand...

Well, here is just a couple quick links to some items in the list archives:
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0201B&L=DCOM&P=R7329
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0006E&L=ATL&P=R13714
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0103D&L=DCOM&P=R346
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0005C&L=ATL&P=R4263

-Valery.

See my blog at:
http://www.harper.no/valery
 
¤ "Paul Clement" wrote:
¤ > A COM callable wrapper is not a COM component.
¤ > It is the interface communication (or interop) layer
¤ > between COM and .NET managed code.
¤
¤ Well, I believe that some historical overview should be provided here.
¤
¤ COM objects and components take their origins from OLE 2.0 spec. OLE 2.0
¤ spec. was a mix of everything related to Object Linking and Embedding (OLE)
¤ and (new for OLE 2.0) OLE controls architecture. Since OLE and OLE controls
¤ are COM based, COM definition was given by the same OLE 2.0 spec as well.
¤ About 2-3 years later an attempt was made to move basic parts of COM
¤ technologies in their own COM specification, without mentioning all OLE and
¤ controls related stuff. Approximately the same time another group inside
¤ Microsoft worked with OLE controls 95 specification that first used word
¤ "component". Some times later OLE Controls 95 was renamed to ActiveX
¤ controls.
¤
¤
¤
¤ According to the COM spec, COM object definition could be given following
¤ way:
¤
¤ COM object is a program unit that implements IUnknown interface. COM spec
¤ also provided description of binary layout (just standard C++ vtables
¤ structure of IUnknown) that actually meant implementation IUnknown interface
¤ plus it defined extra rules for parameters conversion and similar.
¤
¤ OLE Controls 95 spec (the origins of ActiveX controls) defined lightweight
¤ OLE controls with only requirement that contol must implements IUnknown. It
¤ was a big difference to classical OLE controls that required more than a
¤ dozen interfaces with non-trivial protocol implementation. The same OLE
¤ Controls 95 spec first used word "component" for describing these
¤ lightweight OLE controls. The only addition for allowing COM object to be
¤ called "COM component" is requirement of it create-ability. Ie. it "COM
¤ component" COM object should be implemented together with another COM object
¤ that implements IClassFactory interface and retiring an instance of COM
¤ component from its implementation of IClassFactory::CreateInstance method.
¤
¤
¤
¤ .Net COM callable wrapper provides implementation of IUnknown interface.
¤ .Net interop also provides implementation of IClassFactory interface for
¤ using it from COM clients. You can use Regasm utility for registering your
¤ .Net component for use from COM client application. You can also register
¤ your .Net object as COM+ component that by its definition is also COM
¤ component.
¤
¤
¤
¤ Your statement that one can't create COM components in .Net was TOTALLY
¤ WRONG.
¤
¤ Please, take my word of advice and not argue with me about the subjects
¤ related to COM and OLE as you don't have sufficient knowledge for that. If
¤ you need background information regarding my familiarity with the subject,
¤ please make a simple search for my name in Microsoft DCOM and ATL mailing
¤ list archives. As well as you can search developmentors DOTNET (retired)
¤ mailing list archives for background information about my knowledge of .Net
¤ and COM interop related.

Your last sentence confirms my previous statements, so I have no idea what the dispute is.

..NET generates managed code assemblies that execute within its framework. It does not generate COM
executables. The fact that you can use utilities to create COM interfaces to .NET assemblies is
irrelevant. The executing code is managed by the framework. COM does not execute from within the
framework.

Whether you can *access* COM components via .NET, or .NET components via COM is a topic relating to
interop between managed and unmanaged code.

If you believe that an OCX can be created in VB.NET, which was the question posted, then you're
certainly welcome to provide the steps to do so.


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
¤ Can anyone point me to a primer for creating OCX controls in VB .net? In particular, I want to access a web service in a VB6 application (not an easy thing to do). So, if I can write an ActiveX control that accomplishes this in .Net, then I SHOULD be able to add the OCX component to my VB6 app and use it. Unless someone knows why this wouldn't work.....
¤
¤ Any and all help is appreciated.

I probably should have added that you can still use SOAP from your VB 6.0 application to communicate
with your web service:

Migrating from the SOAP Toolkit to Web Services
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/migrsoapwebserv.asp


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
OCX != COM component. OCX == OLE Control (original OLE 2.0 control that
required IOleObject, IOleControl, IOleView ++). COM component requires
IUnkown only (check the specs if you don't believe me). If you can read -
read my previous post, and then go check docs, if you still have problems
with it.

As extra example for you: COM+ component is by definition a COM component
that is registered with COM+ catalog. Can you create COM+ components with
..Net? (hint check System.EnterpriseServices.ServicedComponent).

and yes, even OCX can be created with .Net. I have tried and succeeded in
developing ActiveX document server in .Net. Its about the same complexity
level as OCX. With OCX you just need to implement IOleControl instead of
IOleDocument... You still could experience some problems (see: [*]) with
using OCX implemented in .Net from VB6 or other .Net unaware COM clients,
but that is irrelevent when we just talk about wheter it possible or not.

-Valery.

http://www.harper.no/valery

[*] the problems that I'm talking about is that COM clients not aware about
..Net (like VB6) don't call CorExitProcess exported by MSCOREE.dll. That in
order means that CLR doesn't terminate properly and among other problems
means that Finalizers will not be run on unmanaged proccess terminate. Last
is
because without a call to CorExitProcess, the CLR is only notified that the
process is shutting down from DllMain's process detach notification. The
loader lock is held at this point, so there is no way that finalization code
can safely run.
 
¤ OCX != COM component. OCX == OLE Control (original OLE 2.0 control that
¤ required IOleObject, IOleControl, IOleView ++). COM component requires
¤ IUnkown only (check the specs if you don't believe me). If you can read -
¤ read my previous post, and then go check docs, if you still have problems
¤ with it.

The implementation of COM involves more than simply the use of IUnknown. If also follows a binary
standard that is distinctly different than the .NET implementation.

OLE 2.0 was based upon COM. An OCX is based upon COM. None of the above can be generated with .NET.

¤
¤ As extra example for you: COM+ component is by definition a COM component
¤ that is registered with COM+ catalog. Can you create COM+ components with
¤ .Net? (hint check System.EnterpriseServices.ServicedComponent).

You can create .NET components that run under the COM+ host process. It doesn't make them COM
components. The System.EnterpriseServices.ServicedComponent class provides the interface to
interoperate with COM+. But the bottom line is that you're still generating a managed code assembly
which is in no way consistent with the COM binary standard.


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
Paul,
you have very big problem with your terminology here. Not speaking about
your knowledge of OLE, COM, ActiveX and COM+ is apparently rather limited.

you write:
You cannot create COM components with .NET
Click to expand...

This is totally wrong, because both CCW and COM+ component are 100% good and
valid COM components accordingly to all respective specifications.

Your use of "COM component" is different that it actually defined by
respective specifications and you apparently using it interchangingly with
OCX. But even with this meaning you are still wrong because OCX could be
implemented with .Net. I actually implemented working in-process ActiveX
document server with C# about a year ago. And OCX isn't very different
story, it is just to implement IOleControl instead of IOleDocument. I know
what I'm talking about here, because I implemented quite a lot of OCXs,
ActiveX document/containers, OLE control containers and similar with C++
(both plain C++ and ATL) back in 90th.
Please, don't talk about COM binary standard, calling convention and
similar - you are not qualified.
I have implemented working apartment neutral proxy back in 1999 (the only
existing implementation of apartment neutral proxy to my knowledge). It
provides transparent proxy for arbitrary COM interface that could be called
from any apartment without marshaling, because proxy does all the marshaling
stuff on the fly when necessary.

Here is the link to source code together with binary:
http://www.harper.no/valery/oldsite/ApartmentNeutralProxy.zip
check the source and if you still not convinced - I don't know what else to
say.

-Valery.
(Windows SDK MVP since 2000 btw)

http://www.harper.no/valery
 
¤ Paul,
¤ you have very big problem with your terminology here. Not speaking about
¤ your knowledge of OLE, COM, ActiveX and COM+ is apparently rather limited.
¤
¤ you write:
¤ >You cannot create COM components with .NET
¤
¤ This is totally wrong, because both CCW and COM+ component are 100% good and
¤ valid COM components accordingly to all respective specifications.
¤
¤ Your use of "COM component" is different that it actually defined by
¤ respective specifications and you apparently using it interchangingly with
¤ OCX. But even with this meaning you are still wrong because OCX could be
¤ implemented with .Net. I actually implemented working in-process ActiveX
¤ document server with C# about a year ago. And OCX isn't very different
¤ story, it is just to implement IOleControl instead of IOleDocument. I know
¤ what I'm talking about here, because I implemented quite a lot of OCXs,
¤ ActiveX document/containers, OLE control containers and similar with C++
¤ (both plain C++ and ATL) back in 90th.

And that has nothing to do with .NET. If you can't make the distinction between a managed code
assembly and an unmanaged binary executable standard, then there is no point in taking this
discussion any further.

¤ Please, don't talk about COM binary standard, calling convention and
¤ similar - you are not qualified.

Oh please. This was documented by Microsoft back in 1994. You will have to tell Microsoft they are
not qualified.

OLE Component Design Issues
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg/html/msdn_comdsgn.asp

¤ I have implemented working apartment neutral proxy back in 1999 (the only
¤ existing implementation of apartment neutral proxy to my knowledge). It
¤ provides transparent proxy for arbitrary COM interface that could be called
¤ from any apartment without marshaling, because proxy does all the marshaling
¤ stuff on the fly when necessary.
¤
¤ Here is the link to source code together with binary:
¤ http://www.harper.no/valery/oldsite/ApartmentNeutralProxy.zip
¤ check the source and if you still not convinced - I don't know what else to
¤ say.

As I mentioned before, the poster of the question was looking for a way to create an OCX in .NET to
use from his VB 6.0 app to access a web service. If it is possible, as you say, then feel free to
provide an example.


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
Well, you've just shown that there is no point to continue that discussion
with you any further. What the point arguing with you when you simply repeat
yourself over and over again without even trying to read my arguments and
admit your mistakes...



-Valery.

http://www.harper.no/valery



Paul Clement said:
On Fri, 7 May 2004 21:44:27 +0200, "Valery Pryamikov"

¤ Paul,
¤ you have very big problem with your terminology here. Not speaking about
¤ your knowledge of OLE, COM, ActiveX and COM+ is apparently rather
limited.
¤
¤ you write:
¤ >You cannot create COM components with .NET
¤
¤ This is totally wrong, because both CCW and COM+ component are 100% good
and
¤ valid COM components accordingly to all respective specifications.
¤
¤ Your use of "COM component" is different that it actually defined by
¤ respective specifications and you apparently using it interchangingly
with
¤ OCX. But even with this meaning you are still wrong because OCX could be
¤ implemented with .Net. I actually implemented working in-process ActiveX
¤ document server with C# about a year ago. And OCX isn't very different
¤ story, it is just to implement IOleControl instead of IOleDocument. I
know
¤ what I'm talking about here, because I implemented quite a lot of OCXs,
¤ ActiveX document/containers, OLE control containers and similar with C++
¤ (both plain C++ and ATL) back in 90th.

And that has nothing to do with .NET. If you can't make the distinction
between a managed code
assembly and an unmanaged binary executable standard, then there is no
point in taking this
discussion any further.

¤ Please, don't talk about COM binary standard, calling convention and
¤ similar - you are not qualified.

Oh please. This was documented by Microsoft back in 1994. You will have to
tell Microsoft they are
not qualified.
Click to expand...

What Microsoft document are you refering here? OLE2.0 spec is a bit older
than that, but COM spec and OLE Controls 95 spec is a bit yonger than that?
Did you actually read Microsoft OLE specs? Or COM spec? Or OLE Controls 95
spec? I really doubt it.
 
OLE Component Design Issues
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg/html/msdn_comdsgn.asp
Click to expand...

This article of Charlie Kindel is not a formal specification and it doesn't
even provide any definition of COM component.
COM component definition is provided in COM specification (and number of
other formal specifications).
Charlie's (or Microsoft's) competence is not a question here. The question
that I stated was that your competence is not sufficient to argue about this
subject. Every single message you sent to our discussion only have proved my
point.

If you manage to find any place in this or any other document that says that
COM component is in fact OCX - show it to me.
If you manage to find any place that says that COM+ component is not COM
component - show it to me.
If you manage to find any place that says that CCW is not COM component -
show it to me.

I'm more than aware about binary standards that is defined by COM
specification. As a prove I've sent you a reference to code that I developed
several years ago that relied on my knowledge of vtable structure, calling
convention, and more. Can you show similar prove to me?
I also repeat myself for the third time here: a year ago I've developed
ActiveX document server in C#.
Do you know what is ActiveX document server?

-Valery.
http://www.harper.no/valery
 
Lets make short retrospective of what you wrote in your posts to this
thread:
On Tuesday, May 04, 2004 4:35 PM Paul Clement wrote:
You cannot create COM components with .NET.
Click to expand...
On Wednesday, May 05, 2004 3:59 PM Paul Clement wrote:
A COM callable wrapper is not a COM component.
It is the interface communication (or interop) layer
between COM and .NET managed code.
Click to expand...
On Friday, May 07, 2004 5:04 PM Paul Clement wrote:
.NET generates managed code assemblies that execute within
its framework. It does not generate COM executables.
between COM and .NET managed code.
Click to expand...
On Friday, May 07, 2004 9:08 PM Paul Clement wrote:
You can create .NET components that run under the COM+
host process. It doesn't make them COM components.
Click to expand...
</excerpt4>

Now let us check COM specification.
<excerpt src=" Chapter 3. Objects and Interfaces. 1.1.1 The Interface Binary
Standard">
The interface structure: a client has a pointer to an interface which is a
pointer to a pointer to an array (vtable) of pointers to the object's
implementation.
On Microsoft's 16-bit Windows platform, this default is the __far __cdecl
calling convention; on Win32 platforms, the __stdcall calling convention is
the default for methods which do not take a variable number of arguments,
and __cdecl is used for those that do.
Finally, and quite significantly, all strings passed through all COM
interfaces (and, at least on Microsoft platforms, all COM APIs) are Unicode
strings.
</excerpt>
<excerpt src=" Chapter 3. Objects and Interfaces. 1.6 Designing and
Implementing Objects">
In all cases there is only one requirement for all objects: implement at
least the IUnknown interface. An object is not a COM object unless it
implements at least one interface which at minimum is IUnknown.
</excerpt>
COM specification uses components and objects interchangeably. Example:
Cahpter 3. Objects and Interfaces 1.3.2 Reference Counting, Rule 2d uses
"component" in rule text and "object" in illustration.
Many more examples of interchangeable use of "components" and "objects" by
the authors of COM specification could be provided on request.

All quotations from your posts to that thread (see top of this post) are
COMPLETELY WRONG. They simply show your incompetence when it concerns COM,
COM+, .Net interop. I can provide more quotes from your posts to that thread
that also proves that point.

-Valery.

http://www.harper.no/valery
 
¤ All quotations from your posts to that thread (see top of this post) are
¤ COMPLETELY WRONG. They simply show your incompetence when it concerns COM,
¤ COM+, .Net interop. I can provide more quotes from your posts to that thread
¤ that also proves that point.
¤
¤ -Valery.

Nice chatting with you Valery, but I have no interest in responding to personal attacks or your
continued side stepping of the original question.

People reading this can come to their own conclusions, but you might help your cause a bit by
providing an example that would address the question (which I'm now asking for the third time).

Baiting me with ad hominem comments is useless. ;-)


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
Nice chatting with you Valery, but I have no interest in responding to
personal attacks or your
continued side stepping of the original question.
Click to expand...

Sorry, for being rude. I just reacted on mistakes you made in your first
message, but you didn't let it go and add even more mistakes in conversation
in addition accusing me that I "can't make the distinction between a managed
code
assembly and an unmanaged binary...".

Anyway, my appoligies.
but you might help your cause a bit by
providing an example that would address the question.
Click to expand...

Well, I will do it when I'll get some spare time.
(unfortunately I can't use code of my C# ActiveX document server that I
implemented for my former employer)

-Valery.
http://www.harper.no/valery
 
¤ > Nice chatting with you Valery, but I have no interest in responding to
¤ > personal attacks or your
¤ > continued side stepping of the original question.
¤
¤ Sorry, for being rude. I just reacted on mistakes you made in your first
¤ message, but you didn't let it go and add even more mistakes in conversation
¤ in addition accusing me that I "can't make the distinction between a managed
¤ code
¤ assembly and an unmanaged binary...".
¤
¤ Anyway, my appoligies.

Fair enough.

¤
¤ > but you might help your cause a bit by
¤ > providing an example that would address the question.
¤
¤ Well, I will do it when I'll get some spare time.
¤ (unfortunately I can't use code of my C# ActiveX document server that I
¤ implemented for my former employer)

Maybe not the code, but I'm sure you can re-use the idea in a different
implementation. ;-)


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
Stevewrote:
Can anyone point me to a primer for creating OCX controls in VB .net?
In particular, I want to access a web service in a VB6 application
(not an easy thing to do). So, if I can write an ActiveX control
that accomplishes this in .Net, then I SHOULD be able to add the OCX
component to my VB6 app and use it. Unless someone knows why this
wouldn't work.....
 
Hi,
There is no easy way of making it working. Even so, simply adding Control
(and MiscStatus) key to registry could give you illusion of your control
derived (directly or indirectly) from System.Windows.Forms.Control being
usable from VB6, but you'll experience numerous problems when you actually
try using it. If I remember it correctly - one of the .Net 1.0 betas
actually added these keys to registry when you run regasm on component
inherited from System.Windows.Forms.Control but it was removed from the
final release of .Net...
However, knowing that you can implement any COM interface in .Net, in order
means you can also implement OCX if you manually implement all the
IOleObject, IOleInPlaceObject, IOleView, IOleView2, IPersistStream,
IOleControl++. This method of implementing OCX that I was talking about in
my posts to that thread and I'm going to implement such sample OCX in C#
when I'll get it a bit better with my spare time.
But regardless how you do it you don't get one thing working automatically
(unless it would be added to VB6 runtime at some point). The main problem
with all COM clients that is not aware about .Net (like VB6) is that they
don't call CorExitProcess (exported by MSCOREE.dll). That in order means
that CLR doesn't terminate properly and among other problems means that
Finalizers will not be run on unmanaged process terminate. Last is because
without a call to CorExitProcess, the CLR is only notified that the process
is shutting down from DllMain's process detach notification. The loader lock
is held at this point, so there is no way that finalization code can safely
run.

-Valery.

http://www.harper.no/valery
 
Back
Top