VBA vs LISP
Well, it seems I'm posting a lot of new topics here. I'm working for a company where I need to create some custom applications, and I am debating how best to approach it.LISP seems to be the most compatable method between AutoCAD and BricsCAD. Though, I wish it were more so.LISP can be run on a more basic version of BricsCad, so cheaper to run per station.VBA makes it easy to create a beautiful user interface.VBA has a nice programming interface. (and you are not Lost In Stupid Parenthesis)VBA for IntelliCAD doesn't seem to have any real compatability with AutoCAD VBA, because the point formats are different.Any other comments on one method of customizing vs the other?Joe Dunfee
Comments
-
I am going with LISP. It was not an easy decision. I really like the programming enviroment for Visual Basic.The main thing that made the decision for me was the complete lack of documentation for IntelliCAD's version of Visual basic.I able to use many of the 3rd party books on AutoCAD's LISP. And while there are plenty of AutoCad Visual Basic books, Intellicad's approach to using Visual Basic is so different from AutoCAD it is too cumbersome for a beginner to manage.Joe Dunfee
0 -
LISP has real limitations for us. If your needs are confined to BricsCAD, then you may be ok. With VBA, you will be able to incorporate other windows applications into your solutions, i.e. Excel and Access. Also, any knowledge relating to VBA can be used in those other applications to develop macros not related to CAD ... my 2 cents
0 -
I'm still prepared to believe VBA is good, but from the "promise" of VBA in Icad 98 to later failed attempts at installing pro versions, I have never actually had an environment in which it would work. That's not VBA's fault (directly), but I have to admit not being able to master even the basics of VBA in Msoft Word the one time I had the chance. Just thick I guess.
0 -
Joe,perhaps this is only going to make you hesitate more, but still... we are working on a new COM API for BricsCad which will no longer be different from the AutoCad COM API. Not only will this make the task of porting applications redundant, it will also allow to use the existing books on AutoCad COM.This is scheduled to become available by the end of this yearHans De Backer
0 -
Thank you for that bit of information. I've realized now that I do want the project to be done with VBA. The new compatability with AutoCAD will be an immense help. I will try to put off the project until I can get the new version.Any chance of getting to start my project using a Beta release?Joe Dunfee
0 -
I wanted to add one more comment, as a suggestion to the programmers responsible for the VBA enviroment.Please make a significant effort to make everything compatable with the AutoCAD version.If you can't download a VBA application and use it without modification, then any so-called compatability between AutoCAD VBA and InteliCAD VBA is useless for the non-programmer. Even for the programmer, it is not a casual thing to discover the problem and modify the code for a moderately complex application.I realize the possibility that there are things which may prevent total compatability, but in this case consider a conversion utility. I've been told repeatably that it is easy to convert an AutoCAD LISP into an InteliCAD compatable lisp, but in practice I've never successfully done it (not that I've put a great deal of effort into it). If it really is that simple to do, then a utility program should be able to to it automatically.Joe Dunfee
0 -
After reading all comments on this topic and trying to answer many of the same questions to my self, I would like to ask how does a company like Eagle Point or Bricscad with its Architecturals create a program that can be used in either environment (Bricscad/Autocad), do they actually write and maintain two separate programs in two very similar languages, yet a bit different or is there something we are missing?, our company is setting up a development team and we would like to be able to create a program that would work in a mixed environment but with the current differences this seems cumbersome, or am I mistaken?Regards,José BarzunaAISAsoft S.A.
0 -
Currently, developing applications that run both on AutoCad and BricsCad is indeed (too) cumbersome.To make the efforts of dwg-application developers more effective, we have been investing considerably on several fronts: besides making our COM API fully compatible, we are extending our LISP API with all currently missing VLAX functions, and the LISP engine itself gets replaced by one of the fastest engines around.Concerning C++ API'S: the ADS/SDS compatibity has been very high since several years, but the lack of an ARX compatible API was sorely felt, so we have been working on an ARX equivalent that will allow to keep the porting effort of ARX applications to an absolute minimum.The new COM and LISP will ship end of this year, while at that moment we also plan to offer partial support of ARX equivalent libraries. This support will be further extended in the course of 2007.Concerning how Architecturals was developed:we created 'DwgLib', an abstraction layer that hides the details of the underlying dwg platform (AutoCad-BricsCad) for the programmer. This DwgLib contains mainly I/O functionality. When running on e.g. Acad, the wrapper functions eventually call ARX functions, while when running on BricsCad (or older ACAD versions) this results in calling ADS/SDS functions.This way we could keep the code base for the different dwg-platforms exactly the same. If I'm not mistaken, Eagle point used a similar approach for their applications.The Architecturals COM API in turn, also makes abstraction of the underlying dwg-platform: without recompilation an Architecturals COM application runs both on Architecturals for Acad and Architecturals for Bcad.The DwgLib (including source code) can be licensed from BricsCad, if this looks of interest to you please contact the BricsCad office.We hope the above information gives an idea of our serious commitment to the dwg-application developers community.Best regards,Hans
0 -
Hans,Thanks for such a complete response on this issue, would you say that it is reasonable and safe to initiate development using an Autocad program and it will eventually port well to Bricscad by the end of the year?, after all, development should take at least 6 months for what I have in mindRegards,José
0 -
José,for VBA and LISP I would indeed suggest to start developing on AutoCad now. In the coming months (Q3 2006) we will provide developers with BricsCad beta builds containing our renewed API's, so at that point I would recommend to make the switch, which should be painless. For ARX development we need a bit more time to make the switch painless...Best regards,Hans
0 -
Hans,Thanks again for your help.One more detail, current VBA for Bricscad seems to be a Visual Basic V6, what version of Visual Basic will you be supporting in this API, will it be V6 or .NETRegards,José
0 -
The IDE will still be VBA.Please note that this does not keep you from developing a VB .NET app that uses the COM API.
0