Category Archives: ZWCAD

Why every AutoCAD CAD Manager should have a copy of BricsCAD – part 1, fixing drawings

Here’s a mega-tip with a lot of experience behind it:

As a CAD Manager looking after AutoCAD users, or a power user looking after yourself, it’s worth your while to have a copy of BricsCAD handy.

Why? There are too many reasons to fit in one blog post, so I’m going to do a mini-series. The first post is about using BricsCAD to fix up drawings that are giving your AutoCAD users problems.

One of the things that surprised me most when evaluating BricsCAD as a potential replacement for AutoCAD was that my expectations were wrong when it came to the reliability of opening DWGs. Over the years, I collected a variety of DWGs that gave various releases of AutoCAD some problems. Some of those problems occurred while performing some kind of editing or processing, while others prevented AutoCAD from opening the drawing at all. I was expecting BricsCAD to have all those problems, plus perhaps some additional incompatibilities of its own.

What happened was the opposite. I don’t think I came across a single drawing that AutoCAD could open but BricsCAD couldn’t. On the contrary, BricsCAD was much more forgiving than AutoCAD, breezing through the process of opening drawings that had problems that originated in AutoCAD. Maybe 80-90% of my “problem” drawings were problems for AutoCAD alone. In many cases an AUDIT in BricsCAD and a re-save was enough to make the problem go away in AutoCAD. In other cases I could use BricsCAD to recover the unrecoverable using the traditional methods of WBLOCK, saving as an earlier release, saving as DXF, binary search (I may do a later post on exactly what that means), and so on.

Note that you may be able to obtain similar results using other DWG-based products such as DraftSight, ZWCAD or even the free BricsCAD Shape. However, I don’t have the experience with those products to be able to confirm that. Autodesk’s DWG TrueView, being a cut-down AutoCAD, tends to have the same problems as AutoCAD.

One thing that was particularly pleasant about using BricsCAD to fix problem drawings was the speed at which it could be done, because of BricsCAD’s generally superior performance. Closing and opening AutoCAD is painfully slow these days as the bloat gets worse, so having a product that fires up quickly is very handy.

Also handy is the availability of tools within the product that make it easier to locate and fix problems. Of particular importance is the Drawing Explorer, which provides a consistent and efficient interface that provides access to over 20 different types of aspects of a drawing (e.g. layers, linetypes, text styles, etc.):

One example arose showing how useful this is, when my users were having an intermittent problem with some drawings locking up AutoCAD 2015 on open. Some trial and error made it possible to discover that the trigger for this was the existence of a text style (any text style) with a bigfont attached, where the bigfont SHX file did not exist. It was possible to fix this in an earlier or later AutoCAD release, which the users may or may not have available to them, by opening the drawing, using the STYLE command, then using that dialog box to go through each text style one at a time, looking for bigfonts.

It was much easier to quickly fire up BricsCAD, use the STYLE command which opens the Drawing Explorer in the Text Style section, and see all of the text styles laid out at once (see above). It was very efficient to quickly look for recalcitrant bigfonts and make them go away, or to see instantly that bigfonts weren’t the problem.

Similarly, the consistent, searchable and efficient interface of the BricsCAD Settings dialog makes it easy to check the values of any settings that you suspect may be triggering the problem in AutoCAD:

As a CAD Manager, it’s definitely worth your while to do the quick download and install of an evaluation BricsCAD. My experience in dealing with Bricsys is that requests for extensions for evaluation purposes are usually accepted, so you probably won’t have to give up your valuable tool as soon as your 30 days are up.

Once you’ve determined that it really is an invaluable tool to have around, the cost of entry is low enough to make it relatively easy to justify the investment. You won’t need to recover many drawings to get your money back.

Why digitally sign your LISP files?

4 Replies

After I mentioned in an earlier post that I had digitally signed the sample LISP file I had provided, this generated some interest. In this post, I’ll explain why you might want to sign your LISP files. In a later post, I’ll explain how to do it.

These days it is standard practice for developers to digitally sign their code. Operating systems and applications are displaying increasingly scary warnings when coming across unsigned code. Here is an example of the sort of message you get when you load an unsigned LISP file into AutoCAD from a location that has not been explicitly configured as a trusted location:

