To make it less confusing when working with multiple versions of ObjectARX, I recommend removing the ObjectARX SDK folders from your global VC settings, and adding them instead to the project settings for each individual project. Doing so gives you more local control over the project, and makes it less confusing when you need different build configurations to use different versions of ObjectARX in the same project. ...
[Update: Visual Studio 2010 now includes a built in feature called native multi-targeting that replaces the need for VC Build Hook. Read this blog post to learn how to use VS 2010 to target older versions of Visual Studio.] I created the VC Build Hook utility in order to make it possible to use the current Visual Studio IDE for building ObjectARX applications that target any version of AutoCAD. This is desirable because ObjectARX applications must be built by the Visual C/C++ build tools that correspond to the ObjectARX SDK version for the target AutoCAD version. VC Build Hook works by switching the executables path during a Visual Studio build and pointing the paths to the desired version of the Visual C/C++ build tools. In addition, VC Build Hook automatically fixes build tool command options to account for differences between VC versions so that build commands produced by one version of Visual Studio are correctly interpreted by another version of the build tools. Assuming you've already set up your projects as described here (note that you must have a working installation of the necessary version of Visual C/C++ build tools and runtime libraries), then you'll need to install the current version of VC Build Hook: ...
The registry demand loading feature in AutoCAD, BricsCAD, and ZWCAD is a great method for loading ObjectARX/BRX/ZRX modules automatically at startup, and it's relatively easy to create the demand loading settings from an installation program or MSI file at install time. Unfortunately it only works for ARX/BRX/ZRX files (and also with .NET dlls in AutoCAD 2006 and later). Some years ago, I created a small ARX module called VLXLoad. The purpose of this module was to work as a stub to load an associated .vlx file of the same base name in the same folder. I've since renamed this small utility to LspLoad and expanded it so that it can load any type of LISP file. The idea is to rename the LspLoad.*.* file to the name of the associated .lsp/.vlx/.fas file (i.e. MyApp.18.arx will look for and load MyApp.vlx in the same directory), then create demand load registry settings to load the renamed LspLoad module. Voila, the associated LISP file gets loaded as if it was being demand loaded from the registry. ...
With the advent of AutoCAD 2004 and Visual Studio .NET (aka Visual Studio 2002), ObjectARX programmers are again faced with the task of moving from an older version of a compiler (VC6) to a newer version (VC7). Rather than maintain two versions of compilers and two versions of projects for supporting both AutoCAD 2000/2002 and the new AutoCAD 2004, it makes sense to use only the newest IDE to support *all* target AutoCAD platforms. ...
A common complaint among ObjectARX programmers is that Visual C/C++ doesn't display IntelliSense context menus for classes defined in the ObjectARX headers. The trick is to include all the ObjectARX headers files somewhere in your solution. I created a new folder called ARXHeaders with subdirectories for every version of the ObjectARX SDK. ...
Despite the minor numerical change from Visual C/C++ version 7 to 7.1, Microsoft made some major changes in the compiler and linker in order to become more C++ standard compliant. These changes make it virtually impossible to use 7.1 to build for ObjectARX 2004 and earlier ObjectARX versions. The new compiler chokes on the earlier versions of ATL and MFC libraries because they were not standard compliant, yet these are required when building for ObjectARX because of its reliance upon Autodesk libraries. What's more, the tricks outlined here are not enough to solve this problem. ...
My blogging has taken a nosedive in recent years, but I’m happy to report that I am doing great. I’ve been 100% focused on making sure there’s a viable alternative DWG platform for all you lost, lonely, and depressed CAD users out there. I’m going to keep this short and sweet, because as I write this I am still 100% focused on the task: putting finishing touches on BricsCAD V19 to be released “soon”. ...
Are you looking for a way to turn off the annoying InfoCenter that slows down (or sometimes locks up) your AutoCAD? Of course you are! Hop on over to the ManuSoft Freebies page and install AcadInfoCenterOff.msi, the most popular ManuSoft download of all time. ...
I have updated the automatic lisp loader modules (LspLoad.zip on my freebies page) to support BricsCAD V17 and ZWCAD 2017. Note that the source code for LspLoad is also available.
The ManuSoft web server has been humming along steadily for the last 7 years on an old Compaq server running Windows 2008. You may have noticed that it’s currently offline. Actually the server is still humming along just fine – it’s just that nobody can connect to it. ...
I’ve updated QuirkyPolyline and added support for Bricscad 14 – 15 and ZWCAD+ 2014 – 2015. The new QuirkyPolyline download is available on the ObjectARX freebies page. Share ThisTweetFacebookLinkedInTumblrStumbleDiggDelicious
New Visual Studio C/C++ users sometimes get tripped up by IntelliSense errors, so today I’ve decided to share the secret, undocumented solution: just turn them off! IntelliSense is a nice user interface feature when it works, but it has nothing whatever to do with building and running your C/C++ code. IntelliSense errors do not equal compiler errors, and trying to “fix” them is fruitless. ...