Category Archives: Development

Why digitally sign your LISP files?

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

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.

Yet more Autodesk software falls off the perch

Just when I thought I was having a nice vacation from tending the Autodesk Graveyard (see also Autodesk products are falling like parrots), another bunch of former best-thing-ever products have bitten the dust.

This time, it’s Autodesk’s Gameware middleware products that have been read the Last Rites. Scaleform, Beast, HumanIK and Navigation can no longer be purchased or maintained. If you used these products, support will cease as soon as your existing maintenance agreement expires. More details on cgchannel.com.

That leaves Stingray as the only surviving middleware product (for now). That’s probably only still alive because Autodesk wants the halo effect associated with currently-fashionable-again Virtual Reality. But how long that remains enough for survival is anybody’s guess.

My brief experience with Stingray at an Autodesk event left me with the impression that it’s a fair way short of being a finished product. I have been much more impressed with Autodesk’s competition in this area. Autodesk’s currently in Product Grim Reaper mode, which is understandable given Autodesk’s ridiculously large product portfolio. However, that does mean that potential Stingray users should be very wary of investing time and resources in a bleeding-edge product that might not be around for long.

Anybody care to have a guess at which Autodesk product(s) will be killed off next?

Image of war graves by Arne Hückelheim.
No disrespect intended to those who paid the ultimate sacrifice. Lest we forget.

The big Bricsys interview 7 – the applications ecosystem

This is one of a series of posts covering an extensive interview with Bricsys CEO Erik De Keyser and COO Mark Van Den Bergh.

In this post, Erik discusses the Bricsys efforts to work with and assist third-party developers. He does this without being prompted by a question – it’s obviously very important to him.


Erik: For our future growth it’s very important, the ecosystem of the applications we have now. We have talked a lot about what we are doing and about our own products, but we should maybe have spent more time on the importance of the ecosystem. The worst thing we could do is forget the application market for us.

We will not, and we are not able, to develop another HVAC system or a [inaudible] system. We are limited in our resources and focused too much in our development. We believe that if there are five or ten HVAC packages, one in Germany, one in France, one in the US and one in Australia, all those guys understand their local markets and it’s very difficult to take an HVAC package made in America and sell it in Germany. The last thing we want to do is destroy that diversity of the application market. On the contrary, we’re going to encourage it. Therefore we will continuously provide APIs to the application market and invite and encourage them to become more professional. This support is so important. That’s where we can make a difference with many of our colleagues, and we should bring the application market to the same level of professionalism. That’s where we are investing as well. They can use all our systems for free.

It would be a great and a wonderful world if you as a customer if you come to our website or you go to an application website and finds the same systems and buys something, and communicates… if there’s a problem, it’s our problem. He can tell us, the application partner can tell us, if it’s an application problem we will tell them or the customer will tell them. But that kind of trio between the customer, us and the application market is so important. We need that.

We need those kind of applications working with our system. And they are there! For over ten years they have wonderful applications. The point is, they lacked, for the moment, the technology to grow into IFC and the BIM market. That’s what we are developing for them now. Right now we need the apps, and we’re delivering to them. But it’s a very important thing for us, that ecosystem. And again I think that’s another difference between us and many, er, alternatives (laughs).

Steve: Not saying “the A word” there…

Erik/Mark: (laughs)

Steve: It’s something I’ve noticed for years, actually, that you guys look after the third-party developers whereas Autodesk sees them as a revenue source.

Erik: Absolutely. We are convinced we need them. They have to say they need us as well. That’s a very good symbiosis. And the top of that is Intergraph. For us, it’s an application partner, right? There’s scalability a bit more than before.  If Intergraph takes this step, let us invite every other application developer to do the same.


This is the complete set of links to this interview series:

BricsCAD documentation – a tale of three systems – part 3

In this third post in what was supposed to be a two-part series, I have more to say about the BricsCAD documentation system. See here for part 1 and here for part 2.

Developer Help – Addendum

In this comment from Bricsys API person Torsten Moses, he informed me about the availability of the Lisp Developer Support Package (LDSP) in the Bricsys Application Catalog. As always, when presented with new evidence I am prepared to re-examine my position on anything. Therefore, I will now further discuss the BricsCAD developer documentation.

The first thing to mention is that the existence of the LDSP package is not obvious. To somebody who uses BricsCAD as-provided and as goes burrowing down through the Help system looking for information, that system is still broken. The documentation as presented to the user remains sub-standard, exactly as described in part 2.

Assuming you know of the existence of LDSP, how do you go about using it? Here are the steps:

  • Go to the Bricsys Application Catalog site, click in the search field and start typing LDSP (you don’t need to hit Enter).
  • The link to the Lisp Developer Support Package (LDSP) will appear: click that.
  • Enter your email address, accept the privacy agreement and pick Download. (Note in passing that this is actually published by Torsten’s own company, not Bricsys).

  • If you’re already a registered Bricsys user (you will be if you’re evaluating it), the download will start. If not, you’ll be expected to register (free):

  • Once you’re registered, the download results in a 12 MB file called Lisp Developer Support Package.rar (RAR is a ZIP-like format).

