VBA-VLISP talking to each other

I've made a list of methods by which VBA and VLISP can talk to each other.
I'm not sure the list is comprehensive, though. What am I missing?

1. Read and write files such as text files, Excel files, etc.
2. Read and write system varieables users(1-5), userr(1-5), useri(1-5).
3. Read and write xrecord/dictionary entries.
4. Read and write xdata.
5. Read and write registry items.
6. Sendcommand or sendkeys functions in VBA.
7. Use Frank Oquendo's VLAX-based program.

 

Perhaps ...

Compile an activex dll using Visual BASIC / Delphi etc.;
create instance using visual lisp and invoke methods etc.
using same.

Of course, this isn't talking to VBA per se, but if the
intent is to utilize vb[a] based functionality in lisp
then this would be a means to that end.

I've found it works quite effectively.

I've made a list of methods by which VBA and VLISP can talk to each other.
I'm not sure the list is comprehensive, though. What am I missing?

1. Read and write files such as text files, Excel files, etc.
2. Read and write system varieables users(1-5), userr(1-5), useri(1-5).
3. Read and write xrecord/dictionary entries.
4. Read and write xdata.
5. Read and write registry items.
6. Sendcommand or sendkeys functions in VBA.
7. Use Frank Oquendo's VLAX-based program.

 

Thanks, Michael.

-Randy

 

You're very welcome Randy. If you want some example
code let me know and I'll see if I can put together
a commented skeleton this weekend (if no one else
provides one).


Thanks, Michael.

-Randy

< snip >

 

I appreciate the offer, Michael.

For now we probably won't be going down this road, but I'll keep the
suggestion in the back of my mind.

What seems to be the primary advantage of using the VB/Delphi dll rather
than one of the other methods that I listed?

-Randy

 

To respond (with fairness) to your question one would really
have to put it into some kind of context; e.g. what are you
trying to achieve overall, and how might you delegate the
division of labour? Is it even practical to split the tasks?

Hmmm ... For example, I have penned applications that read a
database and then dynamically create block definitions,
create and populate attributed instances as required and
then log the entire activity to a dictionary. Nothing special
here; one could do it entirely in vba, and for many that's
probably the best way to go.

However, I elected to do the ADO SQL stuff in a dll, and
then everything else in lisp; mostly because vb lends itself
really well to ADO, and I'm more comfortable with the
balance of the exercise using lisp.

While one can argue whether my approach is sound (and I
welcome constructive arguments why it may not be so) for me
it represents a means of choosing the right tool for the job
based on my current abilities and time frame: I have a job
to do and it needs to be done today.

To date it has proven to be fast and very reliable.

In my opinion, trying to achieve the above would be clunky
at best with any of the methods in your original post,
unless you did it entirely in vba; but then this
conversation would be moot.

Hope this helps (some).

Cheers,

Michael.

I appreciate the offer, Michael.

For now we probably won't be going down this road, but I'll keep the
suggestion in the back of my mind.

What seems to be the primary advantage of using the VB/Delphi dll rather
than one of the other methods that I listed?

-Randy

 

Fair enough.

Over the last decade or so, we've grown a multitude of AutoLISP programs
that make drawings of various components that are used in our product. More
recently, we created a very large program that defines an integrated product
rather than just the components. This was needed to create drawings for the
basic framework. This was sufficiently complex that we elected to use VBA
dialog boxes instead of the DCL that we had traditionally been using. DCL
could not have cut it. We used AutoLISP to create the drawings, however,
after the necessary information was gathered from the VBA dialog box. Now
that we have the basic framework, we can begin to integrate all the
disparate old AutoLISP programs into a unified whole. The VBA dialog box
will be the master. Already there are 11,000 lines of code in the VBA just
to run the dialog box. We would really not want to rework all the old
AutoLISP programs into VBA, so then the issue of communication between the
two comes up. We want to minimize the extra code we will have to put into
the old AutoLISP programs, but it looks like we'll have to do some of that
regardless of which system we use. I agree that all the methods that I
listed are clunky--that's why I asked the question, to see if there were
less clunky methods. Your method perhaps is not, since I don't really
understand it, but I do see right off the bat that we would still have to
rework the old AutoLISP programs (admittedly we have to do this anyway) and
we will also have to obtain software to create the DDL's.

It looks like the answer to my question, as I picked through your response,
was that VB lends itself really well to ADO. That's good, but since I
haven't the foggiest notion what ADO is, that is meaningless to me.
However, I do thank you for answering my question.

