Post

The increased sharing of electronic CAD data (ala BIM) holds a lot of promise, but it also exposes companies and individuals to additional liability and risk. This additional risk is coming into focus more and more as actual cases of costly legal battles confront engineers and architects. The June 2008 AUGI wishlist results contain “Design File Locking” as the top wish by a substantial margin, and Shaan Hurley lists it as number 3 in the AU 2008 AutoCAD wish list. Clearly, interest in file and IP security has been growing steadily. As demand for IP security grows, there are sure to be snake oil security vendors trying to cash in on it. I received a spam email a few days ago from SafeNet, Inc. promising “a cost-effective and easy to integrate solution that provides reliable and effective security through the use of digital signatures.” Whenever I see such statements with a long string of buzzwords, my snake oil alarm goes on alert. Digital signatures are for authentication and establishing trust – they cannot and do not provide “reliable and effective security”, although I suppose they could be used by a system that does. In the last year or two, a number of companies have claimed to market software that “secures” AutoCAD DWG files. When I see such a claim, it invariably refers to software that creates an anonymous unequally scaled MINSERT entity. These can be created or “exploded” with a few lines of AutoLISP code. Frequently these companies claim to “encrypt” the drawing, which may sound sexy, but is an outright lie. If this is a level of “security” that meets your needs, at least use one of the many free versions posted throughout the internet (DETER.VLX from DotSoft is one I know of). There are solutions, but they always require changes in the workflow process that involve difficult tradeoffs and careful evaluation of what is technically feasible and practical versus the costs of implementing the changes. There is no such thing as installing a single piece of software to instantly solve the problem. If you are looking for ways to protect intellectual property in your drawing files, don’t be fooled by snake oil security vendors. Disclaimer: One of my hats is the president of CADLock, Inc., makers of CADVault for AutoCAD.

Did you ever wonder what press release writers do in their spare time? Given Autodesk's recent trademark litigation with SolidWorks and related efforts by Autodesk to trademark "DWG", and given the fact that US Patent and Trademark Office (USPTO) trademark examiners are known to use Wikipedia during their research, it doesn't take an evil genius to realize that a little subversive editing here and there might be helpful to the corporate cause. So, I decided to use Wikiscanner to go spelunking through the labyrinth of Wikipedia editing history to see if I could unearth any nuggets. ...

Of course I’m talking about Autodesk’s newly reinvented nomenclature for bug fixes. Once upon a time they were known as bug fixes, then service packs, and now “updates”. Is the Autodesk marketing department running amok? The subtle spin is certainly a sign of the times, but I wonder if the change in terminology comes about for another reason as well. Autodesk promises “features extensions” to subscription customers. They have had difficulty delivering such extensions on a consistent basis. One of the reasons, I suspect, is that developers of extensions encounter the same brick walls that third party developers battle all the time: AutoCAD bugs, of course; but also incomplete APIs and feature limitations. It’s possible that updates not only fix bugs, but also fill gaps so that extension developers can get their extensions working. Then again, the change in terminology might be part of a new fad. My wife, who is an engineer working in the automotive industry, informs me that they no longer issue drawing revisions in her company. Instead, they now issue “updates”. I wonder how long it will be before auto mechanics stop repairing cars and start updating them instead.

