AcXDLL VS AcXEXE

[Arc]

I know DLL are "in-Process" and EXE are "out-of-process" but what exactly that means i don't know.

Can i make a DLL and put it on the server machine and access it and use it to manipulate and return data or does it have to be an ActiveXExe?

Why would i ever use an ActiveXExe? Why dont DLL's Support SIngleUSE and MultiSingleUSE?


Whoa is me

[ChiefRB]

Its a complicated subject. I will do my best to make it simple...

Basically, when you run your VB EXE, it is allocated 2GB of virual memory. All the ActiveX (Ax) DLLs associated with your EXE run within this space. This means that its all in the same thread, so things execute sequentially. Whenever you call a function from an Ax DLL, your VB code will wait for the function to return. For example:

' in a form

' create an object
Dim CObj As ClassObj
Set CObj = New ClassObj

' call a function
Debug.Print "Before"
CObj.DoAction
Debug.Print "After"

' in the DLL
Public Sub DoAction
  ' pause
  Sleep 1000
  Debug.Print "During"
End Sub

The above code would produce an output that looked like this:

Before
During
After

However, if the Ax DLL above was actually and Ax EXE, the same code would produce this output:

Before
After
During

Because the VB EXE hadn't waited for the Ax EXE to return before moving on to the next statement.

This is one way of how to implement multithreading within VB - place everything into an Ax EXE, and use objects instantiated from it.

Both DLLs and EXEs can return data, and can be run in exactly the same manner.

[Arc]

I see. So Ax EXEs can do asyncronous callbacks, whereas Ax DLL's can not?

Am i reading that right?

[ChiefRB]

Yup.

[Arc]

Ok, so the only time i would need to use an Ax EXE is if i need asyncronous callbacks?

[ChiefRB]

Well, that's up to you really... when I want async callbacks I use an activex exe method.

[frigginjerk]

ActiveX Exe's are also said to be more fault tolerant, meaning that if a run-time error were to occur in an ActiveX Exe it would crash but the calling app would not.

[Kunchesm]

'Synchornous cllbacks' in ActiveX dlls... what exactly does it mean?? can anyone explain with an example plzzzzzzzz....

thanX in advance

[Stiletto]

AxDLL and AxEXE are different in many ways.
ActiveXEXE is like an undepended (cant spell) program which works by its own, and connected to the 'mother' application.
ActiveXDLL is a simple file which contains classes which contains bounch of codes. More:
1. Since AxEXE are undepended, If they crash, nothin happens to the application who called them.
2. AxEXE are workin with new memory 'place'. For example, if you use AxDLL, the AxDLL file will use the memory of the application itself to run codes. AxEXE will use a 'new' memory, just like each program will use its memory only.
3. As result from 2, when callin AxEXE, the AxEXE will run code by its own, and the application can continueing running, while when callin AxDLL, the application waits until the DLL file will finish to run codes, and only when the DLL finished, the application will be able to continue running code.
That's it I think.

[Arc]

Nice explination Stileto, but what if the DLL is on a remote server? Then it can't possibly share the same memory as the client EXE. How does that work?

[Anglo Saxon]

You need a surrogate EXE ( i.e. Microsoft Transaction Server ) to remotely run a DLL. This provides the process space for it to run in.

It never actually runs in the same process as the calling EXE, the calling EXE just thinks it does .Data is marshalled back and forth using stubs and proxies on any object method calls.

If you *really* want to know more I suggest you buy a good book on this very long, and often very boring, subject!

--
Anglo Saxon

[Arc]

Hmm, yah i know crap about MTS....snooze.

[crpietschmann]

Ok actually your wrong about ActiveX DLL not being able to do asynchronous call backs. You can do asynchronous call backs from any type of module.

The basic difference between ActiveX DLL's and EXE's is:
1 DLL's run in the same process space as the application that is calling them. So if a critical error occurs in the dll, and the it crashes, then everything in that processing space will crash too.

2 EXE's run in a separate process space from the application that is calling it. If a critical error occurs in the exe, and it crashes, then only it crashes. The program that is calling will not, because it is not in the same process space.

There are trade off's when using EXE's or DLL. DLL's run faster because its easier to talk to someone when their rite next to you, than if you have to pick up the phone first. Of course EXE's provide more stability for your application, because if the EXE crashes you application can just instantiate a new on and keep on going. You could keep the user from even having the foggiest idea.

If you want to use Microsoft Transaction Server (MTS) then you must use DLL's because MTS does not support ActiveX EXE's.

I hope that pretty much answers your question.

[Edneeis]

Do you have an example project that runs a dll asynchronously? I've only seen it done in activex exes.

[crpietschmann]

Ohh, never mind I know what you meant. I just had a stupid moment.

[klintsovi]

Hi Chief, regarding your example

i've created an Ax project, with an client app

Ax:

Option Explicit
Private Declare Sub Sleep Lib "kernel32.dll" (ByVal dwMilliseconds As Long)
Public Function test() As String
Sleep 1000
test = "hello from exe"
Sleep 1000
End Function

app:

Option Explicit
Dim t As MTest2exe.clsMTest2exe


Private Sub Command1_Click()
Set t = New MTest2exe.clsMTest2exe
Debug.Print "app"
Debug.Print t.test
Debug.Print "app"
Set t = Nothing
End Sub

and the output that i'm getting is

app
hello from exe
app

and it sleeps for 2 seconds before it executes second debug.print "app"

could you help?

Originally posted by ChiefRB
Its a complicated subject. I will do my best to make it simple...

Basically, when you run your VB EXE, it is allocated 2GB of virual memory. All the ActiveX (Ax) DLLs associated with your EXE run within this space. This means that its all in the same thread, so things execute sequentially. Whenever you call a function from an Ax DLL, your VB code will wait for the function to return. For example:

' in a form

' create an object
Dim CObj As ClassObj
Set CObj = New ClassObj

' call a function
Debug.Print "Before"
CObj.DoAction
Debug.Print "After"

' in the DLL
Public Sub DoAction
  ' pause
  Sleep 1000
  Debug.Print "During"
End Sub

The above code would produce an output that looked like this:

Before
During
After

However, if the Ax DLL above was actually and Ax EXE, the same code would produce this output:

Before
After
During

Because the VB EXE hadn't waited for the Ax EXE to return before moving on to the next statement.

This is one way of how to implement multithreading within VB - place everything into an Ax EXE, and use objects instantiated from it.

Both DLLs and EXEs can return data, and can be run in exactly the same manner.

[ChiefRB]

You have to use a Timer within the class to fire the method call async, otherwise VB blocks the return.

' in the class
Public Sub Test()
  StartTimer
End Sub

Private Sub StartTimer()
  ' call the API SetTimer here
End Sub

Private Sub pTest()
  MsgBox "moooo!!!"
End Sub

In a BAS module, place the API timer callback routine
this sub will call back the class module that set the timer
and this fires the method call asynchronously.
In order to do so, the BAS module will need an object variable
to hold a reference to the class that is calling the timer. This can get complex though if you've got several class instances active at once, because object references might be overwritten, so use an array or a collection...