Why does Autodesk ignores the LISP community?

[JeremyD]

I find it puzzling that Autodesk seems to want to beat us away from LISP with a stick. They purposely do not improve it because they know many of us will take advantage and ignore VBA. They made a tactical error in giving us the VL functions because then we wrote active-X lisp function libraries to avoid wasting our time with VBA. We bought ObjectDCL so that we were no longer hampered by the lack of dialog support. Right now the majority of programmers on AutoCAD are still using AutoLISP and yet Autodesk seems to remain clueless to this phenomenum. When are they going to wake up to the fact that a typical LISP program is half the lines of code of a VBA program? Does anyone else out there feel that they are being railroaded down a path that they don't want to go on? Why does Autodesk ignore the majority of its working programmers and continually frustrate the direction they want to go in? I have nothing against VBA support, just listen to me once in a while guys? Just because Microsoft pushes VBA doesn't mean it's a wonderful language. Python or Ruby would be far better to base AutoCAD on than VBA.

[Anonymous]

I admit, the issue of compatibility is a potential pit. But all languages are flipping around right now. I can switch to VB if I have to and rewrite various progs so Its not too big a deal. Life is unceratin though... James Maeding James Maeding jmaeding at hunsaker dot com Civil Engineer/Programmer

[Anonymous]

email me at jmaeding at hunsaker dot com if you want help, (or post code here...). I'd love to get you started. There are little things here and there I have had to figure out, but I have been able to with no problems. One thing I have down is what events to use for text boxes and combo boxes. There is no validate event like VB so you have to write your own in, its totally simple though once you see it in action. What kind of sample routine would you like to see? I can write it and post it... "Jason Piercey" |>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. |> James Maeding jmaeding at hunsaker dot com Civil Engineer/Programmer

[Anonymous]

I don't have a specific example in mind at this time. Thanks for the offer, I might hit ya up when I have some "real" time to spend on this. -- Autodesk Discussion Group Facilitator "James Maeding" wrote in message news:s2fpi01dnearrvp2pp6c2j04nuvknk0ipn@4ax.com... > What kind of sample routine would you like to see? I can write it and post it...

[Anonymous]

Chad what do you think about this ? "Terry W. Dotson" wrote in message news:412c74a8$1_2@newsprd01... > And what happens when the ARX spec changes yet again in a future AutoCAD > making it incompatible, and the authors decide it hasn'nt been > profitable enough to continue? > > Isn't this why Tony quit doing AcadX? > > Terry

[Anonymous]

I would add my love for object dcl. It makes for a very nice product. If you want to take your dialogs to the next level, its the only way to go when using lisp. Even when loooking down the road. Chances are Autodesk is going to change something in the next version. Then you are at the same place. Martin Shoemaker |>ODCL uses an arx file to house its methods. The arx for 2005 came out |>very promptly. |> |>Be careful looking down the road. It's true that there's never a |>guarantee that a product will be updated. It's also true that ODCL |>provides a lot of extra capability and cuts development time. Only you |>can decide whether the benefit outweighs the risk for you with what you |>do with AutoCad. |> |>Martin |> |> |> |>R.K. McSwain wrote: |>> "James Maeding" wrote... |>> |>>>Have you tried ObjectDcl? Its a Lisper's dream.... |>> |>> |>> |>> Hmmm. I did not see an answer in there. I'm guessing that you do not get the source code. |>> |>> My point was the same as Terry's |>> |>> What happens to all your applications that depend on ObjectDCL if you do not have (and cannot get) a current version of it? |>> |>> I'm not knocking the usefulness of the product, just thinking down the road.... David

[Anonymous]

"David Allen" <*@*.com> wrote... > I would add my love for object dcl. It makes for a very nice product. If you want > to take your dialogs to the next level, its the only way to go when using lisp. > > Even when loooking down the road. Chances are Autodesk is going to change > something in the next version. Then you are at the same place. ▐▐▐▐▐▐▐▐▐▐▐▐▐▐▐▐▐▐▐ But if Autodesk changes something, you can recompile your own code since you have the source, or in the case of lisp/vba, correct anything necessary, and you are good to go. But what do you do if you are using functions provided by a 3rd party tool (such as ObjectDCL or DOSLIB) and those applications, for whatever reason, are not updated ?? You could have a big problem. Try loading a R13 ARX file in 2002.

[Anonymous]

Ah but that's if the previous cad manager does not run off with the code, sorry bad flashback. Would you like to develop from scratch the functionality of ObjectDCL or Doslib? If you don't use what they are providing then you are missing out on some very handy and cool stuff. Its a catch-22 Last item: Ah that brings up a constant complaint of mine. Autodesk should allow legacy arx code to be ran in newer versions via some sort of emulation or something. This having to get new ARX's for new version of autocad is pure bs. "R.K. McSwain" |>"David Allen" <*@*.com> wrote... |>> I would add my love for object dcl. It makes for a very nice product. If you want |>> to take your dialogs to the next level, its the only way to go when using lisp. |>> |>> Even when loooking down the road. Chances are Autodesk is going to change |>> something in the next version. Then you are at the same place. |> |>??????????????????? |> |> |>But if Autodesk changes something, you can recompile your own code since you have the source, or in the case of lisp/vba, correct anything necessary, and you are good to go. |> |>But what do you do if you are using functions provided by a 3rd party tool (such as ObjectDCL or DOSLIB) and those applications, for whatever reason, are not updated ?? |> |>You could have a big problem. |> |>Try loading a R13 ARX file in 2002. David

[Anonymous]

> 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. James Maeding wrote: > interesting, I like that idea. > We still need command line interpretation though... 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. --

[Anonymous]

R.K. McSwain... >But if Autodesk changes something, you can recompile your own code since you have the source, or in the case of lisp/vba, correct anything necessary, and you are >good to go. >But what do you do if you are using functions provided by a 3rd party tool (such as ObjectDCL or DOSLIB) and those applications, for whatever reason, are not >updated ?? >You could have a big problem. >Try loading a R13 ARX file in 2002. Very good points... hmm Now, anyone have an idea of how many could be using ODCL?....

[Anonymous]

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. David

[Anonymous]

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. > >

[Anonymous]

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

[Anonymous]

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. --

[Anonymous]

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

[cwanless]

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.

[Anonymous]

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 > >

[cwanless]

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.

[cwanless]

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.

[cwanless]

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.

[Anonymous]

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