Hello,

What are the main differences between an EXE or DLL written in Vb6 and
what considerations for choosing one of them when writting a piece of
code to be used with VBA?

Thanks
Avi

An EXE is a stand-alone application, typically started from a Windows icon
though not necessarily. It might, for example, start a new Excel instance,
process a whole bunch of data obtained from elsewhere, dump the results into
a new workbook, save & goodbye. It may or may not have a Form as a user
interface. Whilst it could interact with VBA in a workbook I kind of doubt
that's what you want to do.

A VB(6) ActiveX DLL is activated via a Public (entry) class, two types -

MultiUse: This can be instanciated from VBA with 'New' (early binding with a
reference to the dll in Tools > references) or with createObject (early or
late binding). Once the entry class is running the VB & VBA can act as a
single application shaking hands between the entry class.

GlobalMultiUse: you can call its public methods & properties directly
without doing as described above.

A VB Com-addin is also an ActiveX dll which has a special class. Typically
this is instanciated when Excel starts (according to settings). It has a
built in method to trap the click event of an Excel commandbar button and go
from there, it doesn't require any VBA.

If you want the VB to be controlled from your VBA the choice is clearly the
DLL (vs EXE).

I take it you didn't see the response I left to your earlier post.

Regards,
Peter T

"avi" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hello,
>
> What are the main differences between an EXE or DLL written in Vb6 and
> what considerations for choosing one of them when writting a piece of
> code to be used with VBA?
>
> Thanks
> Avi
>

Helo Peter,

Thanks . I guess i'll opt for a dll as you suggested although i see(am
i wrong?) an advantage in the EXE approach: do not need to register
the DLL / I can put it as a part of the VBA code and call it with
Shell statement

Avi

> an advantage in the EXE approach: do not need to register

If it's an ActiveX EXE you still need to register, but with /RegServer not
regsvr32 as you would with a dll.

If you use late binding, in your VBA code if you can't create your entry
class, trap the error and call a separate routine to register the dll (in
code with Shell and you would need to know it's path or ask user to find it
if necessary).

Have you actually tried your Shell to EXE approach, in addition to which
you'd might want to look into "Shell & Wait". How do you go on to interact
between your VBA and the EXE, can be done but more difficult & limited.

Guess it depends on what you are doing overall.

Regards,
Peter T


"avi" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Helo Peter,
>
> Thanks . I guess i'll opt for a dll as you suggested although i see(am
> i wrong?) an advantage in the EXE approach: do not need to register
> the DLL / I can put it as a part of the VBA code and call it with
> Shell statement
>
> Avi
>

Roedd <<avi>> wedi ysgrifennu:

> Hello,
>
> What are the main differences between an EXE or DLL written in Vb6 and
> what considerations for choosing one of them when writting a piece of
> code to be used with VBA?
>

OK, assuming you mean an ActiveX .exe, the advantage of this is that you can
have it independently threaded to your VBA. Just code some events to alert
your VBA when processes are finished, declare the instance of your .exe
withevents and you can have it go off and do lengthy stuff without any
danger of the user thinking that Excel has hung. The disadvantage is that
all of this takes place outside of the Excel process, which means that
communication between Excel and your .exe will be slow because it must be
marshalled through a narrow communication channel.

So, if you want to do a lot of interaction between your COM server and
Excel/VBA, use a dll.

HTH

Rob