Month: January 2007

Introducing OpenDCL for AutoCAD

AutoLISP programmers may remember a product named ObjectDCL, by 3rd Day Software. ObjectDCL was released as open source in the summer of 2006 by developer Chad Wanless due to his inability to continue supporting the software because of “health reasons”. At the time, many users of ObjectDCL hoped that someone would update the code to work in AutoCAD 2007. Programmer David Robison did some work to get AutoCAD 2007 supported, but the project has been languishing, almost to the point of extinction.

After being asked by several ObjectDCL users whether I could help, I decided a few weeks ago to contribute to the community by getting the original C++ code updated to support AutoCAD 2007. As I am wont to do, I’ve ended up re-architecting much of the code in the process.

The results of my work are available now at the new OpenDCL project on SourceForge. The new 4.0 release is still in the alpha testing phase. If you program in AutoLISP and want to create rich user interfaces for your applications, check it out!

I’ll take web sites for $200, Alex: Part IV

(continued from Part III)

Creating custom modules for DotNetNuke is an esoteric process that I don’t recommend unless you’re prepared to invest quite a bit of time and effort. I slogged through the process because I’m too stubborn to quit, but it’s hardly worth the investment in time for a one-off custom module. I don’t expect many of my readers to try it anyway, so I won’t bother describing the technical aspects in any detail.

My primary objective was to create a Docket History module that renders a court case’s docket history in an HTML table. Since DotNetNuke modules (generally) render data from a database, a large part of my work was defining the database structures and database interface code. The database work was an opportunity to learn more about SQL syntax, something I had never really delved into very deeply in the past. As the module began taking shape, I found myself having to refactor over and over again, often changing the database structure in the process. Changing the database structure meant recreating the data and rewriting the database interface code.

Once I had a working Docket History module, I decided to apply what I had learned to a second custom module for the Grapevine page of the web site. This module would simply display a date-ordered list of links to external web pages, including a column for the “Source” of the linked page — a bit less complicated than my first module. It should come as no surprise that the second one took about a tenth as much time as the first, mainly because I spent much less time refactoring. That doesn’t mean I got it right the first time. In fact, I eventually went back and made yet more changes to the first module to reflect the optimizations and design improvements I discovered while working on the second.

To recap, the web site today consists of DotNetNuke 4.4.0 “out-of-the-box” (I upgraded to 4.4.0 from the original 4.3.7 after 4.4.0 shipped in late December), a free skin from Nina’s Free Skins, the two custom modules I created, and a bug fix to correct a PDF file download issue as described in a DotNetNuke forum thread. Total time spent was around 200 hours over four weeks. Finally, a complete web site — or was it? In Part V, find out what the last missing ingredient was.

AutoCAD drawing files: possession is 9/10 of the law?

The title sums up the puzzling conclusion in a recent 6th Circuit Court of Appeals ruling (CA6 Grusenmeyer Decision.pdf) in a decision about a copyright infringement claim filed by Cleveland architect Jeffrey Grusenmeyer.

Grusenmeyer had contracted to provide a “master plan” for Magnificat High School. The master plan was provided to Magnificat in hardcopy format, Magnificat paid the architect $15,000 as agreed in the contract, and the project was apparently concluded. Some time later, a Magnificat facility manager requested DWG files for “personal use”. Grusenmeyer asserted at the time that he retained all rights to the DWG files but agreed to provide them on the condition they only be used internally and not be further distributed.

Fast forward to the eventual “request for proposal” for an anticipated new building at the school. Upon request, Magnificat provided the Grusenmeyer files to the defendants (a competing architectural firm), who then used portions of the files in their winning proposal. The defendants were aware that Grusenmeyer claimed copyrights to the files, but they used the files anyway. The appeals court notes that “[a]ccording to the individual DSC architects, such reliance on drawings of existing conditions is routine in the industry.”

In affirming the district court’s summary judgement in favor of the defendants, the appeals court noted that the contract between Grusenmeyer and his client (Magificat High School) provided that Grusenmeyer would “provide a master plan for the implementation of the capital improvements program, including plans, renderings, and perspectives suitable for use in presentation and future reference during master plan implementation.” They concluded that this “plain language” gave Magnificat permission to send the AutoCAD DWG files to Grusenmeyer’s competitor.

The district court had previously ruled that Grusenmeyer’s drawings were not sufficiently original to warrant copyright protection, but the appeals court did not address the copyrightability issue at all, dismissing the infringement claim out of hand with their opinion that Grusenmeyer had already given Magnificat carte blanche copyrights to the files vis a vis the quoted clause in their contract — even though the files were never provided as part of the contract!

I think the court erred in determining that the DWG files were subject to the terms of the master plan contract (its incorrect interpretation of the contract notwithstanding), but what I find really surprising in the ruling is the appellate court’s complete disregard of the plaintiff’s claimed and federally registered copyrights.

The moral of the story
If you are providing electronic files, don’t rely on copyright law alone to protect your intellectual property. This case reinforces the 3 C’s for protecting AutoCAD DWG files: copyright, contract, and CADLock.

Update
William Patry (Senior Copyright Counsel, Google Inc.) writes about this case at The Patry Copyright Blog: Make Sure the Contract is Signed.

I’ll take web sites for $200, Alex: Part III

(continued from Part II)

