Visual LISP, AutoLISP and General Customization

[#1]

Jason, You may find the AU class material I did to be useful. It walks you through step by step on creating a project. Not sure if they still have them up on the website, so if you need it, let me know. Joel Roderick "Jason Piercey" wrote in message news:412c8911$1_2@newsprd01... > I've tried it, and find it very confusing to be honest. > Haven't been able to complete a single simple project > with it as of yet. Perhaps I am just not smart enough > to figure it out. > > "James Maeding" wrote in message > news:seeoi0t56r24jolb1mrsjgocfjumjti5j9@4ax.com... > > Have you tried ObjectDcl? Its a Lisper's dream. > >

[#2]

Hi Joel, I'd like to take a look at it, if you don't mind. Off the top of my head, some trouble I had with it was lack of documentation, and why on earth you need *all* of your functions defined like a command (with the c: prefix) That just doesn't make any sense to me. Thanks for the offer. -- Autodesk Discussion Group Facilitator "Joel Roderick" wrote in message news:412e4453_1@newsprd01... > Jason, > You may find the AU class material I did to be useful. It walks you through > step by step on creating a project. Not sure if they still have them up on > the website, so if you need it, let me know. > > Joel Roderick

[#3]

David Allen wrote: > yes a problem. A new customization enviroment is the reason I do not switch from autocad to revit. I don't want to > loose all of my tools I have built up over the years. The same thing would happen if autodesk ditched lisp for some new > format. > > Now if VBA was more commandline friendly then maybe it would be easier to use. > > Martti Halminen > |>> |>The most intelligent thing AutoDesk could do regarding > |> > |>AutoLisp/VisualLisp would be to throw it away and replace it with a > |> > |>full-size CL from one of the commercial vendors, with a compatibility > |> > |>package to allow old AutoLisp code to run. > |> > |> > |> > |>- Whether this is politically possible is another question. > |> > |> > |>Not a problem, the command line behaviour could stay the same > |>regardless of the Lisp implementation behind. The compatibility package > |>would be the default interface, so a casual user wouldn't notice the > |>difference. If you have the source code for your tools, all it would require would be re-compilation; building a source-code compatibility mode in CL would be quite easy, any competent CL programmer could do it. Building a system which could read .vlx files and other compiled/encrypted/obfuscated stuff would be possible, but would need far more work and intimate knowledge of VisualLisp etc implementation internals. --

[#4]

Like you said "If" you have the source. So does lisp, arx, vlx and the rest run in revit? No. Its a totally different enviroment. If (when) autodesk changes its customization enviroment again, legacy arx programs will break again. Some lisp will also no longer work. Martti Halminen |>David Allen wrote: |>> yes a problem. A new customization enviroment is the reason I do not switch from autocad to revit. I don't want to |>> loose all of my tools I have built up over the years. The same thing would happen if autodesk ditched lisp for some new |>> format. |>> |>> Now if VBA was more commandline friendly then maybe it would be easier to use. |>> |>> Martti Halminen |>> |>> |>The most intelligent thing AutoDesk could do regarding |>> |> > |>AutoLisp/VisualLisp would be to throw it away and replace it with a |>> |> > |>full-size CL from one of the commercial vendors, with a compatibility |>> |> > |>package to allow old AutoLisp code to run. |>> |> > |> |>> |> > |>- Whether this is politically possible is another question. |>> |> |>> |> |>> |>Not a problem, the command line behaviour could stay the same |>> |>regardless of the Lisp implementation behind. The compatibility package |>> |>would be the default interface, so a casual user wouldn't notice the |>> |>difference. |> |>If you have the source code for your tools, all it would require would |>be re-compilation; building a source-code compatibility mode in CL would |>be quite easy, any competent CL programmer could do it. Building a |>system which could read .vlx files and other |>compiled/encrypted/obfuscated stuff would be possible, but would need |>far more work and intimate knowledge of VisualLisp etc implementation |>internals. David

[#5]

Hi The documentation has been improved opon. There is an online example section. All the examples are installed with ObjectDCL. There is an intelligent help system that displays the help information through the selected dialog box or control. It will display correctly formated code for the selected object. Joel Roderick Wrote a course for Autodesk Univercity that we are distributing with ObjectDCL. It does and excellent job with teaching a first time user. We also have a manual written by Jim Short that is evalable for download as well from our web site. The new version 3.0 of ObjectDCL has no lack of documentation.

The C: prefix is required because of a shortfall in the ObjectARX programming interface that we cannot work around. There are two ways to activate a defun from ObjectARX and one of them requires the C: prefix to work, the other does not. But for simplification, we made it so both settings require the C: prefix. We would remove it if we could, but unfortunatly we can't.

[#6]

Jason, I put a copy of the paper here: www.globaldialog.com\~jroderick\CP21-3.zip The c: issue is explained in the help file: "There are two similar styles that can be used to program AutoLisp code to handle the ObjectDCL events. But first, to answer a question some of you may have, you will notice that ObjectDCL calls its events as C:xxx defun'd functions. This is done because of the limitation ObjectARX imposes on mechanisms to call AutoLisp functions from some ObjectARX dialog boxes. Rather then setup ObjectDCL to defun some events as C:xxx and others as xxx, C:xxx is used as the standard. The first programming style defines all the event defun's inside the main defun. This allows the program to be created free of global variables. The second style allows global variables to be used instead to organize information between the main defun and the event defun's." If you look at my example in the AU paper, I actually localize the event c:defuns. I tend to be anal about stuff like this When I was doing the CDG thing, I used ObjectDCL for CDGPurge. Since I have dropped the website I have been thinking of just releasing the code as an ObjectDCL example and letting people have fun with it. HTH, Joel "Jason Piercey" wrote in message news:412e48be_1@newsprd01... > Hi Joel, > > I'd like to take a look at it, if you don't mind. > > Off the top of my head, some trouble I had with it > was lack of documentation, and why on earth you > need *all* of your functions defined like a command > (with the c: prefix) That just doesn't make any > sense to me. > > Thanks for the offer. > > -- > Autodesk Discussion Group Facilitator > > > "Joel Roderick" wrote in message > news:412e4453_1@newsprd01... > > Jason, > > You may find the AU class material I did to be useful. It walks you > through > > step by step on creating a project. Not sure if they still have them up > on > > the website, so if you need it, let me know. > > > > Joel Roderick > >

[#7]

If the arx spec's change, the we have to change our code to suit. We usually have to create a new C++/ObjectARX project for every second new release of AutoCAD.

[#8]

Hi, we have been supporting ObjectDCL for AutoCAD from R14 through to 2005. R14 is no longer supported, but we have arx files for all versions of AutoCAD otherwise. The arx distribution files are free to distribute so getting a copy from us will not be problem.

[#9]

When 2004 came along, the C++ compiler went from VC++ 6.0 to VC++ .Net. This meant that to be able to compile for 2004 we had to get the next version of MS VC++ and compile the code in that version. The only changes we needed to make we forced by Microsoft's new .Net and windows XP looking controls. We had to slightly modify a few of our controls so the painted properly in Windows XP. The only change we had to make because of AutoCAD was the option/config tabs. Because our product mainly works with MFC, ObjectDCL is barley affected, if at all when a new version of AutoCAD comes out.

[#10]

Hi Chad, The concern it will be about the long run.... what if ODCL is abandoned?