Flawless Back and Forth Communication Between VBA and .exe

Flawless Back and Forth Communication Between VBA and .exe

Anonymous
Not applicable
638 Views
4 Replies
Message 1 of 5

Flawless Back and Forth Communication Between VBA and .exe

Anonymous
Not applicable
I was wondering if a flawless communication between a
VB .exe and a VBA program exists innately. Or if not can I do something to make it work.

I have inherited a huge VBA program which works perfect -- and I am tasked to expand it.

At first I tried to write the whole thing in VB but the size is just so huge just building the GUI (straight copy from original code) took a whole day. Then I have to change variable names to be understandable and uniform plus changing all control names for the same reason -- then injecting control arrays and making sure that I am not breaking anything -- its just too much headache. And in the end I gave up the plan.

Now here is my new plan ..
I am planning to do all expansions of its capability (existing VBA program) as a separate development using VB, but want to make sure that synchronized throwing data back and forth of control between VBA and VB is possible with VBA as the program which will start this "basketball" thing.

The keyword is "synchronized" I have no problem generating data either from VB or VBA and passing it anywhere I want --between the two but I want complete control -- of program flow.

If I had three lines of code for example where the first line would hide the vba form then second line to call the exe then third line to show again the vba form -- I do not want to have the third line executed before the second line is done.

I tried to do this in my attempt to do VB exe and Lisp back and forth communication and my observation for a similar kind of example above is that the "traffic light" does not seem to be working i.e. when I call lisp from the exe the exe would not wait until the lisp routine is done instead, as soon as it does the call for Lisp to do something from say line 2 of code -- it does not care if lisp is already done with what it is doing or not -- instead, what it will do is right away call the third line even before lisp can complete.

Thank you so much for all the kind help you can give.

Matt
0 Likes
639 Views
4 Replies
Replies (4)
Message 2 of 5

Anonymous
Not applicable
matt_1ca wrote:
> I was wondering if a flawless communication between a
> VB .exe and a VBA program exists innately. Or if not can I do
> something to make it work.

All communication between your EXE and AutoCAD should take place in an
ActiveX DLL. You might even check to see if the EXE isabsolutely
necessary.
0 Likes
Message 3 of 5

Anonymous
Not applicable
I do not know what the exact process the huge VBA or your VB exe is, but as
Frank pointed out, and I also feel that you may put your first priority on
ActiveX dll. Why you need move some process that works well in AcadVBA into
an VB exe? The only reason I can think of is that the process has little to
do with Acad functionally and you want it to be performed outside Acad in a
DIFFERENT process, such as you automate MS Word/Excel from your Acad VBA
code. But from your description, it seems that you are trying to streamline
a huge VBA project that works well in ACAD and the process has to be
sychronized. So, probably you really want to is reorganize to VBA ocde into
one or more ActiveX dll projects, not an ActiveX exe. Again, not knowing
what exactly the process is, here is only my feel on your post.

wrote in message news:[email protected]...
I was wondering if a flawless communication between a
VB .exe and a VBA program exists innately. Or if not can I do something to
make it work.

I have inherited a huge VBA program which works perfect -- and I am tasked
to expand it.

At first I tried to write the whole thing in VB but the size is just so
huge just building the GUI (straight copy from original code) took a whole
day. Then I have to change variable names to be understandable and uniform
plus changing all control names for the same reason -- then injecting
control arrays and making sure that I am not breaking anything -- its just
too much headache. And in the end I gave up the plan.

Now here is my new plan ..
I am planning to do all expansions of its capability (existing VBA program)
as a separate development using VB, but want to make sure that synchronized
throwing data back and forth of control between VBA and VB is possible with
VBA as the program which will start this "basketball" thing.

The keyword is "synchronized" I have no problem generating data either from
VB or VBA and passing it anywhere I want --between the two but I want
complete control -- of program flow.

If I had three lines of code for example where the first line would hide the
vba form then second line to call the exe then third line to show again the
vba form -- I do not want to have the third line executed before the second
line is done.

I tried to do this in my attempt to do VB exe and Lisp back and forth
communication and my observation for a similar kind of example above is that
the "traffic light" does not seem to be working i.e. when I call lisp
from the exe the exe would not wait until the lisp routine is done instead,
as soon as it does the call for Lisp to do something from say line 2 of
code -- it does not care if lisp is already done with what it is doing or
not -- instead, what it will do is right away call the third line even
before lisp can complete.

Thank you so much for all the kind help you can give.

Matt
0 Likes
Message 4 of 5

Anonymous
Not applicable
Thanks Frank,

For months now, I have been planning to move to ActiveX DLL because I know my program would be running faster than an exe if it were as you are suggesting -- and to think that it would also solve my current grief is another good reason.

I do not know so much about how it would react in a network environment but I realize now that it is something I can only postpone to my own disadvantage.

Matt
0 Likes
Message 5 of 5

Anonymous
Not applicable
Thanks Norman,

I will try to proceed with this long overdue migration ASAP.

Matt
0 Likes