Improvement on Visual LISP DCL Interface

I never thought of that. But the reason I dont like VBA is that it does not use ADO for database stuff, it uses DAO or
something. I just know I could not use the same ADO functions in my database library of functions.

The real thing that turned me off of VBA and even VB for tools that draw things in acad is that I end up using
sendcommand for so many things. You cannot silence the command line with sendcommand, nomutt does not work as you would
expect. Its hard to control. Its just plain cluncky to not be able to easily do a (command "whatever..."). Lisp does
that so well. In Lisp, you can construct the value for the next "command" in sequence. This is so nice for dimensions
and other things.
Again, the structure of VB and VBA puts lisp to shame.

Now I want to ask people, does anyone out there actually know of a tool for acad written in .net? I hear people say
that is the future and all but I have never seen anyone actually use it.
thx

James Maeding <>


James Maeding
Civil Engineer/Programmer

 

I don't have any problems using ADO with VBA - just add it to the references in your project.

functions.


Code Snippet:


Dim adoCon As New ADODB.Connection
Dim adoRst As New ADODB.Recordset
Dim strActHgt As String
Dim sSQL As String
Dim sCon As String
Dim projno As String

sCon = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=" & Adv_DBLink & ";" & _
"Persist Security Info=False"
adoCon.Mode = adModeRead
adoCon.Open sCon

sSQL = "qryProjData"
projno = GetProjNo(jobpath)
adoRst.Open sSQL, adoCon, adOpenStatic
adoRst.MoveFirst
adoRst.Find "prProject like " & projno & "*"
If adoRst.EOF = False Then
LoadingData = True
On Error Resume Next
TextBox1.Text = adoRst.Fields(1)
TextBox2.Text = adoRst.Fields(2)
'TextBox3.Text = adoRst.Fields(x) 'City, State are not in Advantage DB
TextBox4.Text = adoRst.Fields(5)
LoadingData = False
ChkData
Else
cmdReadFromAdvantage.Visible = False
lblError.Caption = fso.GetBaseName(jobno) & " project information not available from
advantage...."
End If
adoCon.Close



End Sub

 

I'll have to try that. Thats good to hear.

I have not followed VBA much because I use VB. One thing I have not invested the time to figure out is how to get VB to
hook up with a particular drawing. It uses the first session it finds. I just need to spend time on it. VBA solves
this but I just dont like the controls and things in VBA. There are slight differences that just waste mental energy
figuring out.

Now if someone would tell me .net has a way to do the GRDRAW and GRREAD, I'll start to change my tune on non-lisp
languages. Those two functions are just super useful. I hate using sendcommand for this stuff, its just embarrassing
to see all that text on the command line.
Its a waste of time doing all the careful formatting of the sendcommands. There really needs to be some kind of util
functions for the COMMAND, GRDRAW and GRREAD.

No doubt I could get by some of the things I dont like about VBA and VB but some cannot be avoided and Lisp does those
things easily. You have to use objectdcl though to maximize lisp if you ask me.

"Allen Johnson" <ajohnson@dwase>
|>I don't have any problems using ADO with VBA - just add it to the references in your project.

James Maeding
Civil Engineer/Programmer

 

The users in this post must be doing some really, really advanced stuff, because VLisp has worked very well for me and is very fast IMHO. I can't really think of any particular application where it has left me hangin'.

I guess I just need to get out more...

 

I can't detect any maintenance. DCL hasn't seen any maintenance for ten
years now, but it works. Much worse is the fact, that even the most
horrible bugs in VLisp aren't fixed. Someone else in this long thread
said it clearly: Nothing happened any more since VitalLisp was acquired
(except for changing som icons).

Have a look at this short sample:

(setq defun defun-q)

Type in !defun at the command line: => #<SUBR @0a9c2974 DEFUN-Q>
We should be able to rely on the fact that from now defun-q ist
exececuted when we use defun.

(defun add(a b)(+ a b))

!add => #<SUBR @0a9230dc ADD>

Is this the proof that VLisp has already forgotten the setq-statement?
No, defun is still assigned to defun-q, but nevertheless defun-without-q
is executed.

What does that mean? VitalLisp brought a new kind of 'macro table' into
the language, but the macros are somewhat 'hard wired'. In fact, there
are two defuns: DEFUN no. 1 is a Symbol which you can bind to whatever
you can imagine (nil too!), but the binding is never evaluated.
Then there is a macro DEFUN which is executed by the reader without
really seeing the interpreter from inside. No matter what is bound to
DEFUN, VLisp always executes what VLisp thinks, not what
the program or the user intended.

This is a very severe bug - so severe that I think the VLisp language
isn't any more operational. One can still use VLisp for some simple
Basic-Style utilities, but it doesn't work any more for more complex
techniques like self-modifying code. This severe bug is not to defun, it
applies to every lisp function which is internally implemented as a
(hygienic) macro, like SETQ, FOREACH, WHILE, REPEAT and so on (all the
functions that 'autoquote' one or more of their arguments).

This bug is in VLisp since VLisp exists. 'Maintenance' would mean, that
the bug would be fixed, but it wasn't fixed for years, and it will never
be fixed. VLisp has not gone into 'maintenance mode', it has gone into
'still-existing, but unmaintenanced mode' like DCL.

D'accord, Tony. But what about VBA? 6.3 in 2004, 6.3 in 2005 - I don't
think MS will still do any further development. VBA hasn't that severe
bug (except that VB6 is a large kind-of-bug itself), but it shares the
future with VLisp: 'still-existing mode'. Learn to use other languages,
yes, but surely not VBA/VB6.

Axel

 

well, the only problem is that ODCL is not fully activex compatible with all custom controls. Certain things just do
not work. You have to really be pushing the envelope though to run into this and there are easy workarounds.

Its odd that such an archaic language happens to be the smoothest for acad.

Nick_Merchant <>
|>The users in this post must be doing some really, really advanced stuff, because VLisp has worked very well for me and is very fast IMHO. I can't really think of any particular application where it has left me hangin'.
|>
|>I guess I just need to get out more...

James Maeding
Civil Engineer/Programmer

 

What will happen,
will be what is more useful ( $ $ $ ) to Autodesk,
and not what is useful to users and customers.

domenico