Outside The Box
Random thoughts about AutoCAD, ObjectARX, and the meaning of life.
All Original Content Copyright 2006 - 2008 Owen Wengerd, All Rights Reserved
2010-03-11
AutoCAD versions since AutoCAD 2008 (and since AutoCAD LT 2009) have included both 32 bit and 64 bit flavors on the same media. If you install on a 64 bit Windows system, you get the 64 bit AutoCAD; otherwise you get the 32 bit AutoCAD. The 64 bit AutoCAD can take advantage of as much memory as you can throw at it, whereas the 32 bit version is limited to 2 GB (3 GB if you cheat). They should be otherwise identical in theory, but in practice there are major differences.
One big difference is VBA. Microsoft put VBA out to pasture many years ago when they introduced the .NET framework, so there will never be a 64 bit version of VBA. Autodesk had to resort to a seriously inefficient kludge to get it to work at all in the 64 bit flavor of AutoCAD (VBA has to run in a separate 32 bit process, which makes typical applications two orders of magnitude slower).
The other big difference is that any third party ObjectARX applications must be installed for the correct architecture. A 32 bit ObjectARX application will not work in a 64 bit AutoCAD. [Note that .NET (or "managed") applications typically work fine in both architectures -- I'm referring to native C++ ObjectARX applications only.]
On the Autodesk discussion groups, many people ask how they can install the 32 bit version of AutoCAD on their new 64 bit operating system. Why would they want to do that? Almost always because they need to use an application that is only available for 32 bit AutoCAD architectures, or because they discover that their VBA applications become unbearably slow.
It is possible, with some hacking of the AutoCAD installation database, to install the 32 bit flavor of AutoCAD on a 64 bit system, but I don't recommend that. There is just no excuse any more to not support the 64 bit architecture. If you find yourself in this situation, put pressure on the developer of the application to get it ported.
In fact, if you rely on an application that hasn't been ported to the 64 bit architecture, I'd like to hear from you. Add a comment to this post and let me know the name of the application. If you are a vendor or developer that has not yet ported your 32 bit application, please contact me -- I will gladly port it for you. Even large applications can typically be ported in several hours.
BTW, I am well aware that even Autodesk is guilty of not supporting 64 bit platforms in some of its vertical market AutoCAD versions (and corresponding object enablers). I certainly hope they remedy that situation in the next release cycle.
One big difference is VBA. Microsoft put VBA out to pasture many years ago when they introduced the .NET framework, so there will never be a 64 bit version of VBA. Autodesk had to resort to a seriously inefficient kludge to get it to work at all in the 64 bit flavor of AutoCAD (VBA has to run in a separate 32 bit process, which makes typical applications two orders of magnitude slower).
The other big difference is that any third party ObjectARX applications must be installed for the correct architecture. A 32 bit ObjectARX application will not work in a 64 bit AutoCAD. [Note that .NET (or "managed") applications typically work fine in both architectures -- I'm referring to native C++ ObjectARX applications only.]
On the Autodesk discussion groups, many people ask how they can install the 32 bit version of AutoCAD on their new 64 bit operating system. Why would they want to do that? Almost always because they need to use an application that is only available for 32 bit AutoCAD architectures, or because they discover that their VBA applications become unbearably slow.
It is possible, with some hacking of the AutoCAD installation database, to install the 32 bit flavor of AutoCAD on a 64 bit system, but I don't recommend that. There is just no excuse any more to not support the 64 bit architecture. If you find yourself in this situation, put pressure on the developer of the application to get it ported.
In fact, if you rely on an application that hasn't been ported to the 64 bit architecture, I'd like to hear from you. Add a comment to this post and let me know the name of the application. If you are a vendor or developer that has not yet ported your 32 bit application, please contact me -- I will gladly port it for you. Even large applications can typically be ported in several hours.
BTW, I am well aware that even Autodesk is guilty of not supporting 64 bit platforms in some of its vertical market AutoCAD versions (and corresponding object enablers). I certainly hope they remedy that situation in the next release cycle.
Labels: AutoCAD, Autodesk, ObjectARX, programming
2010-01-11
Many of you use my VC Build Hook utility to target multiple versions of AutoCAD from a single solution in Visual Studio 2008. Visual Studio 2010 now includes a new feature called native multi-targeting that performs the same function as VC Build Hook. The new feature works great for using build tools back to VC 7.1, but it does not work with VC 7, which is required for targeting AutoCAD versions 2006 and earlier.
The problem is that VC 7 chokes on Unicode response files. In earlier versions of Visual Studio you could set a project property to select Unicode or ANSI response files, but that property has been removed in Visual Studio 2010. I have been told by a Microsoft engineer that the problem will be addressed in SP1, presumably by adding that project property back.
The moral of the story is that you'll need to wait for SP1 before you'll be able to use the VC 7 build tools from within the Visual Studio 2010 IDE. I am not planning to update VC Build Hook to support Visual Studio 2010.
The problem is that VC 7 chokes on Unicode response files. In earlier versions of Visual Studio you could set a project property to select Unicode or ANSI response files, but that property has been removed in Visual Studio 2010. I have been told by a Microsoft engineer that the problem will be addressed in SP1, presumably by adding that project property back.
The moral of the story is that you'll need to wait for SP1 before you'll be able to use the VC 7 build tools from within the Visual Studio 2010 IDE. I am not planning to update VC Build Hook to support Visual Studio 2010.
Labels: ObjectARX, programming, Visual Studio
2009-12-24
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.
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:
Now when I start AutoCAD 2010, I see on the command line:
These files are free to use for any purpose. Have a great holiday, everyone!
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.
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) ""))
(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!
Labels: AutoCAD, Bricscad, ObjectARX, programming
2009-01-28
My participation in the Autodesk discussion groups has been severely curtailed since the notorious "upgrade" a few months ago. One of the many problems introduced by the upgrade is the loss of formatting. It's now virtually impossible to post messages that include inline AutoLISP or ObjectARX code without them being reformatted into unreadable garbage. Even attaching the code as a file is difficult (the "solution" is to rename files with a .txt extension!) As a result, many queries for programming help go unanswered. Autodesk has made an attempt to provide a fix, but a survey of the posts in any of the programming groups shows that it's not working*.
* [Thread has been removed by Autodesk, so link was changed to point to archived thread.]
The recently announced layoffs and related cost cutting measures at Autodesk have dimmed my hopes for a resolution. Therefore, I've decided to offer my services to fix the problem. Autodesk, I'm offering to donate my time to fix your discussion group software. Just give me access to a development and testing platform, and the right to modify or rewrite the code.
Readers, can I get an "Amen"?
Newsgroup%20needs%20complete%20overhaul.htm
* [Thread has been removed by Autodesk, so link was changed to point to archived thread.]
The recently announced layoffs and related cost cutting measures at Autodesk have dimmed my hopes for a resolution. Therefore, I've decided to offer my services to fix the problem. Autodesk, I'm offering to donate my time to fix your discussion group software. Just give me access to a development and testing platform, and the right to modify or rewrite the code.
Readers, can I get an "Amen"?
Newsgroup%20needs%20complete%20overhaul.htm
Labels: Autodesk, discussion groups, programming
2008-12-22
One of my many complaints about about the CUI system introduced in AutoCAD 2006 is that it's not very friendly to third party developers. In my opinion, it's not very friendly to end users either, but I digress...
One example of the unfriendly CUI is the case where a third party application installs a partial menu. In the pre-CUI days, adding a partial menu was an easy way to add an application specific menu to AutoCAD without making any changes to the end user's existing menu files. If the application was later uninstalled, the uninstall script could remove its menu and clean up the registry, leaving no trace behind. CUI breaks that scenario.
When a partial menu is loaded into AutoCAD 2006 and later, the CUI system actually writes a reference to the new partial menu into the main .cui file. To make matters worse, there is no clean way to programmatically remove those references because there is no deterministic way to locate all the .cui files used by a specific instance of AutoCAD from an uninstall script running outside of AutoCAD.
This would not be the end of the world if AutoCAD simply ignored references to missing files, but it doesn't. When the CUI command starts, it detects the missing files and displays an obnoxious message box that must be dismissed before the command will continue.
Then to top it off, AutoCAD displays a second message box that also must be dismissed.
I think it should be obvious even to an untrained UI designer how ridiculous this is.
In AutoCAD 2006 and 2007, the solution is to dutifully dismiss both dialogs, then when the CUI dialog finally appears, click [Apply] to rewrite the .cui file without the missing partial menu references. In AutoCAD 2008 and 2009, you have to first expand the 'Partial CUI Files' node in the Customization tab, then right-click on the unresolved partial menu file and select 'Unload CUI File', then click [Apply].
Labels: AutoCAD, CUI, programming
2008-05-12
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 2007 I plan to focus on debugging.
To get you in the mood, I decided to blog about a capability of Visual Studio that often goes unnoticed and unused: breaking on an exception. This works just like breaking on a code breakpoint, except the debugger breaks execution *before* the exception handler gets control, thus allowing you to get a clearer picture of what was happening immediately before the exception occurred.
In an ObjectARX project, all kinds of exceptions can occur. Sometimes they are perfectly normal exceptions caused by and handled by AutoCAD. Many times, especially during development, your code triggers an exception that causes AutoCAD to crash, and it's not obvious what caused things to go haywire.
When unexpected things happen while running your code under the debugger, the first order of business is to inspect the debug output window to determine what happened. The debug output window (Debug->Windows->Output) displays a message whenever an exception occurs. Sometimes a series of exceptions occur, usually all caused by the same root problem. Breaking when the first exception occurs will likely yield the most useful information about the cause.
Once you examine the debug output window to determine the type of exception that occurred, open the Exceptions dialog (Debug->Exceptions) and tell Visual Studio to break when the exception is thrown:
Visual Studio contains a prepopulated list of common exceptions to choose from, or you can add new ones if you need to break on an exception that is not already listed. Many times, breaking when the exception is thrown allows you to inspect the stack trace to determine which one of your functions is to blame -- and in the vast majority of cases, it will be your code that is at fault!
Labels: Autodesk University, ObjectARX, programming, Visual Studio
2007-12-03
The Hot List
- Carl Bass munching on fast food in the food court, and spotted throughout the week yakking with average folks in the halls.
- Staggered classes reduced the lunchtime crush experienced at AU 2006.
- More ObjectARX programming classes this year. I'm pushing for creating a new "Developer" track for AU 2008.
- The Matt Murphy Head (peace be upon him).
- Meeting a lot of familiar faces and a few new ones!
The Cold List
- The food was worse this year than even AU '97 in Los Angeles. At least AU '97 had a Burger King nearby for someone on a budget; here in Las Vegas I ended up spending several hundred dollars over the course of the week just for food.
- Pete Kelsey's band, Dr. Ruth, didn't play. Rumor has it that the AU organizers refused to give them space. Dr. Ruth has become an AU staple, and it just wasn't the same without them.
- Shaan Hurley's gut-wrenching regimen for clearing 20 year old meat byproducts from various body cavities.
I presented the first of two ObjectARX roundtable discussions this year (the second one, hosted by Stephen Preston, also covered .NET). This was an experimental format. I liked it, and I thought it went well. If you were there, I'd like to hear your suggestions for making it better next year. I will be following up with some more posts covering topics raised in this and other AU classes.
Labels: AU 2007, ObjectARX, programming
2007-11-26
The new Visual Studio 2008 has been released, and to celebrate, I've updated VC Build Hook. The updated utility allows you to use the new IDE while still building with older versions of the build tools.
Why is this necessary? If you build your AutoCAD 2007/2008 ObjectARX application with the Visual C/C++ 9.0 tools, AutoCAD will display a warning message about an incompatible module when you try to load it. You can use VC Build Hook to target all previous AutoCAD versions from a single Visual Studio 2008 solution (if you have the correct version of Visual C/C++ installed alongside Visual Studio 2008).
In my testing so far, existing Visual Studio 2005 projects build without problems in Visual Studio 2008 when VC Build Hook is installed and the new 'BuildToolVersion' property is set to the correct version.
Why is this necessary? If you build your AutoCAD 2007/2008 ObjectARX application with the Visual C/C++ 9.0 tools, AutoCAD will display a warning message about an incompatible module when you try to load it. You can use VC Build Hook to target all previous AutoCAD versions from a single Visual Studio 2008 solution (if you have the correct version of Visual C/C++ installed alongside Visual Studio 2008).
In my testing so far, existing Visual Studio 2005 projects build without problems in Visual Studio 2008 when VC Build Hook is installed and the new 'BuildToolVersion' property is set to the correct version.
Labels: Microsoft, ObjectARX, programming, Visual Studio
2007-08-01
OpenDCL 4.0 has finally been released. If you're not familiar with OpenDCL, check it out at www.opendcl.com, or on SourceForge at sourceforge.net/projects/opendcl.
OpenDCL, based on the original commercial ObjectDCL software by Chad Wanless, is a modern replacement for the old DCL dialog control language in AutoCAD. The current OpenDCL Runtime supports AutoCAD 2002 through 2008 (except AutoCAD 2008 x64). It is designed to give AutoCAD end users and AutoLISP application developers a simple yet powerful way to design and use rich user interfaces in their applications.
The goal for version 4.0 was to get it stable and fix all the bugs, with minimal new feature development. OpenDCL 4.1 will add support for AutoCAD 2008 x64. After that we will start working on localized language versions, and adding new features.
OpenDCL is licensed under the GNU General Public License (GNU GPL) open source license, completely free to use, and source code is available on SourceForge.
OpenDCL, based on the original commercial ObjectDCL software by Chad Wanless, is a modern replacement for the old DCL dialog control language in AutoCAD. The current OpenDCL Runtime supports AutoCAD 2002 through 2008 (except AutoCAD 2008 x64). It is designed to give AutoCAD end users and AutoLISP application developers a simple yet powerful way to design and use rich user interfaces in their applications.
The goal for version 4.0 was to get it stable and fix all the bugs, with minimal new feature development. OpenDCL 4.1 will add support for AutoCAD 2008 x64. After that we will start working on localized language versions, and adding new features.
OpenDCL is licensed under the GNU General Public License (GNU GPL) open source license, completely free to use, and source code is available on SourceForge.
Labels: AutoCAD, ObjectARX, ObjectDCL, OpenDCL, programming
2007-06-15
I've received several emails recently from users of my VC Build Hook utility that mention switching the 'UseVC7Paths' setting on and off depending on the build configuration they are working on. If you are doing this, you need to change your project structure!
Build configurations in Visual Studio 6 and later are logically attached to the solution, not to an individual project as they were in older Visual Studio versions. What happens is that programmers find it easy to add a new build configuration to an existing ObjectARX wizard created project for targeting a new release of AutoCAD -- unfortunately those configurations end up belonging to the entire solution instead of just one project. Since VC Build Hook cannot be set on a per-configuration basis, they end up having to change the project setting depending on which configuration they are building. That's bad, very bad!
The correct way to handle this situation is to create new projects, not new build configurations. Yes, it's a bit more work, and it would be nice if Microsoft added an easy way to clone a project, but them's the breaks. Targeting different AutoCAD releases requires project-level changes, so you must create a new project instead of trying to get by with a new build configuration. You can and should share source code files between the projects, however.
When I create a new multi-target solution that e.g. targets AutoCAD 2000 - AutoCAD 2008, I structure the project files on my hard drive like this:
Solution (.sln file)
\ARXProject (ARX module source files)
+ARXProject.15 (.vcproj file)
+ARXProject.16 (.vcproj file)
+ARXProject.17 (.vcproj file)
\DBXProject (DBX module source files)
+DBXProject.15 (.vcproj file)
+DBXProject.16 (.vcproj file)
+DBXProject.17 (.vcproj file)
When starting a new project, I first use the wizard to create a default project structure and source code files for the current AutoCAD release. Once I've got that set up the way I want (including moving the project file into a subdirectory and modifying the source file paths appropriately, as well as setting the _ACADTARGET preprocessor macro), I clone projects by copying the .vcproj files and editing the copies in a text editor to give them a new GUID, then recreate my solution's project structure from scratch by dragging and dropping the project files back into the solution and editing them as necessary.
If you need to target multiple AutoCAD releases from a single project, invest the time to set your solution up this way (and follow the other advice on my ARX tips page!), otherwise you will find yourself constantly fighting the system.
Build configurations in Visual Studio 6 and later are logically attached to the solution, not to an individual project as they were in older Visual Studio versions. What happens is that programmers find it easy to add a new build configuration to an existing ObjectARX wizard created project for targeting a new release of AutoCAD -- unfortunately those configurations end up belonging to the entire solution instead of just one project. Since VC Build Hook cannot be set on a per-configuration basis, they end up having to change the project setting depending on which configuration they are building. That's bad, very bad!
The correct way to handle this situation is to create new projects, not new build configurations. Yes, it's a bit more work, and it would be nice if Microsoft added an easy way to clone a project, but them's the breaks. Targeting different AutoCAD releases requires project-level changes, so you must create a new project instead of trying to get by with a new build configuration. You can and should share source code files between the projects, however.
When I create a new multi-target solution that e.g. targets AutoCAD 2000 - AutoCAD 2008, I structure the project files on my hard drive like this:
Solution (.sln file)
\ARXProject (ARX module source files)
+ARXProject.15 (.vcproj file)
+ARXProject.16 (.vcproj file)
+ARXProject.17 (.vcproj file)
\DBXProject (DBX module source files)
+DBXProject.15 (.vcproj file)
+DBXProject.16 (.vcproj file)
+DBXProject.17 (.vcproj file)
When starting a new project, I first use the wizard to create a default project structure and source code files for the current AutoCAD release. Once I've got that set up the way I want (including moving the project file into a subdirectory and modifying the source file paths appropriately, as well as setting the _ACADTARGET preprocessor macro), I clone projects by copying the .vcproj files and editing the copies in a text editor to give them a new GUID, then recreate my solution's project structure from scratch by dragging and dropping the project files back into the solution and editing them as necessary.
If you need to target multiple AutoCAD releases from a single project, invest the time to set your solution up this way (and follow the other advice on my ARX tips page!), otherwise you will find yourself constantly fighting the system.
Labels: ObjectARX, programming, Visual Studio
If you use of any of these ManuSoft products, preliminary AutoCAD 2008 support has been available for several weeks at the Download Center for registered users. The QuikPik and Periscope updates are now officially released, and the shareware versions of QuikPik and Periscope are now available as well. SuperPurge will be officially released in the next week or so.
My free AcadStatusBarButton library has also been updated for AutoCAD 2008, and is now available for download on the Freebies page. The only change is the addition of a blank status bar pane beneath your floating buttons so that the new annotation scale buttons in AutoCAD 2008 don't get covered up (the blank panes force the annotation scale buttons to the left of your custom buttons). If your button position is fixed (i.e. not floating), the blank pane will not be used.
As always, if you encounter any problems, please let me know!
My free AcadStatusBarButton library has also been updated for AutoCAD 2008, and is now available for download on the Freebies page. The only change is the addition of a blank status bar pane beneath your floating buttons so that the new annotation scale buttons in AutoCAD 2008 don't get covered up (the blank panes force the annotation scale buttons to the left of your custom buttons). If your button position is fixed (i.e. not floating), the blank pane will not be used.
As always, if you encounter any problems, please let me know!
Labels: ManuSoft, Periscope, programming, QuikPik, SuperPurge
2007-01-31
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 beeen 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!
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!
Labels: AutoCAD, ObjectARX, ObjectDCL, OpenDCL, programming, Visual Studio
2007-01-11
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):
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.
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.
Labels: ATL, manifest, Microsoft, ObjectARX, programming, Visual Studio
2007-01-08
I'm one of those throwbacks that learned HTML by typing it in Notepad. I've since moved up to using the Visual Studio editor; it does syntax coloring, error highlighting, and has a "design" mode for previewing the page, yet it's a very utilitarian editor that I feel comfortable with. I do use FrontPage when I need to manage connections between multiple HTML pages, but mostly in raw HTML mode. When I use WYSIWYG design mode in FrontPage, I inevitably end up cleaning out a lot of unnecessary junk that it includes in the generated HTML. I think it's fair to say that my obsession with clean HTML results in utilitarian, functional, and standards conformant presentations -- but with a decided lack of graphic appeal.
The ManuSoft and CADLock web sites are examples of this utilitarian approach. The ManuSoft site uses no fancy graphics and relies very little on client side scripting, and it supports a hierarchical navigation system using only standard hyperlinks. I like that minimalist approach, but the price for clean HTML being served to clients is a lot of work on the server to maintain the site. As a result, I don't update the site very often because it's just too difficult.
This blog was the first step toward realizing a goal of making it easier to add new content. After all, the raison d'être of blogs is to minimize the latency between the writer's stream of consciousness and words on the web by making it irresistibly easy to add new content. This is precisely why blogs have become so popular.
Unfortunately, I soon found limitations with my blog. Tabular lists of data still require manual HTML input, it is difficult to customize the content area outside the individual posts on the blog page, and most aspects of the hosted blog software are outside my control. I wanted more.
The Autodesk vs. Open Design Alliance lawsuit gave me an excuse to take the next step: implement the "blog" concept across an entire web site with software that I control. So, I decided to swallow my pride and learn how to create an entire web site that would be so easy to update that I would actually update it frequently -- even if it meant messy HTML code. Stay tuned for Part II, choosing a hosting service and deciding which software to use.
The ManuSoft and CADLock web sites are examples of this utilitarian approach. The ManuSoft site uses no fancy graphics and relies very little on client side scripting, and it supports a hierarchical navigation system using only standard hyperlinks. I like that minimalist approach, but the price for clean HTML being served to clients is a lot of work on the server to maintain the site. As a result, I don't update the site very often because it's just too difficult.
This blog was the first step toward realizing a goal of making it easier to add new content. After all, the raison d'être of blogs is to minimize the latency between the writer's stream of consciousness and words on the web by making it irresistibly easy to add new content. This is precisely why blogs have become so popular.
Unfortunately, I soon found limitations with my blog. Tabular lists of data still require manual HTML input, it is difficult to customize the content area outside the individual posts on the blog page, and most aspects of the hosted blog software are outside my control. I wanted more.
The Autodesk vs. Open Design Alliance lawsuit gave me an excuse to take the next step: implement the "blog" concept across an entire web site with software that I control. So, I decided to swallow my pride and learn how to create an entire web site that would be so easy to update that I would actually update it frequently -- even if it meant messy HTML code. Stay tuned for Part II, choosing a hosting service and deciding which software to use.
Labels: Autodesk, CMS, ODA, programming, Visual Studio
2006-12-19
I've installed Visual Studio 2005 SP1 and have been busy testing all my projects to make sure they didn't break. Microsoft did fix at least one of the bugs I reported (the resource editor choked on resource strings that contained an embedded NULL character), but the IDE still crashes fairly consistently if I initiate a large solution build while the Intellisense database is being rebuilt. SP1 also managed to break my VCBuildHook utility, so I've uploaded an updated version (2.0.3.0) for use with SP1.
Labels: Microsoft, ObjectARX, programming, Visual Studio
2006-12-18
Finally, the long awaited service pack 1 for Visual Studio 2005 is released! The service pack has been in the pipeline since soon after Visual Studio 2005 shipped last November, with release dates slipping month after month. The latest official release date was announced as "early 2007". Perhaps this was an intentional attempt to alleviate some of the waiting pains with a suprise release (or maybe just the Microsoft rumor mill on autopilot).
Be prepared for a long install. The download page warns that it could take an hour or more to verify digital signatures before the service pack installation even begins.
Be prepared for a long install. The download page warns that it could take an hour or more to verify digital signatures before the service pack installation even begins.
Labels: Microsoft, ObjectARX, programming, Visual Studio
2006-12-08
If you've been programming with ObjectARX for a while, you already know that each version of the ObjectARX SDK only works with a specific version of Visual Studio. Mazhar Basa touches on the subject in his article Components of ObjectARX Applications. My VCBuildHook utility makes it possible to build for multiple target AutoCAD versions from a single Visual Studio 2005 solution, but this utility still needs the older versions of Visual Studio to be installed on the same system in order to perform its magic.
The problem is, legitimate licenses of older versions of Visual Studio are hard to come by. Back in the Visual Studio .NET 2003 days, you could purchase a new license of VS 2003, then get a free license downgrade from Microsoft that allowed you to install Visual Studio 2002 side by side on the same system. That combination allowed you to target AutoCAD versions as far back as AutoCAD 2004. Unfortunately, Microsoft stopped offering the VS 2002 downgrade license when Visual Studio 2005 began shipping in November of 2006.
The end result is that new ObjectARX programmers are faced with a dilemma if they need to target anything older than AutoCAD 2007. One of the attendees at my "High-Octane ObjectARX" class at AU 2006 reminded me that MSDN (Microsoft Developer Network) members can download older versions of Visual Studio from the MSDN subscriber download center.
I have verified that Visual Studio .NET 2002 (VS 2002) is available for download to MSDN Professional subscribers, but I could not find Visual Studio 6.0, which is required to target AutoCAD 2000 - 2002. Visual Studio 4.2 (required for AutoCAD R14) is available though, so maybe I'm just not looking in the right place.
If you are a professional software developer, whether commercial or in-house, you should consider subscribing to MSDN for various reasons. If you're an ObjectARX programmer and need to target older versions of AutoCAD, MSDN may be the only way to obtain the older Visual Studio build tools and libraries that you'll need.
The problem is, legitimate licenses of older versions of Visual Studio are hard to come by. Back in the Visual Studio .NET 2003 days, you could purchase a new license of VS 2003, then get a free license downgrade from Microsoft that allowed you to install Visual Studio 2002 side by side on the same system. That combination allowed you to target AutoCAD versions as far back as AutoCAD 2004. Unfortunately, Microsoft stopped offering the VS 2002 downgrade license when Visual Studio 2005 began shipping in November of 2006.
The end result is that new ObjectARX programmers are faced with a dilemma if they need to target anything older than AutoCAD 2007. One of the attendees at my "High-Octane ObjectARX" class at AU 2006 reminded me that MSDN (Microsoft Developer Network) members can download older versions of Visual Studio from the MSDN subscriber download center.
I have verified that Visual Studio .NET 2002 (VS 2002) is available for download to MSDN Professional subscribers, but I could not find Visual Studio 6.0, which is required to target AutoCAD 2000 - 2002. Visual Studio 4.2 (required for AutoCAD R14) is available though, so maybe I'm just not looking in the right place.
If you are a professional software developer, whether commercial or in-house, you should consider subscribing to MSDN for various reasons. If you're an ObjectARX programmer and need to target older versions of AutoCAD, MSDN may be the only way to obtain the older Visual Studio build tools and libraries that you'll need.
Labels: ObjectARX, programming, Visual Studio
2006-12-04
Some years ago I wrote a small ObjectARX module named VLXLoad that loads a .vlx file of the same name and in the same directory as the .arx module. I never claimed credit for the utility, but now that I've released the source code, I guess I'll have to own up to it.
If you're interested in seeing an example of "dynamically" defining an ADS (lisp callable) function when an ObjectARX module loads, take a look at the VLXLoad source code. The code also demonstrates how to call the GetModuleFileName() WinAPI function to get the path of the executing module, and how to declare and use the undocumented ads_queueexpr() function.
There is no documentation (and probably no comments), so be warned. The download contains ready to build projects for Visual Studio 2002 (targeting AutoCAD 2004-2006) and Visual Studio 2005 (targeting AutoCAD 2007). These projects were both created with the corresponding ObjectARX wizard, and are included in the course materials for my "High-Octane ObjectARX" class at AU 2006 as an example of a simple (yet very useful) ObjectARX application.
If you just want to use VLXLoad, I've also made the original pre-built binaries available on my Freebies page. The idea is to rename the correct .arx file so it matches the name of your .vlx, then set up registry demand loading so that the .arx loads when AutoCAD starts. The .arx then loads the associated .vlx file, and voila, demand loading for .vlx files. Instructions for setting up demand loading have been posted on the 'net in the past (and it is well documented in the ObjectARX SDK), so I won't describe that here.
If you're interested in seeing an example of "dynamically" defining an ADS (lisp callable) function when an ObjectARX module loads, take a look at the VLXLoad source code. The code also demonstrates how to call the GetModuleFileName() WinAPI function to get the path of the executing module, and how to declare and use the undocumented ads_queueexpr() function.
There is no documentation (and probably no comments), so be warned. The download contains ready to build projects for Visual Studio 2002 (targeting AutoCAD 2004-2006) and Visual Studio 2005 (targeting AutoCAD 2007). These projects were both created with the corresponding ObjectARX wizard, and are included in the course materials for my "High-Octane ObjectARX" class at AU 2006 as an example of a simple (yet very useful) ObjectARX application.
If you just want to use VLXLoad, I've also made the original pre-built binaries available on my Freebies page. The idea is to rename the correct .arx file so it matches the name of your .vlx, then set up registry demand loading so that the .arx loads when AutoCAD starts. The .arx then loads the associated .vlx file, and voila, demand loading for .vlx files. Instructions for setting up demand loading have been posted on the 'net in the past (and it is well documented in the ObjectARX SDK), so I won't describe that here.
Labels: ObjectARX, programming
This year I taught an ObjectARX class at AU. As usual, there wasn't nearly enough time to cover all the things I wanted to cover. I'm still contemplating what I want to do differently next year in order to be able to spend more time on the subject without boring everybody to death.
By the way, fellow programmers, do you agree that we need a Programming campus at AU 2007? I hate being lumped into a generic category like General Design. I suggest a new campus just for programmers, with our own industry reception (I'm thinking pizza, beer, and a Pink Floyd tribute band -- and Lynn Allen of course).
If any of you went to the Programming Gurus Go Head To Head panel discussion on Thursday afternoon and were wondering why I wasn't present... well, er, next time, could you please call me on my mobile phone a few minutes before the class to jog my aging memory? Sheesh. I always enjoy the quasi-chaotic gurus panel, and I can't believe it completely slipped my mind.
Speaking of chaos, I like chaos -- but more on that subject later. I like unscripted discussions where the topics are limited only by the imaginations of the participants. I usually sit in on a few classes at AU, but with a few rare exceptions, the only time I learn something new at AU is outside the structured classrooms.
This year I did learn something new in a class, though. I sat in on Josh Johnson's Demystifying Installers class, and I learned how to create a new registry key that AutoCAD's secondary install uses to trigger a third party secondary installer (this would occur when a new user logs in for the first time). Thanks, Josh! I did not know that! [An interesting sidenote: Josh taught the class with his father in the audience. How cool is that? Er, not cool at all, especially in Vegas! Seriously, I thought it was cool, and it was a pleasure to meet both of the Johnsons. Good thing I brought... never mind.]
By the way, fellow programmers, do you agree that we need a Programming campus at AU 2007? I hate being lumped into a generic category like General Design. I suggest a new campus just for programmers, with our own industry reception (I'm thinking pizza, beer, and a Pink Floyd tribute band -- and Lynn Allen of course).
If any of you went to the Programming Gurus Go Head To Head panel discussion on Thursday afternoon and were wondering why I wasn't present... well, er, next time, could you please call me on my mobile phone a few minutes before the class to jog my aging memory? Sheesh. I always enjoy the quasi-chaotic gurus panel, and I can't believe it completely slipped my mind.
Speaking of chaos, I like chaos -- but more on that subject later. I like unscripted discussions where the topics are limited only by the imaginations of the participants. I usually sit in on a few classes at AU, but with a few rare exceptions, the only time I learn something new at AU is outside the structured classrooms.
This year I did learn something new in a class, though. I sat in on Josh Johnson's Demystifying Installers class, and I learned how to create a new registry key that AutoCAD's secondary install uses to trigger a third party secondary installer (this would occur when a new user logs in for the first time). Thanks, Josh! I did not know that! [An interesting sidenote: Josh taught the class with his father in the audience. How cool is that? Er, not cool at all, especially in Vegas! Seriously, I thought it was cool, and it was a pleasure to meet both of the Johnsons. Good thing I brought... never mind.]
Labels: AU 2006, AutoCAD, programming
About Me
- Name: Owen Wengerd
- Location: Apple Creek, Ohio, United States
I'm a starving artist specializing in the programming genre. I work in my home office, where I am the owner and sole proprietor of ManuSoft as well as the President and chief software artist of CADLock, Inc.
Syndication
Archive
December 2006January 2007
March 2007
April 2007
May 2007
June 2007
August 2007
September 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
December 2008
January 2009
February 2009
March 2009
July 2009
August 2009
September 2009
November 2009
December 2009
January 2010
March 2010
Recent Comments
Steve Johnson:I have a home-grown app that relies on a free 4th party 32-bit DLL that is extremely unlikely to ever be updated, regardless of any pressure I may attempt to apply. Does this count as a valid excuse? :)
@ March 12, 2010 1:10:00 AM EST
:I'm running 64-bit AutoCAD 2010 on XP SP3 64-bit and the VBA Enabler loads and runs just fine. Never had a problem installing it or with it running. Also, Autodesk didn't pull VBA out of the base installation setup until 2010. AutoCAD 2009 still installs it. Am I missing something?
@ March 12, 2010 6:58:00 AM EST
:Owen, I have discussed this issue with you in the past, Eagle Point has refused to port their product to 64 bit, and now that they are closing the doors on their civil software for vanilla cad, I dont expect them to. Our office was forced to install 32 bit Windows, just because of this one program. I wish they would have taken you up on your offer to port their software, but for now, I just have to wait until Eagle Point goes away, then our office will switch to some other software that supports 64 bit.
@ March 12, 2010 8:17:00 AM EST
:Very nice Christmas present Owen .. Thanks !!!
Regards
Kerry Brown
@ December 24, 2009 7:31:00 PM EST
Melanie (Stone) Perry:Amen!
@ January 28, 2009 12:39:00 PM EST
R.K. McSwain:Amen #2
@ January 28, 2009 1:28:00 PM EST
Jimmy Bergmark - JTB World:Autodesk, say yes if possible. But don't they use Jive?
http://www.jivesoftware.com/jivespace/message/138762#138762
@ January 28, 2009 2:48:00 PM EST
Owen Wengerd:Jimmy, they do use Jive. I would assume Autodesk has (or could) negotiate a license to modify Jive's software as needed. Or, scrap it altogether.
@ January 28, 2009 3:05:00 PM EST
Matthew Anderson:Hallelujah!
Amen!
@ January 29, 2009 9:58:00 AM EST
:You're a good man Charlie Brown... I mean Owen... bless you for being good hearted. Let's just hope AutoDesk is listening.
@ January 29, 2009 10:00:00 AM EST
Christopher Fugitt:Amen
@ January 29, 2009 10:41:00 AM EST
:Amen! Well kinda…
It’s been busy over at TheSwamp.Org lately, which is good..
Thanks for all you do Owen
Daniel
@ January 29, 2009 6:24:00 PM EST
:amen !
and Bravo ! Owen
Kerry Brown
@ January 29, 2009 6:41:00 PM EST
Barry:Owen you da man. :)
@ January 29, 2009 7:53:00 PM EST
:Hear! Hear! (or Here! Here!).
... and Amen, too.
@ February 1, 2009 12:22:00 AM EST
Steve Johnson:Can we assume you haven't been taken up on the offer yet? ;)
@ February 24, 2009 12:51:00 AM EST
Owen Wengerd:Yes, Steve, that would be a correct assumption. :/
@ February 24, 2009 2:12:00 AM EST
Steve Johnson:I have something to say about the "it's not working" link to the discussion in the Autodesk Discussion Groups. It's not working!
"Error: you do not have permission to view the requested forum or category."
Strange, it used to work. Moved out of sight, perhaps? If so, that's really not a good idea. Suppressing a discussion in the discussion groups about improving the discussion groups only supports the conspiracy theory that Autodesk actually wants to keep them working badly.
@ February 25, 2009 1:30:00 AM EST
Owen Wengerd:Good catch, Steve. I've verified that the entire thread has been removed from the server. Luckily I still have it archived.
@ February 25, 2009 11:37:00 PM EST
Steve Johnson:Yup. This is just one symptom of just one aspect of the CUI system's faulty design. It causes me grief on a regular basis as a user, a developer and a CAD manager. Hardwiring partial menus? Who could possibly have thought that was a good idea?
@ December 30, 2008 7:23:00 AM EST
:Amen to that I have pulled 3rd party software from previous firms that work quite well until CUI (how dare i capitalize that.
@ October 6, 2009 3:23:00 PM EDT
Deelp Menezes:At SYCODE, we actually have a document that we regularly hand to users who have uninstalled our plug-in but don't know how to remove the menu that it added.
@ October 7, 2009 5:30:00 AM EDT
Owen Wengerd:Now with the advent of the ribbon, I'm thinking about getting some condoms. Then I'll just give them a condom and tell 'em they're screwed. <:-)
@ October 7, 2009 9:52:00 AM EDT
:Awesome, Thanks for the Tip
@ May 15, 2008 12:11:00 PM EDT
:Very nice Owen, Thank you for this wonderful utility.
Question, do you think this will work for building mix managed/unmanaged and or
C++/CLI apps? Thanks
Daniel
@ December 4, 2007 7:15:00 AM EST
Owen Wengerd:Thanks for the feedback, Daniel. VC Build Hook should work for mixed apps, but I haven't tried that yet. If you try it, please let me know whether you encounter any problems.
@ December 4, 2007 3:31:00 PM EST
:Thanks Owen for your tool.
I downloaded the tool in an attempt to use VS2008 as IDE to develop a C++/CLI application which uses ObjectARX 2008 SDK.
It compiles well with an initial problem of incorrect library settings. After a small fix, build went well. But unfortunately the netload command inside AutoCAD exists with a "System.IO.FileNotFoundException:The specified module could not be found" exception.
I feel that this should not be related any way with the hook nor with the code.
Daniel and Owen, I request you to keep me updated in case if you come across any solution of clue that might solve my problem.
Thanks and till then, I'll use VS2008 for AutoCAD .Net API only :-(
regards,
Narayanan
SendtoNarayanan(at)Gmail[dot]com
@ March 11, 2008 5:26:00 AM EDT
:I can't get the download to work:
File Not found
File: index.html not found.
To go back to the project page for opendcl click here
Click here for documentation about the download process on sf.net.
@ February 1, 2007 7:44:00 AM EST
Owen Wengerd:SourceForge is a bit confusing. After you click on <Download OpenDCL for AutoCAD>, make sure you click on <Browse> to show the download categories. Select the "OpenDCL Full Install" category, then it should finally display a list of files to download. Right now there is only one (ObjectDCL.msi) in this category.
@ February 1, 2007 10:38:00 AM EST
:I have installed the aplication using OpenDCL.4.0.0.12.msi and it works with AutoCAD 2006. However when I tried to run the tree control included in _MasterDemo.LSP I have got this message:
Comando: tree
; error: error en solicitud ADS
Do you have any idea about the problem.
@ February 15, 2007 5:12:00 AM EST
:Be sure you are not loading previous versions of ObjectDCL. The ObjectDCL2004.arx supplied by 3rd Day Software seems to be different from that included on OpenDCL.
I have found some problems with the OpenDCL Dialog Workshop:
1. The Picture folder looses its contents when you save a project to update it. Only the picture named 100 remains.
2. The original release from 3rd Day Software allows you to include each time more than a hundred pictures at the Image list of a Tree control. The OpenDCL is unable to add more than 25 pictures each time.
3. It seems that Dockable Form with AllowResizing property set True doesn’t work properly and resizing is not possible.
Congratulations Owen! You have made a very good work and I am very grateful for it.
Thank you.
@ February 15, 2007 6:31:00 PM EST
:Excellent website. Good work. Very useful. I will bookmark!
@ September 9, 2007 4:13:00 PM EDT