Any recent commercial ZIP utility (e.g. WinZip) will open RAR files and there are a variety of freeware/adware/shareware utilities available to do likewise. For example, RAR Opener in the Windows Store will present itself as the first option in Windows 10. But it goes without saying that going off in a hunt for utilities wouldn’t be on anyone’s expected to-do list when just looking for product help. A bunch of people would give up here, if not earlier.

I went through with installing RAR Opener, but when I attempted to open the LDSP file I saw this:

Oh, and a handful of empty folders were produced. Is there an email waiting for me at work with the password (my Bricsys registration email is at work but I’m at home)? Am I really supposed to have a password to open this RAR? If so, why wasn’t I prompted for one? RAR Opener doesn’t present me with that option anywhere I can see. Is the download corrupt? Does it refuse to work on a Sunday? I have no idea.

At this stage, many more would give up. How many prospective customers would be filtered out by this experience? There’s no way of knowing. However, I’m made of sterner stuff and persevered with downloading and installing another app from the Windows Store. 9 zip did the job and uncompressed the file, no password required.

Yes, the RAR Opener problem I had above isn’t a Bricsys problem directly. But it is indirectly, because the file I was given to deal with won’t open by default in Windows, where the vast majority of BricsCAD users will be working. It’s a level of obfuscation that you can get away with when dealing with cellar-dwelling geeks handling obscure pieces of open source software. It’s not appropriate for customer-facing documentation in a mainstream CAD application. Yes, even developer documentation, because with CAD applications like AutoCAD and BricsCAD, most of the developers are customers/users/managers, not people trying to sell utilities.

Once you manage to get the file uncompressed (it becomes 41 MB), there are three help systems provided in there (CHM, PDF, HTML). That’s excellent, and conforms nicely with the Bricsys philosophy of providing customers with choice. I was unable to find any broken links. However, even in the LDSP, standard AutoLISP functions are undocumented. So I still couldn’t find the (entget) help I was looking for in part 2:

According to Torsten:

…the standard AutoLISP functions like (entget) are not documented, as there are plenty docs on the web for this; but we document any extension beyond AutoLISP standard, even for the standard functions.

Sorry, but while “we don’t have that information but you can Google it” might have been an acceptable answer for a cheap AutoCAD clone’s API documentation ten years ago, that’s not where BricsCAD is today and most definitely where Bricsys wants it to be in future. Just two days ago, Bricsys CEO Erik De Keyser sat across a table from me and told me that BricsCAD isn’t intended as merely an AutoCAD alternative, but must go well beyond that in order to prosper. He’s right. The BricsCAD developer documentation today is not compatible with that vision. I know it’s that way for historical reasons, but we’re now at a different point in the historical timeline.

Conclusion – Addendum

My conclusion from Part 2 remains valid, despite the existence of LDSP. Both Autodesk and Bricsys have work to do. Downloading LDSP will help with some of the BricsCAD developer documentation failings but leaves plenty behind. It also provides its own set of unfortunate challenges.

This isn’t just a technical and ease-of-use failing, it’s a marketing one. That’s because it acts as a stumbling block to conversion of AutoCAD sites to BricsCAD. Disaffected AutoCAD power users in small sites and CAD Managers from large sites are right now taking tentative steps to evaluate the suitability of BricsCAD to replace AutoCAD in their complex LISP-heavy custom environments. They’ll want to know what’s the same and what’s different so they can estimate the effort and cost involved in the transition before getting in too deep. I know this, because I’ve done it myself. The first thing they will come across in their search is disjointed, very inconvenient and incomplete. It presents a less-than-professional image.

Some potential customers, like me, will persevere and discover that the quality of the developer tools implementation far exceeds the expectation generated by the documentation. Others will give up well before they reach that stage, and that’s a shame.

AutoCAD 2018 – at last, something to praise

This isn’t supposed to be an Autodesk-bashing blog. Really, it’s not. Sure, Autodesk (and anyone else) gets criticism where deserved. There’s been a lot of that lately, but only because Autodesk has thoroughly deserved it. I don’t make up things so I can have a go; Autodesk provides the material all by itself.

Among other things, I’m a customer advocate. I don’t care who you are, act in an anti-customer manner and I’m going to slam you. Hard but fair. Dish up bullshit to your customers and I will gleefully point that out and heap derision on you. Deal with it.

On the other hand, act in a pro-customer manner and I’m going to praise you. I do praise Autodesk (and anyone else) where deserved. There are dozens of examples of that on this blog. Lately, the pickings have been slim. Time to redress the balance a little.

I’ve mentioned before that Autodesk has some great documentation people, including Lee Ambrosius

