Outside The Box
Random thoughts about AutoCAD, ObjectARX, and the meaning of life.
All Original Content Copyright 2006 - 2008 Owen Wengerd, All Rights Reserved
2008-05-12
Debugging ObjectARX: Break on Exception
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
AU 2007 Post Mortem
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
VC Build Hook utility for Visual Studio 2008
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 Debuts
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
Visual Studio Build Configuration Tip
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
2007-01-31
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 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
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):
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
2006-12-19
VCBuildHook updated for VS 2005 SP1
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
Visual Studio 2005 Service Pack 1 is here!
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
Visual Studio Version Hunt
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
Demand Loading a VLX File
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
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
Recent Comments
: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