I'm satisfied, until someone comes forward with another option, that there's
no superduper way to have AutoLISP and VBA talk to each other, so I'll just
be satisfied with something less than superduper.

-Randy

 

Did I say something to offend you somehow? Sure hope not.

Sorry about the acronym, ADO stand for Activex Data Objects
library; the successor to DAO or Data Access Objects; both
means to talk to databases.

So it means I can query a database for data and have the
results returned to lisp. In other words, application
invocation starts with a lisp based command (defun c:MyApp),
is transferred mid execution to one or more dlls, and then
back to c:MyApp where it goes about the business of placing
the acquired data into the drawing as previously described.

Oddly enough, in the end, I believe this would be closer to
what you want (minimize impact to existing source base) than
trying to jig up something in vba, and then communicate thru
some tin cans and bail wire back to lisp (i.e. user vars).
That is not a shot at you, just my sense of how reliable
using userr1 etc. to talk back and forth between lisp and
vba might be.

Re: "Alternative to DCL", you can embed dialogs in dlls too,
which I have also done without any difficulty. I did not
mention it merely because I wanted to talk about a
relatively simple, but real world example. It's just as easy
to embed dialogs, albeit a little more development time that's
all, and I would say it's easy enough that even I can do it,
as I am by no means a vb shaman.

To wit, you may be able to put all the vba code you have
already penned in a dll (albeit with some modifications, a
wrapper class perhaps) and then call it the way I suggested.
Perhaps a simple example project will help illuminate (see later
in this post).

In the end, no matter what route you go, it sounds like you
may have to stand back and take a high level view of the
problem, and then map out a practical solution that is
implementable, documentable, maintainable and serves you best
long term. If I am not mistaken, you and I, perhaps a more
northernish fellow than myself, talked about this years ago.

Offer stands for example code; I'll make it dialog based if
you wish; just no promise of when I can concretely deliver it
(though I'll endeavour to do it as soon as my schedule affords).
I'm more than happy to provide this for if it can help you out.

Cheerios and best wishes.

There's three things I hate about getting older; I forget
the other one.

Fair enough.

Over the last decade or so, we've grown a multitude of AutoLISP programs
that make drawings of various components that are used in our product. More
recently, we created a very large program that defines an integrated product
rather than just the components. This was needed to create drawings for the
basic framework. This was sufficiently complex that we elected to use VBA
dialog boxes instead of the DCL that we had traditionally been using. DCL
could not have cut it. We used AutoLISP to create the drawings, however,
after the necessary information was gathered from the VBA dialog box. Now
that we have the basic framework, we can begin to integrate all the
disparate old AutoLISP programs into a unified whole. The VBA dialog box
will be the master. Already there are 11,000 lines of code in the VBA just
to run the dialog box. We would really not want to rework all the old
AutoLISP programs into VBA, so then the issue of communication between the
two comes up. We want to minimize the extra code we will have to put into
the old AutoLISP programs, but it looks like we'll have to do some of that
regardless of which system we use. I agree that all the methods that I
listed are clunky--that's why I asked the question, to see if there were
less clunky methods. Your method perhaps is not, since I don't really
understand it, but I do see right off the bat that we would still have to
rework the old AutoLISP programs (admittedly we have to do this anyway) and
we will also have to obtain software to create the DDL's.

It looks like the answer to my question, as I picked through your response,
was that VB lends itself really well to ADO. That's good, but since I
haven't the foggiest notion what ADO is, that is meaningless to me.
However, I do thank you for answering my question.

I'm satisfied, until someone comes forward with another option, that there's
no superduper way to have AutoLISP and VBA talk to each other, so I'll just
be satisfied with something less than superduper.

-Randy

 

No, Michael, you haven't offended me. Not at all.

You're right, we did discuss a big project a few years ago. A completely
different one, but having the similarity of needing a well-thought-out
strategy. This one is for my day job, that one was an independant project.

My wife is outside with the car running waiting to pick me up, so I'll see
if I can try to understand the rest of what you're saying later.

Thanks again,

-Randy

 

Speaking of long term strategies, as long as you are visiting
your design and considering the best means to code up what
amounts to a presentation layer (iinm), I should mention that
..NET (Microsoft's latest programming technologies) might be also
be considered, as that appears to be the direction Autodesk is
going.

I haven't used .NET since I was at University, so my limited
experience was purely academic rather than industrial. In other
words, others are far more suited for providing you any .NET
advice based on their real world experience.

At this point I hope others may jump in and offer any additional
council to help you identify a path forward, be it any of the
mentioned techniques or technologies or something completely
different.

Sincerely,

Michael.

<snip>