If you’re a CAD Manager dealing with your own internal code, it’s not too onerous to configure AutoCAD in Options > Files such that a folder is trusted by AutoCAD and place your code in there. The folder should be read-only; if it isn’t, AutoCAD warns you when you try to configure it. If you do this, the scary warnings don’t appear to bother and confuse your users, even if your code is unsigned.

Another way a CAD Manager can avoid the warnings is to set the SECURELOAD system variable to 0. That’s generally not recommended because it turns off AutoCAD’s security features. While you’ll probably get away with this, there’s always a chance that a user will load some malware and then you’ll have to explain yourself to management.

If you’re not just using your code internally and it’s going to be used by other parties, then you’re not going to have that level of control over the user environment. In recent AutoCADs it’s possible to set up the installation deployment such that users can’t turn off the security settings. If the CAD Manager at the location using your code has done this, your potential users are going to be presented with unprofessional-looking scary warnings.

If you sign your code, users might still get a warning, but it’s less scary. It identifies you as the verified source of the code so they will have more confidence in picking the Always Load button. Once they’ve done this, other signed code of yours will be automatically trusted.

There’s another important reason you might want to sign your code, and that’s protection against other people’s modification of your code. If somebody edits your LSP file and then gives it to someone who tries to load it, the user is presented with an even scarier warning:

Note that this warning no longer has your name on it. This means it’s possible to protect yourself from people (internal or external) who well-meaningly hack about with your code and then try to blame you when it goes wrong. It also gives a level of protection against your code being infected by malware.

Note that all of the above only applies to AutoCAD 2016 and later. AutoCAD 2014 introduced some LISP loading security measures, but the signature stuff came a couple of releases later. Earlier AutoCAD releases, along with compatibles such as BricsCAD and ZWCAD, will just ignore the digital signature. It’s just a comment in the code as far as they’re concerned.

LISP files with the LSP, MNL, FAS, or VLX file extensions can be digitally signed. There’s a bug in the original iterations of AutoCAD 2016 and AutoCAD 2018 that prevents signed VLX files from working. This was patched later in both releases (2016 SP1 and 2018.0.2), but if you’re distributing your code externally there’s always a chance that your VLX might end up in the hands of somebody using a broken release. Also, VLX files that are digitally signed cannot be loaded into AutoCAD 2015 and earlier, broken or not. You should bear that in mind before distributing signed VLX files. I don’t do it and would advise against it. Thanks, Autodesk.

Given this information, if you decide that signing your LISP is a good idea, watch this space for information on how to do it.

Setting your application or document window size using LISP

1 Reply

I intend to produce a few videos containing tips, tutorials, product comparisons and the like. I’ve set up a cad nauseam YouTube channel, but don’t bother visiting it yet because it’s empty.

One of the things I need to do for these videos make sure I’m capturing the screen at an appropriate resolution. I knocked up a bit of Visual LISP to take care of this task quickly and accurately, and you might as well have it. It’s a simple routine that allows you to accurately size either the main AutoCAD application window or the current document window (drawing area) within the main window.

The file is WindowSize.lsp. It should work in all full AutoCAD releases (not counting LT and AutoCAD for Mac) and AutoCAD-based verticals from 2000 on.

It works in recent BricsCAD releases (except the free and LISPless BricsCAD Shape). I’ve only tested it in Windows, but it should also work in the Mac and Linux versions due to the high degree of LISP compatibility provided even across platforms. It also works in ZWCAD 2018 for the main application window, but don’t use it on the document window because that doesn’t work.

Download it, put it in a location of your choice and load it into your CAD application (for example by dragging and dropping it from Explorer onto the drawing window).

Note: In AutoCAD 2014 and later, loading any LISP or other executable file may result in a warning depending on the release, the security settings, whether the file is located in one of AutoCAD’s trusted locations, and whether the file is digitally signed. I’ve digitally signed the file to reduce the incidence of warnings, but you could still see something like this:

The verified publisher should be cad nauseam as shown above. If you pick Always Load then you shouldn’t see the warning again for this file or any others signed by cad nauseam. Feel free to edit the file for your own needs, but if you do the signature will become invalid and you’ll be warned again when loading the file.

Once it’s loaded, enter the command WindowSize. The prompt sequence goes like this:

Command: WINDOWSIZE Window to size [Application/Document] : Width in pixels <1280>: Height in pixels <720>:

Now, back to work on the first of those videos.