DotNetNuke (aka DNN) is not simple to set up. It needs at least the free SQL Server Express Edition on the host system (full SQL Server requires some changes to the default configuration) and either IIS or another ASP .NET 2.0 compatible web server to run on. If you have Visual Studio 2005 fully installed, you have all you need to run DNN.

There are a number of manual steps involved, and the steps are different depending on the environment, and whether or not you have the version with full source code included. The quickest route to an operational DNN installation is to download the latest ‘Install’ files from http://www.dotnetnuke.com/ and unzip them to a new folder. Next, make sure the ASPNET account has modify, read, execute, and write access to that folder (new folders will not have this permission by default — it must be added). Next, create a new virtual directory in IIS and map the new virtual directory to the new DNN folder. Once this is done, open a browser and browse to the new virtual directory. This will initiate the DNN installation sequence, where it creates and populates its database with default settings. Once the installation sequence completes, DNN is ready to use, and looks like this:

The structure of DotNetNuke is designed so that a single DNN installation consists of a host (the person controlling the physical computer on which the web site lives) and any number of portals (that may be administered by others). The distinction is important when changing settings because host settings can place limits on portal settings, and portal settings can override host default settings. In my case, I am both host and administrator of the single portal.

A DNN portal is a single web site. A web site consists of web pages (also called “tabs” in DNN lingo), each containing controls that may be added to predefined “panes” on the page. Before you can add new controls to a page, the controls must be defined. You can define controls by importing “modules”. These can be third party modules, or one of the 15 or so standard modules that come with DNN.

To actually modify the web site, you simply log in to the web site as an administrator. As soon as you are logged in as an administrator, the web pages change to reveal administrative controls that you can use to modify the layout or module settings of the current page, like this:

Notice the control panel at the top of the page, as well as the new hyperlinks on the controls themselves. These can be used to change individual module settings, or to move modules around the page (or even to a different page) very quickly and easily. There is also a new “Admin” menu page that an administrator can use to manage all other aspects of the web site such as the skins, user accounts, security roles, and other site settings. In theory, all this editing can be done on a live web site; in practice, most changes should be made first on a local mirror of the site, then uploaded to the server once they have been fully tested.

The beauty of a CMS system is that the software makes it possible to build a complete multi-page web site in minutes. Changing skins is quick and can change the look and feel of an entire web site instantly. Unfortunately, there’s always a catch. The price of quick-and-easy is that you have to live with the quirks, bugs, and inconsistencies that come with the software. I spent a lot of time trying to fix some little things that I wasn’t happy with. In some cases I was able to fix them myself, but in the end I just had to learn to live with numerous small irritants.

Coming up in Part IV, completing my first custom module.

My ManuSoft manifest manifesto

With the advent of Visual Studio 2005 and automatically generated manifest files, the topic of when and how to use manifest files comes up occasionally. Since a default ObjectARX wizard generated project in Visual Studio 2005 generates an embedded manifest by default, most people don’t even think about it. Of course that was the whole idea — the manifest would ensure that the correct dependent DLLs get loaded, and voila, no *need* to think about it. One of my programming axioms applies in this case: TANSTAAFL.

The problem is that ObjectARX applications are not in charge. AutoCAD is in charge, and it will decide which VC runtime and MFC runtime DLLs to load. If your ObjectARX application loads a different VC or MFC runtime than the ones AutoCAD is using, you’ll encounter big problems. I’ve always advised disabling the manifest completely (see my ObjectARX Tips page) to avoid such a possibility. Unfortunately, there’s a catch.

The problem is that linking to the ATL80.DLL file isn’t possible by just disabling the manifest and doing nothing more. ATL is now a side-by-side (SxS) assembly, and it no longer lives on the Windows support path, so a standard un-manifested DLL won’t be able to find it. The preferred solution is to link statically to ATL (see Configuration -> General -> ‘Use of ATL’ in VS 2005 project properties) and avoid the problem altogether. If you only have one module that uses ATL, this is always the best solution.

The less desirable solution is to add a *manually-created* manifest that specifies the desired ATL SxS assembly, but ignores the VC and MFC runtime DLLs. You’ll still need to decide whether to make ATL shared or private, and in either case you *must* distribute ATL with your application to ensure that it is available when your application is deployed. You can cheat, and let VS generate your manifest file (instruct it to *not* embed the file), then just edit the resulting .manifest file to remove references to the VC and MFC assemblies. For example, here’s one that I generated (you’ll need to generate your own to ensure that the manifest matches the version you are redistributing):

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<assembly xmlns=”urn:schemas-microsoft-com:asm.v1″ manifestversion=”1.0″>
<dependency>
<dependentassembly>
<assemblyidentity type=”win32″ name=”Microsoft.VC80.ATL” version=”8.0.50727.762″ processorarchitecture=”x86″ publickeytoken=”1fc8b3b9a1e18e3b”>
</assemblyidentity>
</dependentassembly>
</dependency>
</assembly>

In my work, I’ve had very little need for manifests. The VC optimizer is able to strip the unused portions of statically linked ATL out of your code, leaving a much smaller footprint than the entire assembly would require. This eliminates the need to redistribute ATL with your application, thus reducing the overall potential for deployment issues. Nevertheless, there are exceptions to every rule, and your mileage may vary.