Exchanging info between VB-VLisp-VB

I have many programs in Visual Lisp and I would like to add some VB to them. I need to read visual lisp lists in my VB program and I don't know how to do it.

Any help?

 

One way would be to use Frank Oquendo's Vlax Class. This allows you to
access lisp functions & symbols. It has been posted here numerous times. If
you can't find it, post back and I'll see if I still have the zip file here.

 

I have not tried the vlax class, but when trying to mix the two, I make dll's of my VB code and call them in process.
I know you want to read the global vars in an acad session which is different.
I think you should consider writing info to a text file with your lisp as a go-between.
Its an odd thing because you can make dll's with VB, but not with lisp.
Curious to see what you decide.

Yvon <>
|>I have many programs in Visual Lisp and I would like to add some VB to them. I need to read visual lisp lists in my VB program and I don't know how to do it.
|>
|>Any help?

James Maeding
jmaeding at hunsaker dot com
Civil Engineer/Programmer

 

Hi Yvon

In addition to the other answers:

You can build an interface to 'transport' the values from/to...
- Single values by system vars USERI1-5 USERR1-5 or USERS1-5
- For complex informations use dictionaries

This sample shows you how to do it with system vars:

Code:

;
; == Function MeMsgBox
; Displays the VBA MsgBox.
; Arguments [Type]:
;   Pmt = Prompt [STR]
;   But = Buttons [INT] *)
;   Tit = Title [STR]
; Return [Type]:
;   > Return value [INT] *)
; Notes:
;   *) Details see VBA help, for LISP use the 'vlax-' prefix.
;
(defun MeMsgBox (Pmt But Tit)
(setvar "USERS1" Pmt)
(setvar "USERS2" Tit)
(setvar "USERI1" But)
(vl-vbarun "YourVba.dvb!MacroFunctions.ShowMsgBox")
(getvar "USERI1")
)

' VBA Macro (in modul 'MacroFunctions')
'
Sub ShowMsgBox()

With ThisDrawing
.SetVariable "USERI1", MsgBox(.GetVariable("USERS1"), _
.GetVariable("USERI1"), _
.GetVariable("USERS2"))
End with

End Sub

Sample:
(MeMsgBox "This is a test." (+ vlax-vbOKOnly vlax-vbInformation) "Title")

Cheers

 

Hi "Jürg,

Just in case some other program is relying on data from the User group,
would not it be a good idea to append your value to the current value with a
unique divider and remove the additional data after reading it.

psuedo code only.