…who does a great job with developer documentation. That job’s less visible, but still very important and performed to an excellent standard. Lee is very technically knowledgeable and understands users, developers and their documentation requirements. Within the confines of the systems he’s forced to work with, Lee has done the very best job it would be possible for anyone to do.

Lee has again stepped up to the mark and done exemplary work with the AutoCAD 2018 developer documentation. See Lee’s post for details. This list of AutoLISP changes is an example of the sort of thoughtful addition Lee has provided. Thank you, Lee!

BricsCAD’s LISP kicks sand in the face of AutoCAD’s

If you’re a power user or CAD Manager transitioning from AutoCAD to BricsCAD, one of the things you’ll like is that almost all of your LISP routines will just work. That’s not an statement that can be made about various Autodesk products that bear the AutoCAD name, such as AutoCAD 360, AutoCAD LT and AutoCAD for Mac.

It’s not just simple old AutoLISP code that runs in BricsCAD, but complex dialog routines that use DCL, and Visual LISP stuff that uses ActiveX. Yes, even on the Mac and Linux platforms. Some DOSLib functions are built in and the rest can be loaded, as with AutoCAD. Even OpenDCL is supported. It’s a quite astonishingly high level of compatibility.

But it’s not 100%. There are minor incompatibilities, system variable and command-line differences that cause problems in a handful of cases. It’s often possible to work around these and still retain the same code that works in both AutoCAD and BricsCAD. Reporting LISP bugs and incompatibilities to Bricsys generally gets them fixed super-quick.

Also super-quick is the speed at which your code will run. It’s immediately noticeable when running any LISP code that needs to do a bit of processing that it just gets done faster in BricsCAD than AutoCAD. Fast enough to extract the following comment from one of my AutoCAD users trying out a linework cleanup routine in BricsCAD:

Wow.

 
User impressions are one thing, but how about measurements? Today, I had a support job to do that involved running one of my LISP routines. I ran it on both AutoCAD 2017 and BricsCAD V17 on the same PC. AutoCAD took 2970 seconds (about 49 minutes), BricsCAD 1030 seconds (about 17 minutes). Over half an hour saved on one operation. That’s 2.88 times faster, which is consistent with my previous observations with a variety of routines.

Upshot: if you’re doing work where there’s a lot of LISP processing going on, switching to BricsCAD is going to save you a shedload of time.

There is a downside to BricsCAD’s LISP, and it’s a big one; no VLIDE. No equivalent, either. There are various programming editors around that can help with editing code, but no substitute for integrated debugging. It means if you’re a power user, CAD Manager, developer or support person, you’re probably going to have to keep one working copy of AutoCAD around even after you’ve completed the transition to BricsCAD.

Because VLIDE has been in maintenance mode for over 15 years it remains virtually unchanged year after year (including ancient bugs). So it doesn’t matter that much which AutoCAD release you have hanging around. Assuming you’re a perpetual license holder, when you drop the maintenance contract on one of your AutoCAD licenses, you’re entitled to keep using the software as long as you wish, albeit only the current release at the time the contract ends. How long the software will keep working is another matter, depending as it does on factors not entirely within your control.

This is an imperfect solution. Even keeping a copy of AutoCAD around won’t help much if you’re debugging a problem caused by something specific to BricsCAD. Filling the VLIDE hole is something Bricsys needs to work on.

AutoCAD 2017 for Mac released, still half-baked

AutoCAD 2017 for Mac and AutoCAD LT 2017 for Mac have been released. Here’s a video highlighting exciting and innovative new features such as drawing and layout tabs. Despite such stellar advances, it’s safe to say that AutoCAD for Mac remains half-baked, even after all these years. Don’t say I didn’t warn you.

According to Autodesk, these are the features missing from AutoCAD 2017 for Mac:

LAYDEL, LAYMRG, LAYWALK and LAYVPI
Tool palettes
New layer notification
Navigation bar
ShowMotion
Ribbon*
DesignCenter**
Sheet Set Manager***
Steering wheel
Feature finder for help
Model documentation tools
Dynamic block lookup parameter creation/editing
Table style editing
Multiline style creation
Digitizer integration
Geographic location
Simplified, powerful rendering
Material creation, editing, and mapping
Advanced rendering settings
Camera creation
Point cloud
Walkthroughs, flybys, and animations
DWF underlays
DGN underlays
Hyperlinks
Data extraction
Markup set manager
dbConnect manager
WMF import and export
FBX import and export
Design feed
Import SketchUp files (SKP)
Design share
3D print studio
Reference Navisworks models
Right-click menus, keyboard shortcuts, and double-click customization
VisualLISP
.NET
VBA
DCL dialogs
Action recorder and action macros
Reference manager (stand-alone application)
Password-protected drawings
Digital signatures
Workspaces
User profiles
Autodesk desktop app
Migration tool enhancements
CAD standards tools
CUI import and export
BIM 360 add-in
Performance Reporting
Sysvar monitor

