I had the good fortune of hearing Deelip Menezes deliver the keynote address at the Bricsys 2010 Conference in person. If you missed it, check out the video now at the Bricsys web site. The question and answer session after the speech is an excellent harbinger of the discussions to come if Deelip is correct in his prediction about CAD on the cloud.
Tag: Bricscad
Bricsys 2010 Developer Conference Post Mortem
I am back home after a whirlwind trip to the Bricsys 2010 Conference. I’m very happy to be back to Ohio food and my own bed. It was a great experience and well worth the trouble.
I’ve written before (and here) about the problem with food at conferences, and this one was no different. Unfortunately, there are no Burger Kings in Belgium, so the problem was compounded. I was excited when I saw a restaurant touting “American Food”, unfortunately it was “American Food as Europeans Imagine It”, which is not American food at all.
The hotel was, well, let’s just say you got that genuine experience of living in the past. Not quite the stone age past, but clearly before the age of modern locks and clocks — and well before air conditioning was invented. To make matters worse, housekeeping did not replace the provided shampoo and soap, so I had to make do with no soap on day 2 of the conference. The concert hall where the conference was held was also not air conditioned, which just compounded the problem — and certainly contributed to the dispersement of attendees from initially a small intimate group on day 1 to most of us sitting in the galleries by ourselves by the end of day 2.
The good news is that all the suffering was worthwhile. Bricsys was very accomodating, and it was a pleasure to meet modern day Robin Hood and Bricsys CEO Erik de Keyser and his merry band of men. Deelip Menezes’ keynote address about the future (cloud) of CAD (cloud) was (cloud) excellent, and the discussion that followed turned into a 12 round bout that Deelip played to a draw. Well done, Deelip, well done. I’m sure the fight will continue virtually, so take heed, and stay out of the line of fire.
I learned that Bricsys has made an impressive investment of time and resources into a foundation upon which to build a “DWG CAD” business. This is no longer about who can take on Autodesk. Autodesk conceded the AutoCAD (or “DWG”) market with their push toward subscription (aka “maintenance”), annual release cycles, and artificially high pricing on their platform technologies. There are literally dozens of companies trying to capture that market: products like ZWCAD and GstarCAD from China are hot on the heels of Bricscad. This is about who will emerge to control the market that Autodesk abandoned, and to some extent about how Autodesk will respond.
Bricscad is currently the clear leader among DWG CAD companies in terms of technical capabilities, but at least to date, it’s mostly AutoCAD application developers that recognize this (because of Bricsys’ very successful effort to make their BRX API source code compatible with ObjectARX). The question is whether they can convince consumers that Bricscad is the best choice. I think we will be a long way toward answering that question by this time next year, and of course the answer will be critically important to the DWG CAD market. I think it was shrewd of Bricsys to invite thought leaders like Deelip to this conference, but that is only a first step. Still, the very fact that I am writing and Deelip is blogging and tweeting about Bricscad is an important milestone on the road to respect.
[Full Disclosure: Bricsys paid for all my travel and conference expenses.]
Belgium Bound
Bricsys asked me to give a short presentation about OpenDCL to developers at their Bricsys 2010 Conference in Bruges next week. I’m looking forward to meet keynote speaker Deelip Menezes and other familiar names in the CAD community, and of course planning to learn more about the ever evolving Bricscad platform.
[Full Disclosure: Bricsys is paying for all my travel and conference expenses.]
Automatic LISP Loading
There are a myriad of ways to load AutoLISP applications in AutoCAD, including acaddoc.lsp, an .mnl file, the Startup Suite, and manually by various means. For application developers wishing to deploy their applications to others, all of these methods have drawbacks. The ideal solution should be easy to implement in an installation program, require minimal or zero changes to the user’s AutoCAD configuration, work the same way across all versions of AutoCAD, and easily undone when the application is uninstalled.
ObjectARX application developers have long used registry demand loading to load their applications automatically, either when AutoCAD starts or when the user enters a command that the application defines. Registry demand loading is relatively easy to set up and meets the other requirements for an ideal solution, except for one problem: it works only with ObjectARX modules (or with .NET modules in AutoCAD 2006 and later).
Many years ago, I created a solution to this problem by building a small stub ObjectARX module that did nothing but load an associated LISP file. This effectively allows the registry demand loading mechanism to be used for loading a LISP file. If you develop AutoLISP applications that could benefit from registry demand loading, then I have a Christmas present for you: LspLoad.zip contains a complete suite of newly updated stub modules for all versions of AutoCAD from AutoCAD 2000 to AutoCAD 2010, plus modules for Bricscad 9 and 10, which also supports registry demand loading.
To use the stub modules, just rename them so that the base filename matches your application’s main LISP filename, then install them in the same folder as the LISP file and create the registry demand load entries. The only work you have to do is to get the stub module to load. You can simply drag and drop the appropriate stub module into a running instance of AutoCAD in order to test it.
[Update 2014-02-18: See Building a commercial grade lisp plugin installer in 5 easy steps for a solution to setting up the demand load keys using Inno Setup.]
Creating the demand loading registry keys is not difficult, but it may require some programming. I write custom actions for my installation programs that enumerate all installed AutoCAD versions and flavors, and set up the demand load keys for every one. However you do it, the final result should look something like this (for AutoCAD 2010 on my system):
In this screen shot, I created an application called “!LspLoadTest” (the “!” was added just so it displayed at the beginning of the list). I added the minimum required subkeys. The LOADER string value is set to the complete path of the stub module, and LOADCTRLS is set to a value of 2, which means I want the application loaded when AutoCAD starts. LOADCTRLS is a bit coded value; for use with LspLoad, it’s only useful values are 2 or 4. A value of 4 means “load when my command is invoked”; this mode requires a COMMANDS subkey that lists the defined commands.
The way it works is very simple. In the example above, you can see that I renamed the module (but left the “.18.x64.arx” so that I can tell it apart). I then added !LspLoadTest.lsp to the W:LspLoad folder. That file contained the following:
(princ “nThis test file loaded from “)
(princ (if GetPathOf!LspLoadTest (GetPathOf!LspLoadTest) “<unknown>”))
(princ)
Now when I start AutoCAD 2010, I see on the command line:
This test file loaded from W:\LspLoad
These files are free to use for any purpose. Have a great holiday, everyone!