Activex exe And Activex dll

[bala_e]

Hi,

I'm having doubt in COM area. Actually in which situation we've to go for Activex dlls and in which situation we've to go for Activex Exes.



With Advance Thanx


Bala

[techyspecy]

Originally posted by bala_e
Hi,

I'm having doubt in COM area. Actually in which situation we've to go for Activex dlls and in which situation we've to go for Activex Exes.



With Advance Thanx


Bala

All COM Dll's in VB are made using Active X DLL. Very seldom you are going to use ActiveX EXE. For explanation search the forum.

I'm too tired to type

[usamaalam]

ActiveX dll is usually used when we are calling the ActiveX server and ActiveX client are on the same machine, while ActiveX exe is used when ActiveX server and ActiveX clients are on different machines.

[Shawn N]

Just to clear up usamaalam's post:

An ActiveX EXE is best used when there is a network and every computer has acess to a server. The server will contain the EXE and all request from your VB project to make an instance of the object will go to this server. Definately makes updating a lot easier as long as you stick with binary compatibility.

An ActiveX DLL is best for programs that run on an independent machine.


There's a lot more to the concept, but that's the biggest differences to me.

[techgnome]

It makes no difference if the components are on the same machine or not. You can use ActiveX EXEs or DLLs in either case.
So, what is the difference? Threading for one, concurrency for another, and the ability to be executed in a standalone object.
Typically DLLs are used 90% of the time. They are (generally) self-contained code objects that can be instanciated then called. You can create multiple instances of the same object. But they will all run withing the same thread as the calling program. ActiveX EXEs on the other hand allow you to break that thread process and let it run on it's own. It can be on the same machine or on another. You can also set up callbacks with it to let the main program know what it is up to.
I've never seen a situation where ActiveX EXE was the way to go. I think the situations that ActiveX EXE were created for have been replaced by MTS, which allows the server to run the process, freeing up the client completely.

[Shawn N]

It makes no difference if the components are on the same machine or not. You can use ActiveX EXEs or DLLs in either case.

techgnome please explain something to me:

How can a DLL exist in the same process as the creating EXE if the DLL is on a seperate machine?

[TPR25]

While I use ActiveX exe's very infrequently, I do on occasion find use for them. Generally, this comes when I have a stand alone application that I would also like to provide scripting access to. Where I to use an ActiveX dll, I would have to create a stand alone interface and then a dll to provide access to the functions. However, on occasions where you would like to provide access to methods used by the exe itself (MS Excel being one example), then an Active X exe provides that functionality.

Like I said, not something that I would use every day, but something that is occasionally useful.

[techgnome]

When you use CreateObject and get it from a remote server, you actually pull down a copy of of the object in memory back to the client machine.
That's where MTS get it's strength from, it stays on the server, and runs in it's own process. If simply having the DLL on a remote machine & calling it left it on the remote, what would be the point of MTS?
When using MTS, you tell the server,"Hey, create yourself this object, and pass it these parameters when you call method XYZ." The server responds w/ OK (or Failed), spawns the process and runs with it.
Using CreateObject to get a "remote" object only tells the client machine, "hey, you can get that object's definition over at this location." But the object will still be in the client's memory.

[usamaalam]

Thanks.

I got some new concepts.

[techgnome]

Originally posted by TPR25
While I use ActiveX exe's very infrequently, I do on occasion find use for them. Generally, this comes when I have a stand alone application that I would also like to provide scripting access to. Where I to use an ActiveX dll, I would have to create a stand alone interface and then a dll to provide access to the functions. However, on occasions where you would like to provide access to methods used by the exe itself (MS Excel being one example), then an Active X exe provides that functionality.

Like I said, not something that I would use every day, but something that is occasionally useful.

I agree, there's not too many times when it's usefull, but there's that 1% of the time when it is.

[Shawn N]

Originally posted by techgnome
When you use CreateObject and get it from a remote server, you actually pull ...

Well I was talking about actually using a reference to interface with during design. I'm not to experienced with using either DLLs or EXEs, just know what I've read.

[techgnome]

Originally posted by Shawn N
Well I was talking about actually using a reference to interface with during design. I'm not to experienced with using either DLLs or EXEs, just know what I've read.

Right, you create a reference to an object that holds the interface definition of the object you want to "talk" with. Then user CreateObject (using both parameters, ProID and ServerName) to get an instance of that object. Once you CreateObject, it's on the client machine.

[Shawn N]

I'm gonna try it on my comps here at home. I was positive that an object of a DLL couldn't be created remotely.

[techgnome]

I didn't think so either, but I've seen posts from others here on VBF who have done it.....