* To be fair, AutoCAD 2017 for Mac does have a Ribbonesque feature, albeit one that that looks more like the pre-2009 Dashboard than the Windows-style Ribbon.

** Autodesk claims Content Palette to be roughly equivalent to DesignCenter, but it claimed that (wrongly) about the awful and short-lived Content Explorer. It’s wrong here too; Content Palette on Mac has nowhere near the functionality of DesignCenter on Windows.

*** Autodesk claims AutoCAD for Mac’s Project Manager is functionally equivalent to the missing Sheet Set Manager.

Also, some PDF export features don’t work when plotting, only when using Publish.

No workspaces? No model documentation? No hyperlinks? No table style editing? Various kinds of reference files unsupported? No Visual LISP or DCL? Still? Come on Autodesk, you’re not even trying.

That’s before we get on to the lack of third party applications, vertical variants and object enablers. Is Autodesk expecting full price for this thing? Really?

It’s not all bad news, though. Not having Autodesk desktop app is no handicap at all. Also, according to Autodesk the following features are unique to AutoCAD for Mac:

Coverflow navigation
Multitouch gestures
External reference path mapping
OpenGL Core Profile support
OS notification for updates
Language switching in product

Well that’s all right, then.

BricsCAD startup LISP bug fixed

In my previous post I have a real problem with BricsCAD, I related my then-latest interaction with the Bricsys support system:

Steve Johnson
05-12-2016 05:30 UTC

I don’t know if this is a BricsCAD problem or a DOSLib one, so I am reporting it to both Bricsys and Dale at McNeel. I’m also not sure if this was happening in earlier versions.

If I load DOSLib during an S::STARTUP call and then use the (dos_msgbox) function later in that call, this fails the first time round because BricsCAD things the function is not defined. Opening a second drawing results in the call working as expected. I’ve chopped down our startup routine so you have an example.

; error : no function definition ; expected FUNCTION at [eval]

Awesome Bricsys Person
05-12-2016 12:32 UTC

Hi Steve,

There was a regression introduced in V17.1.10 that caused startup code to execute too early under certain conditions, before the lisp engine document context was properly initialized. This has been fixed now for the next update.

Steve Johnson
06-12-2016 02:43 UTC

I must say, the responses I’ve been getting to my support requests have been absolutely bloody brilliant. Cheers!

Let’s just finish the sequence, shall we?

Second Excellent Bricsys Person
13-12-2016 19:18 UTC

Hi Steve,

I have very good news. The fix is included in BricsCAD V17.1.11, available for download.
Thank you for your help.

Following a fast and straightforward download and install, I can confirm that the bug is fixed. The elapsed time from my bug report to the fix being publicly available and me being informed personally of the fact was 8.5 days. Note that this isn’t a workaround, patch or service pack, it’s a permanent fix that is now automatically in place for everybody who downloads the software.

Edit: the new version was actually released at 4 PM on 9 December, so it was less than 4.5 days from report to fix. Outstanding!

I should mention that I also received a prompt and relevant response from Dale at McNeel, despite the fact that the problem was nothing to do with him!

For somebody used to dealing with Autodesk, this is a breath of fresh air. Bricsys team, take a bow!

Hotfix for AutoCAD 2017 SP1 Autoloader bug

As reported earlier, AutoCAD 2017 SP1 breaks third-party add-ins that use the officially approved Autoloader mechanism. Autodesk is to be commended for acting quickly to produce a hotfix for this. In order to make this hotfix available quickly, Autodesk has taken the very unusual step of allowing a third party to distribute it. See this post from Jimmy Bergmark, who pointed out the bug in the first place. Kudos to whoever at Autodesk made the call to think outside the box to do this. It’s a very un-Autodesk Corporate thing to do, and particularly commendable for that very reason.

It’s important to note that because of the way Service Packs are now handled in AutoCAD and the vertical products based on it, this SP1 bug affects all of those products, not just base AutoCAD. Here is the list of affected products*:

  • AutoCAD 2017
  • AutoCAD Map 3D 2017
  • AutoCAD Civil 3D 2017
  • AutoCAD Mechanical 2017
  • AutoCAD Electrical 2017
  • AutoCAD Architecture 2017
  • AutoCAD MEP 2017
  • AutoCAD P&ID 2017
  • AutoCAD Plant 3D 2017
  • AutoCAD Utility Design 2017

*See links in comments below for further information about this.

Having heaped praise upon Autodesk for acting so quickly, it still needs to be said that Autodesk has done the wrong thing very quickly. Customers who go along with Autodesk’s continuous update push will see third party applications failing. The third party developers will be getting support requests from those customers and will have to persuade them a) that it’s Autodesk’s fault, and b) to go and deal with a manual hotfix that requires admin rights and requires copying/renaming things in Program Files. For customers without sufficient confidence to do that, or for whom just getting permission from IT to perform admin-rights operations is onerous, that’s pretty inconvenient.