eg (setvar "USERS1" (strcat (getvar "USERS1") "|||" Pmt)

And at the far end.
sTmp = Getvariable ("USER1")
vTmp = Split (sTmp, "|||")
SetVariable "USER1" vTmp(0)
TransferredVariable = vTmp(1)


--

Regards,


Laurie Comerford
www.cadapps.com.au

 

It would be nice if we didn't represent third party tools
that are nothing but 'wrappers' around already existing
functionality, as essential.

The Visual LISP ActiveX API is readily accessable from
any language without the need for any wrapper.

Learning to use the core functionality directly can
have benefits in the long run.

 

My advice is to use Visual Basic (not VBA), and develop
your code as ActiveX servers, which you can call from
Visual LISP.

 

I have to take exception to promoting this sort of
hacking. If there were no other way to do what the
subject line seeks to do, I would not condemn it in
the stongest possible terms, but given the broad
range of alternatives, this is about as horrible as it
gets.

 

>

Would you care to share so I might learn? In all of the posts with this, or
similar, question, I have not seen any response from you, or anyone else, as
to how this may be done.

Say I have my "xtraspecial.lsp" that I have been using since Eisenhower was
president, it works great and sets a global var named "*xtra_spcl_var*" that
contains a list of dotted pairs. How can I access the data in this var in my
new VBA project?

Thanks,
Jeff

 

Hi Tony,

You may be surprised that I agree with you that it's a kludge as are several
of the obvious ways of swapping data between lisp and VBA, but if it is
done, then better to do it safely.

The other thing for you to realise is that you have an extraordinary
knowlege of customising AutoCAD. Most (if any) users do not have your
skills, or the time and intellect to develop them.

Unfortunately you tend to keep your skills secret - usualy preferring to
present them as criticism of others' attempts to solve problems from their
personal range of experience an knowledge.

A positive response would have been to publish an elegant method of swapping
variable values between Lisp and VBA.

If users can get a kludge to work and meet their needs, then they are happy.
In general they are not faced with the implications of making sure the code
works in all situations.

--

Regards,


Laurie Comerford
www.cadapps.com.au

 

No need for Tony to share; I already did. The utility you mentioned is a
plain text file, readily accessible to anyone who cares to delve into
how it works.

However, it's silly to balk at the idea of using components in our code
when VB and VBA are almost entirely component based. Indeed, that's the
idea behind ActiveX in general.

The real issue, rather than the red herring presented, is when it is
appropriate to use thid-party tools. As a rule of thumb, avoid any
closed-source solution not offered by a reputable company with a
longstanding, respected reputation. Shareware and freeware authors,
myself included, are free to abandon or radically alter their offerings
at any time, leaving you without a tool which has become a key component
in your coding efforts.

Always look for an option to acquire the source, even if the component
is free. About the only exception is wrappers for well-documented
processes such as CommonDialog control replacements and such.

The only time you should ever set these guidelines aside is when you
simply need something *now*.

 

Sorry to disagree. Doing things the right way requires no
'extraordinary' knowledge of AutoCAD. It may require a
modest understanding of good/sound programming concepts,
principles, and practices, and the common sense to see the
pitfalls of kludges like this, before you fall into them.

In this case, it doesn't take a guru to see that transferring
data via strings, requires the data to be converted to- and
from strings, and it requires enough sense to realize that
there are things that may need to be transferred (such as
entity names, selection sets, etc.), which cannot persist
in string form.

So, given those simple to understand limitations, I can see
no legitmate argument in defense of taking such an unsound
and inherintly limited approach to begin with.

It doesn't take a guru to see how many hoops VBA users
have to jump through to use the SendCommand() kludge,
since that also suffers from the same limitations (everything
must be a string), except that in the case of SendCommand(),
the VBA programmer can compose LISP expressions as a way
of passing things that can't be persisted directly in string form.
(Kludge on top of Kludge).

If the sophistication of the tools you want to develop require
this kind of communication wiith LISP, then you've already
outgrown VBA, and should just accept that, and the fact that
its probably time to think about using a 'grown up' programming
system (such as a VB based ActiveX servers).

 

There's been quite a few posts here on how to use
VL.Application and its aggregates, although I don't
know if they're all available.

More importantly, I would recommend avoiding that
in any case, and just do it the right way (Okay, to
me, the 'right way' means not using VBA to begin
with, and instead using VB to build ActiveX dlls that
you can control directly and in a more supported way,
from LISP).

One thing that we should all agree on, is that Microsoft
very deliberately designed VBA to be limited and easily
'outgrown', to support sales of VB and other programming
tools. I don't really see any good purpose in trying to
'buck' that concept and do things with VBA, that it was
deliberately designed to not do.

 

While I don't disagree with your asessment, I believe your perspective
is one not shared by most people in this group.

You make your living writing software. Most of us make our living
drafting and program as a means to the end of making our drafting
operations more efficient and standards compiant.

Whether VBA was designed to do something doesn't really matter so long
as it *can* do that something since it represents one of the tools
readily available to every AutoCAD user.

 

Hi Laurie

First of all, the USERxn sysvars shouldn't be used as globals. It would be a
bad practice to rely on 'untouched' USERxn's.
However, everyone has the freedom to reset the variables to the original
values:

Code:

(defun MeMsgBox (Pmt But Tit / RetVal VarLst)
(setq VarLst (mapcar 'getvar '("USERS1" "USERS2" "USERI1")))
(setvar "USERS1" Pmt)
(setvar "USERS2" Tit)
(setvar "USERI1" But)
(vl-vbarun "YourVba.dvb!MacroFunctions.ShowMsgBox")
(setq RetVal (getvar "USERI1"))
(mapcar '(lambda (s v) (setvar s v)) '("USERS1" "USERS2" "USERI1") VarLst)
RetVal
)

Cheers

 

Have a look at the code in Frank's class and you should be able to work it out.
Regards - Nathan

 

Tony,
Thank you for taking the time to share this. It is quite helpful, but I am
having a hard time understanding how having a formal interface in lisp is
any different than having an interface in VBA that utilizes the same
VL.Application as yours..... I mean, what Frank put together is by no means
any rocket science type code, but rather a compilation of some useful
functions that help poor sods, like I once was, to make the transition from
lisp to VB(A). And those functions don't look much different than what is in
your code. I found the VLAX class to be both useful AND educational......I
learned that I didn't want to be passing data back and forth, although I
could if I needed to. I have long since stopped trying to do this, but the
newcomers need something to help them along (otherwise they wouldn't of
asked the question).

I still haven't gotten to the VB part, as that route costs money that I
can't justify spending for the mods I currently write. But that doesn't mean
that I don't want to learn the proper way to do things, it's just that
sometimes we need a crutch to get past the falling down we do in the pursuit
of learning.

Thanks again,
Jeff