If you’re an AutoLISP programmer, you’ve probably heard about OpenDCL. Maybe you’ve even checked it out, but it looked complicated and you weren’t sure whether it was worth the trouble to learn how to use it. Either way, do yourself a favor and spend 10 minutes to go through the following 10-step quick introduction to OpenDCL. Download and install OpenDCL Studio. Select the latest version in your desired language (ENU in the filename means US English). The download is an .msi file that can be cleanly uninstalled afterward.Start AutoCAD (2004 or later). Use the APPLOAD command to load _MasterDemo.lsp from the OpenDCL Studio samples folder (it will be located in a language subfolder of the main OpenDCL Studio folder). When you close the APPLOAD dialog, the OpenDCL ‘MasterDemo’ dockable form will appear.Click on the [ListView] button to run the ListView sample. The ListView sample is very simple and will demonstrate some basic principles of OpenDCL. Leave it running as you proceed through the following steps.Locate and open ListView.lsp in the OpenDCL Studio samples folder. ListView.lsp contains all the code for the ListView sample. Look for the c:ListViewDlg_Close_Clicked function defined near the end of that file. That function is called an “event handler”, and it is the lisp function that is executed when the [Close] button is pressed. The event handler for the [Close] button simply closes the dialog. The c:ListViewDlg_OnInitialize event handler function initializes the controls on the dialog before it is displayed.Locate and open ListView.odcl in the OpenDCL Studio samples folder. Files with an .odcl extension can be opened and edited in OpenDCL Studio. OpenDCL Studio is used to design the user interface elements in an OpenDCL project. In the project tree pane, open the ‘Modal Forms’ folder, then double click on ListViewDlg. The ListView form will be displayed in design mode.Click on the [Close] button on the ListView form. In the font toolbar at the top of the editor, press the [B] button to make the font bold. Notice that the button’s caption becomes bold. In the ‘Properties’ pane, double click on the ‘Height’ property value and change it to 20. Press [Enter] to apply the new value. Use your mouse to drag the bottom of the button in design view to resize it dynamically.Leaving OpenDCL Studio open, switch back to AutoCAD. Resize the ListView dialog, and notice how the controls it contains are also resized. Now switch back to OpenDCL Studio, make sure the [Close] button is selected, then click in the right column of the ‘(Wizard)’ property in the Properties pane (or right click on the button control and select ‘Properties’ in the control’s context menu). In the Control Properties Wizard, the Geometry tab shows that the button’s “Left Side Alignment” has been set to “Offset From Center of Dialog” and it’s “Top Side Alignment” has been set to “Offset From Bottom Edge”. Once these properties are set, no additional code is needed for the control to react correctly when the dialog is resized.Exit AutoCAD, then restart. Enter the OPENDCL command. This command demand-loads the OpenDCL Runtime using AutoCAD demand loading mechanism. The OpenDCL Runtime must be loaded before the OpenDCL functions will work. The OpenDCL Studio installation includes OpenDCL Runtime, so it already exists on your computer.If you are developing an application for use by others, you’ll need to download and distribute the OpenDCL Runtime along with your application. This is best done by incorporating the OpenDCL Runtime merge module for your language directly into your own application’s installation script. Alternatively, you can distribute the standalone OpenDCL Runtime .msi file for your language, or publish the URL where end users can download the latest version.Switch back to OpenDCL Studio and double click on the [Close] button control. Intelligent help displays all the properties, methods, and events of the selected control, including their AutoLISP syntax. Click on a property, method, or event in the left pane to see detailed information for it.Once you complete these ten steps, you are only a few minutes away from creating a fully functional OpenDCL application. Give it a try! ...

InfoWorld columnist and legendary consumer advocate Ed Foster died over the weekend. Ed was a tireless crusader for consumer rights in the digital age, and he will certainly be missed. For many years Ed has authored GripeLine, where he called companies and politicians to task for abusive anti-consumer practices. I’ve written before about how Ed exposed and publicised shamefully lopsided software license agreements, including Autodesk’s and Adobe’s. Recently, Ed commented about the May, 2008 Vernor decision (see my CAD/Court web site for more information about the Vernor case). It will be no easy task to fill Ed’s shoes. We can be certain, though, that his work must go on.

This is a story about my 11 year old son, Nick, and a father’s pride. I coached Nick’s Little League baseball team this year, and now that the regular season is over I’m coaching an 11-12 year old All Star team. Being the youngest on the team, Nick struggles with his self confidence even though he’s an excellent baseball player. He’s not the tallest player, but he’s faster and more athletic than many of his older teammates. Even so, he doesn’t want to take any risks or make any mistakes, and his insecurities often prevent him from performing at his best. A few weeks ago in the league tournament Nick hit a ball against the fence, just short of going over. That was the closest he came all season to hitting one out, and was perhaps the first time he started to believe that it was possible. A few nights after our team was eliminated from the championship tournament, a kid hit a walk off grand slam with 1 out in the bottom of the 6th, down 9 - 6. Nick and I were there to watch it. I heard that the same kid hit one more out of the park later in the tournament. Those were very likely the only two over-the-fence home runs all year in our local league. Sometime during tournament time, Nick’s baseball bat disappeared from the trunk of my car. I suspect he didn’t close the trunk all the way one night, and someone stole it during the night. The following week, in exchange for Nick agreeing to mow the lawn this summer, I bought him a shiny new baseball bat, a new bat bag, and new cleats to replace the old ones with holes in their toes. Nick was itching to play again so he could try out his new toys. Fast forward to the all star team’s second scrimmage earlier this week. In his first at bat, Nick got walked (then stole second, third, and home over the course of the next few pitches). In his second at bat, Nick hit a hard line drive into the gap, and got to second with a stand-up double. It was just a scrimmage, there was no pressure, and Nick was feeling good about himself, perhaps even daring to feel confident in himself. His third time at the plate, Nick crushed the first pitch well over the center field fence amid groans from the opposing team. There was a mixture of surprise and elation among the other players on our team. Some had never seen a player at this level hit a ball over the fence, and I even had to remind them that they were allowed to enter the field to greet Nick as he crossed home plate. The excitement was soon forgotten as the game moved along, until Nick came up to bat again and everyone jokingly told him to hit another home run. And then, with two strikes, two out, and two on, he did it again! It’s amazing how much difference a shiny new bat can make.