It is wrong for Autodesk to offload the consequences of its incompetence onto its victims. Those customers and developers who have simply followed Autodesk’s direction and done nothing wrong deserve better than this.

What should have happened? SP1’s immediate withdrawal. It should be pulled now and reintroduced later (perhaps as SP1a) with this bug fixed. Given we’re only talking about one file, a week or two should do it. The hotfix should remain available for those customers who have already installed SP1, wish to keep it in place, and are happy to do the manual hotfix steps.

The lesson for customers and developers is not to blindly follow Autodesk’s direction. Make your own informed decisions about how you use, manage and develop for Autodesk products.

There are lessons here for Autodesk, too.

  1. Test stuff properly before releasing it. If serious bugs like this are discovered, delay the release until they’re fixed and retested.
  2. When you do screw up, fix it not only quickly but correctly. Don’t offload your problems onto your customers and developers; clean up your own mess.
  3. You’re not competent enough to do the automated continuous update thing. Your customers won’t trust you to do it, and they will be right. Give it up.

If item 2 above involves extra inconvenience and expense, so be it. It’s part of the cost of doing business; people pay a lot of money for Autodesk software, particularly if they’re forced to rent it. But doing item 1 right is actually cheaper and it means item 2 is much less likely to be relevant.

Will Autodesk learn from this? Unfortunately, I can’t be confident about that. I’ve seen too many such lessons unlearned or simply ignored over the years.

AutoCAD 2017 Service Pack 1 is out but you probably don’t want to install it

As reported by Jimmy Bergmark, AutoCAD 2017 SP1 will break add-ins that use Autodesk’s built-in autoloader mechanism. It looks like it’s a problem caused by third party applications, but it’s not. It’s entirely Autodesk’s fault. The only fix at this stage is to uninstall SP1.

It’s astonishing that Autodesk would release a service pack like this, introducing a nasty bug that will break customers’ existing functionality. This reminds me of the comedy of errors that was AutoCAD Release 13 with its multitude of updates, many of which introduced new bugs as well as fixing others. AutoCAD 2017c4a, anyone?

If you needed any more evidence that automated continuous updates from Autodesk are A Bad Idea, here it is. What a crock.

Shout out to Robert McNeel & Associates

Let’s start the rebirth of this blog on a positive note. I’d like to express my gratitude to Robert McNeel & Associates for what must surely be the most outstanding example of long-term customer service in the CAD industry.

These days, McNeel is best known for the 3D modelling software Rhino. I have heard good things about this product, but have never used it. However, I am a long-term user of another McNeel product, DOSLib. This is an extensive set of functions that adds greatly to the functionality of AutoLISP. It all works very well and has saved me many hours of work that I would have spent reproducing that functionality. Of course, many LISP programmers could write functions to calculate a cube root, or read a text file, or display a date in whatever format you like, or copy files, or generate a GUID, or toggle the Caps Lock status, or display an HTML file, or return a list of OLE objects in the drawing, or display a multi-select file dialog, or return a list of Windows printers, or a hundred other handy things. The point is, they don’t have to because all that has been done for them and handed over for nothing.

The documentation is straightforward and accurate, and is provided in the form of a good old-fashioned local CHM file. This Help system may be unfashionable, but it remains infinitely superior to the still-awful system that paying AutoCAD customers have had to put up with for the last few years.

For those investigating alternatives to AutoCAD for whatever reason, the availability of DOSLib for Bricscad may help make that particular alternative a more attractive proposition.

Despite McNeel and Autodesk breaking ties many years ago, McNeel’s Dale Fugier has continued to provide, maintain and improve DOSLib. What’s more, DOSLib has remained totally free of charge and ad-free throughout its history, which dates back to 1992! Sometimes, there really is such a thing as a free lunch.

So here’s a big raised glass to Dale and Robert McNeel. Thank you for the many years of outstanding customer service in exchange for nothing but good feelings. Long may you prosper!

Disclaimer: I have no pecuniary relationship with McNeel; no money has ever changed hands in either direction. This post is totally unsolicited; I hope it comes as a pleasant surprise to McNeel.

AutoCAD 2013 Help shock – it no longer sucks

Some months ago, I gave Autodesk several damn good (and thoroughly well-deserved) thrashings over its hopelessly inadequate AutoCAD 2013 Help system. When Autodesk’s Dieter Schlaepfer responded and asked for feedback, he sure got it. There are 142 comments on that one post to date, most of them leaving nobody under any illusions about how short of the mark the new system was.

There is now an updated version of the AutoCAD 2013 Help system. It has been an interminably long time coming, a fact made far worse by Autodesk’s stubborn refusal to provide a CHM stopgap (which could have easily been done on the ship date with minimal resources if the will had been there), but at least an update is here now. Is it any good, though?

