Message 1 of 5
Flawless Back and Forth Communication Between VBA and .exe
Not applicable
06-16-2005
09:00 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
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
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