From the NewsFeed on my CAD/Court web site: “The court today issued an order denying Autodesk’s motion to dismiss the charges in the Vernor lawsuit. Normally such a denial is perfunctory and mundane, but in this ruling the court performs a breathtaking analysis of whether the AutoCAD software was a sale or a license, and reaches conclusions that, if not reversed, are certain to change the face of software sales in the USA. Technically, the scope of this order is limited to simply refusing to grant Autodesk’s motion to dismiss the lawsuit, but the implications of the judge’s analysis are almost stunning in their rejection of Autodesk’s legal claims. I’m sure you will be hearing much more about this order in the coming weeks, as the entire software industry will certainly take notice of this case."

I have presented a class entitled High Octane ObjectARX at Autodesk University the past two years. In 2006 the focus was on project organization, and last year I focused more on techniques for supporting multiple versions of AutoCAD with a single Visual Studio solution, touching briefly on testing and profiling. For 2008 I plan to focus on debugging. ...

Steve Johnson asks “where have all the developers gone?”, and Deelip Menezes wonders in a comment whether Autodesk’s annual release cycle for AutoCAD is part of the problem. I’ve always said that an annual release cycle is untenable. The annual release cycle is motivated by Autodesk’s desire to make the subscription program look attractive. Has it worked? Based on what I’ve read and heard through the grapevine, it has definitely worked. More customers than ever are choosing the subscription model. In many cases, the annual subscription business model actually works well for software like AutoCAD, providing benefits for both Autodesk and their customers. But subscription is not for everyone. In typical greedy big corporate fashion, Autodesk have overplayed their hand. Instead of concentrating on those customers for whom subscription makes sense and leaving the others to choose a different model, the “more is always better” marketing machine kicked in. Ergo, the annual release cycle carrot and the AutoCAD retirement program stick were invented. [Oh sorry, it’s called the Autodesk Loyalty Program.] I am already seeing the beginnings of a movement of discontent among Autodesk customers, and I expect the annual release cycle to collapse under its own weight within another year or two. In the meantime, tremendous damage is being done. Customers, third party developers, authors, and consultants all suffer under the strain of the annual release cycle, but that’s only the tip of the iceberg. To pull off annual releases, Autodesk have to be working on multiple versions of AutoCAD in parallel. While AutoCAD 2006 was being beta tested, AutoCAD 2007 and 2008 were already under development, and AutoCAD 2009 was already in the planning stages. When CUI was first introduced to the public, the new ribbon UI was likely already in the planning stages. Is it any wonder that the angry feedback about CUI was ignored? When you have an annual release cycle with 3 or 4 future releases on parallel tracks, you can’t just stop and fix a fundamental design flaw. All you can do is increase your public relations budget. The harm done to third party developers is substantial, but the inability to shift gears and correct fundamental design flaws is the real travesty of the annual release cycle.

QuikPik and Periscope are now available for AutoCAD 2009, and SuperPurge will be available later this week. QuikPik users, note that the quick buttons feature does not work with buttons on the new ribbon UI.

Like that day almost 50 years ago, could today be the day that ObjectARX has died? There have been a flurry of posts in the ObjectARX discussion group about problems downloading the new ObjectARX 2009 SDK. At first I dismissed the problems as new release hiccups, and expected things to get resolved in short order. Seeing that there were no new complaints this morning, I headed over to http://www.objectarx.com/ to download the new ObjectARX 2009 SDK. Instead of the new ObjectARX 2009 SDK, I received the following: ...

This Autodsys press release made me chuckle. Their IntelliCAD based AcceliCAD now supports custom entities, announces the press release. “Instead of creating custom objects as is necessary in some other CAD packages the application developer can instead use the primitives already built into the program such as LINEs, ARCs, CIRCLEs, and POLYLINEs.” Hmmm, that sounds an awful lot like blocks in AutoCAD – a feature AcceliCAD has surely supported since its inception. The press release continues, “That means there is no need to define grip points or editing operations for the entities because those functions are already built into AcceliCAD." ObjectARX programmers have been able to create custom objects in AutoCAD for years. One of the most common reasons for creating a custom object is to “define grip points or editing operations”. Otherwise, blocks work just fine in most cases.