I’ve seen fit to give the online version of the updated system a few minutes of my time and I have to say that it’s now way, way better than it was before. In a remarkable turnaround from current standard Autodesk practice, it would appear that customer feedback has not just been listened to, but actually acted on. Honest! Search results make sense. Performance is generally way better than I expected from an online system. There are links to useful things like lists of commands. Things like forward/back mouse buttons work as expected. Various things I expected to suck, simply didn’t. Huh? What’s going on here?

It’s not all brilliant. There are occasional unexpected pauses, but not to excess. A Douglas Adams fan (Dieter?) is clearly responsible for The Hitchhiker’s Guide to AutoCAD. It’s fun, but I’m not convinced it’s particularly useful. The layout is confusing and the content has me somewhat baffled. Is DRAWORDER really one of the first things a beginner needs to know about AutoCAD? Or were there 41 things in someone’s list and that one was thrown in there to make the number up to 42?

That aside, this thing is looking good. Unlike the last effort, I don’t think it deserves Total Existence Failure. But does it just look good in comparison with what went before? Have I been so shocked by apparent adequacy that I have missed some glaring problem? You tell me. Please, give it a fair go and report back on what you think.

If you want to try the offline version, here it is. It’s not immediately obvious, but you’ll need to uninstall the old one first before the new one will install, don’t bother. It’s still the horrible old thing. See I was wrong about AutoCAD 2013 Help, it still sucks for what I think about that.

LISP programmers, have your say again

Autodesk wants your input again in its annual API survey. This used to be a closed survey for Autodesk Developer Network (ADN) members, but has been open to all for the last few years. If you do any AutoCAD-based development at all, I encourage you to take part. That includes those of us who do most of our development in LISP.

Here’s the direct link to the survey. As you can see if you click the link, there’s a lot of stuff in there that assumes you’re keen to get developing for AutoCAD WS. If you’re not quite so filled with Cloudy enthusiasm and would prefer Autodesk to expend its resources elsewhere (on fixing and improving Visual LISP, for example), please fill in the short survey and say so. It closes on 22 June, so you only have a week.

Why bother, when it’s obvious that Autodesk is determined to ignore to death its most popular API regardless of whatever anyone says or does? I’m not sure, really. Maybe I’m an eternal optimist. (Ha!) Maybe I just want them to at least feel slightly guilty about sticking their fingers in their ears and going “LALALALALA! NOT LISTENING! WE HAVE A VISION, NOT LISTENING! LALALALALA!”

AutoCAD 2013 – Using Help in anger

Trying to be fair, I decided to put aside my initial hostility to the AutoCAD 2013 Help system and use it for real. I used it in a realistic situation, to find out how to work with something new or changed (model documentation) as I was working through it with my own example drawing. Try as I might to give it a fair go, I could only get so far before I got irritated. Using it in anger might not be an entirely appropriate phrase for it, but it’s not that far off. Using it in annoyance, perhaps? Here’s how it went.

I hit F1, wait for it to finish loading itself, click in the search box (because that’s not where the focus is to start with), type ‘model documentation’ and pick Search (because Enter doesn’t work). I then wait again, for about 10 seconds, even though I’ve configured it for offline use. Eventually, there is a huge mass of results displayed, almost all of which are totally (totally!) irrelevant to model documentation. Most of them are relevant only to ARX programmers dealing with completely unrelated matters.

If I use the “phrase” option rather than “and”, the list is much shorter and has a much higher proportion of results that have some relevance, but there are still completely pointless results. For example, the 4th result is About Performance Considerations (AutoLISP), which does not contain the phrase at all. It does contain the words ModelSpace and Document, but not together. It does not contain any information remotely related to model documentation. Didn’t Autodesk buy a search technology company a while back? If that company’s technology is in use here, then Autodesk bought a dud.

At least the top two results directly relate to what I need, so I’ll move on with those. They are Commands for Working With Model Documentation Drawing Views and About Model Documentation. The content of the former page is OK; it’s just a list of commands. There is some pointlessly wasted space at the top of the page that means I have to scroll down to see the bottom of the list, but other than that it serves as a useful reference. The latter page is also fine. It’s an executive summary of the feature with a few relevant pictures, followed by a decent set of links pointing to relevant pages that expand on the subject and explain how to do various tasks associated with it. Now I have overcome the inadequacies of Search and determined that useful Help content is all there, that’s all good then, isn’t it? Not really, I’m afraid.

If Help was being run from a real browser, I’d be able to keep both of those starting pages open with their useful links, then middle-click on each of them as needed to open each useful page in a new tab. However, Help isn’t being run like that. It’s being run from inside Autodesk’s pseudo-browser thing, which only allows one page at a time to be displayed. To be fair, this restriction also applies to the old CHM-based Help to some extent. However, the old CHM Help is split into multiple sections, and it is possible to have multiple CHMs each open in their own windows. For example, I can have the AutoCAD 2010 main Help and Developer Documentation open at the same time, something that’s very important for my productivity and which I would find extremely difficult to give up.

To work around the tabless nature of 2013 Help, I need to choose one particular page and stick to it. When I need another page, I need to navigate back up to one of the original links pages and then back down again. That would be bad enough if navigation within the pseudo-browser was good, but unfortunately it isn’t. Despite what looks like a breadcrumb feature at the top of the page, this is non-functional because of the lack of a hierarchical structure to the content. It just keeps taunting me by saying ‘Home’ and nothing else, pointlessly wasting a swathe of vertical space. There are back and forward buttons in that space, but the back and forward mouse buttons I can use everywhere else do nothing in this browser. You can use Alt+Left and Alt+Right to back and forward. Don’t go too far back, though! If you do, the Search panel goes blank and can’t be restored by going forward again, or by switching between Favorites and Search. To fix this, you can close and restart Help , or pick the Home button and wait about 6 seconds for it to get its act together and restore the Search panel. Then you’ll be at the home page, which may not be where you wanted to go back to.

All right, so I have chosen the single page I’m allowed to have open and I want to use the features it describes. This test PC only has a single 1280 x 1024 screen so there really isn’t room for both AutoCAD and Help at the same time, a situation that will be familiar to users of notebooks. I click on the AutoCAD drawing area behind the Help window, expecting AutoCAD to come to the top and to go behind it. Nothing happens, other than Help losing focus. Help stays on top, obscuring the drawing area. If I click the main AutoCAD taskbar button (this is in XP), that minimizes both Help and AutoCAD. Restoring AutoCAD also restores Help, so it still obscures the drawing area. The two windows are linked, and not in a good way for somebody with one screen. I guess some users will want Help to stay on top, but there are plenty of others who won’t, so what could Autodesk have done to keep everybody happy? Made it configurable, obviously.

Eventually I worked out that I could work on AutoCAD if I explicitly minimised the Help window, so away I went. I used the Commands for Working… page, then the VIEWBASE page to start my model documentation experiment. I then picked another link from the VIEWBASE page, the Drawing View Creation Ribbon Contextual Tab page. Having finished with that, I wanted to get back to the Commands for Working… page, so instead of picking multiple Back buttons (which as noted above is fraught with danger if you do it too often), I clicked on that result in the Search panel on the left. Did this take me back to the Commands for Working… page? No, it did not. It did nothing at all. To make it work I had to click another search result first, and only then the one I really wanted.

One saving grace is that I discovered that if I right-clicked on a link in Help, I could copy the URL and then paste it into a proper browser. This works both on and offline, and allowed me to work around many of the problems noted above. This kludge doesn’t work for search results, though, only for links in pages.

I’ve given AutoCAD 2013 Help a decent go, as much as the average reasonable person would before giving up. Maybe more so. I feel pretty comfortable about giving it what I consider a fair assessment. The content of the Help pages itself looks pretty good to me, at least for those pages I visited and the context in which I was using them. If you already know what command you’re supposed to be using, you just hit F1 from within that command to get at the page you want and you don’t need to go any further, you could well be satisfied. But if you’re using the system in any other way, there’s no getting away from it, it’s a crock. The content is not the problem, it’s the loss of structure to that content, and the browser thing being used to present that content. That loss of structure was A Bad Idea and the browser is a very poor effort. The system as a whole should not have been inflicted on customers.

As a courtesy, Autodesk should do what it did following the 2011 Help debacle and provide a CHM solution for customers to download. It should then go on providing a CHM solution indefinitely, until it can come up with something that is of comparable quality. People are already talking about making their own 2013 CHMs. Autodesk, please do the right thing and save them the bother; let us all know that you’re going to provide CHM as a workaround and get it to us as soon as you can. Don’t worry about losing face by admitting that the 2013 Help isn’t up to scratch. It’s too late for that; we’ve already noticed.

AutoCAD 2013 – Help improved in one area

There’s one important area in which AutoCAD 2013’s Help shines when compared with its immediate predecessors. If you’re a Visual LISP user, you’ll be pleased to know that if you select a function name in the editor (e.g. (vla-get-ActiveDocument)) and hit Ctrl+F1, this now takes you to the appropriate page in the ActiveX and VBA Reference, as it should. In AutoCAD 2011 you just got a cryptic message or a 404 error, depending on the context. In AutoCAD 2012, you were just taken to the front page of Help and expected to find it yourself. Props to Autodesk for fixing this problem.

As a bonus, the reference you’re taken to is still a CHM so it works nicely. The Search tab doesn’t work in Windows 7, but that applies to all CHM Help and it’s Microsoft’s fault, not Autodesk’s. The structured contents and index are fully functional, which makes the whole thing usable even without the search facility.

Autodesk’s Kean about moving to the Cloud

Autodesk’s API guru Kean Walmsley is the second Autodesk person I’ve seen who has been brave enough to stick his head above the parapet by discussing the Cloud, in writing, and in a medium that allows for public comment. Kean has always seemed like a straight shooter to me. Please note that his blog represents his personal opinions rather than an official Autodesk position. He’s after your comments, so please go and let him know what you think on his post. Add your comments here if you’re more comfortable with that, and I’ll make sure Kean sees them.

The worst feature ever added to AutoCAD is…

…the Ribbon, according to your selections in the What are the worst features ever added to AutoCAD? poll. As in the best ever poll, the winner (loser?) in this race had no serious competition. I’ve listed eleven top (bottom?) features here rather than ten, partly because the popular (unpopular?) choice Memory Overuse isn’t exactly a feature. But it’s mainly because I’d hate to see Action Recorder unfairly miss out on a well-deserved mention.

  • Ribbon (30%)
  • CUI (20%)
  • Help (on line / 2012) (18%)
  • Memory Overuse (17%)
  • AutoCAD Today (2000i/2002) (16%)
  • White / Cream Drawing Background (16%)
  • Unreconciled Layers (16%)
  • Nudge (10%)
  • Blipmode (9%)
  • Proxy Object Compatibility (9%)
  • Action Recorder (8%)

Given the reception the Ribbon received when it was introduced, maybe it’s unsurprising to see it top the lists here. Cloud observers may find it interesting to note that that Autodesk’s attempt to move AutoCAD’s Help on line has been very poorly received. Yo Autodesk with your Cloud an’ all, I’m really happy for you, I’ma let you finish, but on-line Help has been voted one of the worst features of all time! Of all time!

The dislike of the intrusive, useful-to-some but short-lived AutoCAD Today feature remains strong a decade later. Light drawing backgrounds remain unpopular, which should not be a surprise to anyone, except maybe some people at Autodesk who thought it was a good idea to rehash old mistakes in a new and exciting way (“This time it’s magnolia!“). History, doomed to repeat, etc.

As for poor old Action Recorder, that has to be the ultimate brochure feature. It’s something for Autodesk to boast about rather than something for customers to actually use; “We responded to customer requests and fulfilled AUGI wishlists for a macro recorder!” Well, you did, kind of, by giving us something that’s about as useful as a chocolate fireguard. Looks nice, though. Autodesk, please try again, but this time do it properly.

It’s interesting to note that the “worst ever” list is significantly younger than the “best ever” list. Only poor old blipmode is truly ancient. Only a single “best” feature (dynamic blocks) comes from AutoCAD 2006 or later. (In fact, that’s the only feature in the “best” list that was even introduced this century). In comparison, most of the “worst” list comes from AutoCAD 2006 or later, including the top (bottom?) three. So what does that tell you?

(so (long (and (thanks (for (all (the (parentheses))))))))

A few days ago, John McCarthy died at the age of 84. He didn’t make a fortune selling gadgets, he just profoundly affected the world of computing. He will be remembered mainly as the father of LISP, without which it is quite possible that AutoCAD and Autodesk would not have survived beyond the 80s. However, his original thinking went well beyond the development of a language. For example, 50 years ago he came up with an idea that is very relevant to what we are actively discussing today:

In 1961, he was the first to publicly suggest (in a speech given to celebrate MIT’s centennial) that computer time-sharing technology might lead to a future in which computing power and even specific applications could be sold through the utility business model (like water or electricity). This idea of a computer or information utility was very popular in the late 1960s, but faded by the mid-1990s. However, since 2000, the idea has resurfaced in new forms (see application service provider, grid computing, and cloud computing.)

(Credit: Wikipedia)

Back to LISP, I still use John’s antique language today. It’s still the best language choice for the vast majority of the development I do. Thanks, John.

Taking control of your command line history

Thanks to Kean Walmsley’s post on his Through the Interface blog, I have learned something that would have been handy to know for the last decade or so, but which somehow escaped my knowledge. I learned how to increase the size of AutoCAD’s command line history cache. It defaults to 400 lines, which isn’t enough for me. I think this information deserves a wider audience than the ubergeek developers who frequent Kean’s blog, so here goes.

Although it’s not directly mentioned on Kean’s post, you can find the current command line history cache length setting like this:

(getenv "CmdHistLines")

This will return a value showing the number of command lines AutoCAD remembers, e.g. “400”. Although this is used as an integer value, it is passed to and from the Registry as a string. You can set a new value as shown below. Again, use a string, and note that values outside the range 25 to 2048 will be ignored:

(setenv "CmdHistLines" "2048")

Also, if you don’t like AutoCAD repeatedly stopping during a long listing (e.g. SETVAR ? *), you can turn off that feature by setting the QAFLAGS system variable to 2. Don’t set it to 8191 as suggested in Kean’s post, because that will change a lot of other settings, few of which are documented publicly.