Category Archives: Customisation

The BLADE video watchlist

I did my third and final (for now) BricsCAD Unplugged webcast about BLADE last Wednesday. Here’s the video:

Before I dig into DCL, I start with a brief description of an absolutely brilliant feature that was added to BLADE in V19. If you code in LISP, you’ll love this feature.

Then I move on to some ancient history. Did you know that we can thank the far-sightedness of some slightly renegade Autodesk OS/2 developers in the early 1990s for the dialog boxes we use today? Did you know that you could program dialog boxes for AutoCAD for Mac in 1993 but you can’t today? Can you spot the items of interest in the background?

The rest of the video is dedicated to describing DCL programming and debugging, and I explain how BLADE is the best tool for that job using examples.

If you want to watch all three of the BLADE videos in a row (that’s 1 hour 49 minutes of viewing), Matt Olding has created a YouTube playlist for this series.

It has been an absolute pleasure working with the Bricsys people in putting this series together. Torsten Moses has informed me about yet another bunch of enhancements that are coming very soon to BLADE, so maybe you haven’t heard the last from me on this subject on BricsCAD Unplugged.

More BLADE videos

As mentioned previously, In December I made a guest appearance on the BricsCAD Unplugged webcast series to discuss the LISP development environment, BLADE (YouTube link).

I made another appearance last week describing debugging using BLADE (YouTube link):

If you’re dealing with LISP code for AutoCAD and/or BricsCAD, you really should be doing it in BLADE. It’s the best development environment for AutoLISP/Visual LISP that you’re ever going to get.

I have another appearance scheduled for later today (13 February) in which among other LISPy things, I will be discussing using BLADE for DCL programming. Again, even if you’re AutoCAD-only, I believe this is worth a watch. BLADE is better for DCL programming, too.

Even if you’re AutoCAD-only and not a programmer, you might find my brief ancient history lesson of interest. Did you know that BricsCAD for Mac users can thank a far-sighted early 90s Autodesk OS/2 team for the dialog boxes they use today?

The BricsCAD Unplugged webcast broadcasts run on the Bricsys Facebook page and are then quickly transferred to YouTube. Today’s session will start at about UTC 14:15 (2:15 PM) on Wednesday, 13 February 2019 (click here for your local time)

Video – who is that masked man?

Last night I made another guest appearance on the BricsCAD Unplugged webcast series. This time I was discussing the LISP development environment, BLADE. Here’s the video:

Bonus points will be awarded for identifying three items of interest in the background. No, not counting my dog Sunday asleep at lower left.

Despite going way over time, there was still nowhere near enough opportunity to describe the full LISPy awesomeness that BLADE represents. I am therefore scheduled to return for another two or three episodes beginning in February. In those, I’ll be doing more of a step-by-step demonstration rather than the overview and V19 new feature description I did in this episode. If you have any particular requests for what you want covered, please comment on this post.

I also showed how the tools in BLADE (e.g. the (inspector) function) are still worth having for any DWG-based CAD Manager or power user, even if you’re not a full-on LISP programmer. If you have to work out what’s going on with dodgy DWG files, you’ll want to have (inspector) in your set of tools.

The BricsCAD Unplugged webcast broadcasts run on the Bricsys Facebook page and are then quickly transferred to YouTube. This was the last episode for 2018 because of Christmas and New Year.

Wielding BLADE on BricsCAD Unplugged

In September I was the special guest on the BricsCAD Unplugged episode BricsCAD Unplugged – Steve Johnson 5 surprises moving to BricsCAD. Next Wednesday I will return, this time to wield BLADE, the best thing to happen to CAD LISP in nearly 20 years. I’ll be introducing it and demonstrating a few things, including the new features that came with V19.

These live broadcasts are run on the Bricsys Facebook page and are then quickly transferred to YouTube. This broadcast will start at UTC 15:00 (3 PM) on Wednesday, 19 December 2018. Here’s that time in a few handy time zones:

Location Zone Time
San Francisco PST 07:00
Minneapolis CST 09:00
New York EST 10:00
London GMT 15:00
Brussels CET 16:00
Moscow MSK 18:00
Mumbai IST 20:30
Perth AWST 23:00

Video – Steve on BricsCAD Unplugged

Following on from Lynn Allen and Robert Green’s guest appearances on the BricsCAD Unplugged webcast a couple of weeks ago, this time it was my turn.

Last night (my time) I was the special guest on the episode BricsCAD Unplugged – Steve Johnson 5 surprises moving to BricsCAD. I’m introduced at 2:12 and appear at 3:30. Here’s the full video:

In this week’s episode, you’ll witness:

  • Me discussing the five biggest things that pleasantly surprised me about BricsCAD. (I have more than five, but time was limited).
  • Don Strimbu bribing me with drinks containers.
  • An actual printed copy of Cadalyst magazine from 1995, complete with my old column Bug Watch (1995-2008).
  • The excellent euphemism, “You’re generally pretty conservative in terms of your praise.”
  • Don throwing me a curveball by introducing my points out of order!
  • The announcement that I’ll be at Bricsys 2018 in London and possibly participating in the BLADE session.
  • Me saying, “No. I’m wrong.”
  • Me drinking a glass of wine (parental guidance advised – alcohol consumption depicted). If you care, it’s a Shiraz (that’s Syrah if you’re American) from South Australia’s Limestone Coast region.
  • Total lack of coordination from everyone in raising our drinks at the end.

Thank you to the Bricsys crew for the invitation, it was a blast! If you ever want me on again, I’ll be happy to oblige.

For future reference, these live broadcasts run on the Bricsys Facebook page and are then quickly transferred to YouTube.

Mac users rejoice – at long last, a LISP IDE comes to OS X

CAD’s best LISP development environment has come to the best “AutoCAD for Mac”. It should come as no surprise to anyone that this has occurred without Autodesk’s involvement.

What’s happened?

With the release of BricsCAD (Mac) V18.2 (currently V18.2.23-1 to be precise), BLADE (BricsCAD’s much-superior equivalent to VLIDE) has been added to BricsCAD

See here for the release notes and here to download. Make sure you select the Mac version:

Significance

This is pretty significant for anybody serious about using DWG-based CAD on the Mac. AutoCAD without LISP is hardly worthy of the name, which is why I’ve never been keen on AutoCAD LT from the moment LISP was yanked out of it just before release in the early 90s. There has never been an integrated development environment for AutoCAD for Mac (either in the first iteration in the 1990s or the second attempt in the 2010s) and I think I can safely predict that there’s never going to be one. I expect AutoCAD for Mac’s LISP to remain forever in 1990 mode.

Compatibility

One problem a small number of users may face when developing for Mac with BLADE is that of downward compatibility. In case you’re wondering, BricsCAD (Mac) to AutoCAD for Mac is very much a downward direction, particularly in the area of LISP. The LISP in AutoCAD for Mac is famously half-baked with large portions of functionality missing, including no ability to control dialog boxes. BricsCAD (Mac)’s LISP is very much more capable, so while compatibility between AutoCAD for Windows and BricsCAD (Mac) is strong, you can’t say the same for LISP compatibility between AutoCAD for Windows and AutoCAD for Mac.

Half of the stuff you write for AutoCAD in Windows is just going to fail when you try to run it in AutoCAD for Mac. Much more of it is going to work in BricsCAD (Mac). While you can now write, debug and run your LISP code efficiently in BricsCAD (Mac) and it’s practically guaranteed to run just fine in AutoCAD and BricsCAD for Windows, it will be very easy to write stuff in BricsCAD (Mac) that doesn’t work in AutoCAD for Mac. Of course, the same downward compatibility problem applies to writing stuff in AutoCAD for Windows using VLIDE.

If you’ve moved on completely from AutoCAD for Mac to BricsCAD (Mac), that’s not going to be a problem. Bircsys building a notably better product that’s significantly more compatible with the main game is not something anybody could reasonably condemn. However, but it’s something to bear in mind if you are hoping to write code that runs on both AutoCAD and BricsCAD for Mac.

Summary

That caveat aside, it’s all good news for Mac CAD users. You already had a product available that would run a much higher percentage of the huge library of LISP out there than AutoCAD for Mac would. For the first time in history, you now also have access to a professional LISP development tool. Lucky for you, it’s the best such tool on the market.

A & B Tip 5 – polyline areas

In this series of posts, I’ll be providing tips that show how to do something in both AutoCAD and BricsCAD, hence A & B.

The Series

The idea behind this series is to provide useful information for several sorts of reader:

  1. AutoCAD users.
  2. BricsCAD users.
  3. People in the process of transitioning from AutoCAD to BricsCAD and who need to know what to do differently (if anything).
  4. People considering transitioning from AutoCAD to BricsCAD and who want to know about the differences and similarities.

What area is that polyline?

There are several ways of determining the area enclosed by a polyline. This post goes through the various methods. You will also notice that in each of the methods, you get the length (perimeter) as a bonus.

Spoiler alert: the most efficient methods are at the bottom. There’s a one-click method in AutoCAD (it needs a little setting up first) and a zero-click method in BricsCAD.

LIST command in AutoCAD

The oldest method is the good old LIST command. Although this has been around for ever, here’s how it works in recent AutoCAD releases. Issue the LIST command, select the polyline, press Enter to finish the selection, and above your floating command line AutoCAD will show something like this:

If this display goes away and you want to see it again, hit F2 and it will return. If you have a docked command line, AutoCAD will display the information on the text screen, which it will then display:

If you have a floating command line but want to see the text screen rather than the over-the-command-line popup, you can switch to it using Ctrl+F2.

LIST command in BricsCAD

The command works in just the same way in BricsCAD as it does in AutoCAD with the docked command line.. The main differences are that the BricsCAD default interface has a docked command line, and that the text screen (called Prompt History in BricsCAD) is displayed even when using a floating command line.

If the text screen goes away or is obscured, you can restore it using the familiar-to-AutoCAD-oldtimers keystroke of F2 (not Ctrl+F2, which toggles the ribbon in BricsCAD).

Unit precision in BricsCAD

Another difference you might notice is that the only whole units are displayed. This is because BricsCAD respects the setting of DIMZIN when displaying values in the AREA command and AutoCAD doesn’t. In this drawing, DIMZIN is set to 8, which suppresses trailing zeroes. Because the area is exactly 448.0, BricsCAD displays it as 448. If DIMZIN is not set to suppress trailing zeroes, this doesn’t happen. If DIMZIN is set to 0, BricsCAD displays the area using the setting for linear units precision, LUPREC. If this is 4, the LIST command will display the area as 448.0000, as it does in AutoCAD.

This respect for DIMZIN applies in other places in BricsCAD too. For the remainder of this post I’ll have DIMZIN set to 0.

AREA command in AutoCAD

Another good old method is the AREA command. Issue the command, use the Object option and pick your polyline. You will be shown the area in two places as shown here:

AREA command in BricsCAD

The AREA command works similarly in BricsCAD. Although the options displayed indicate that the subcommand is Entity rather than Object, you can in fact use either E or O to initiate selection of an object. Unlike AutoCAD, the area is displayed in one place only, the command prompt area:

Note that the AREA command in both applications gives you more options, including adding together several areas.

Properties palette in AutoCAD

If you have the Properties palette visible (Ctrl+1 will toggle it on), you can simply select the polyline and the area will be displayed in the palette, thus:

Note that unlike the AutoCAD AREA command, the Properties palette does respect the value of DIMZIN. To display the trailing zeroes, first set DIMZIN to 0.

Properties palette in BricsAD

Using the Properties palette in BricsCAD is identical to AutoCAD. Here’s the display:

Quick Properties in AutoCAD

Quick Properties is a cursor-based cut-down version of the Properties palette. It’s not what you get when hovering, which is this:

What you want is Quick Properties, which you only get when you select an object, for example:

Unfortunately, Area is missing. It was there once upon a time, but there were performance problems so it was removed by default. However, you can add it back in. Invoke CUI and pick Quick Properties on the left. Scroll down on the right and pick Polyline.

Turn on Area (and Length if you want). Pick OK. Now see what happens when you select a polyline:

Note: in AutoCAD 2014 (and maybe others), the Area option was missing. There’s a workaround, but it’s a complex hack and well beyond the scope of this post.

Quad cursor in BricsCAD

The easiest way to find a polyline area in BricsCAD is just to hover over it. The Quad cursor will appear, giving you the information you need:

Alternatives

If you’re doing this regularly, it makes sense to automate it as much as possible. Depending what you want, menu macros might help. There are also various free LISP routines around that do this sort of thing, for example these by Lee Mac. If you have more specific requirements (e.g. automatic area label, export to CSV), then that’s the sort of thing I do for a living so feel free to get in touch.

A & B Tip 4 – turning on toolbars

In this series of posts, I’ll be providing tips that show how to do something in both AutoCAD and BricsCAD, hence A & B.

The Series

The idea behind this series is to provide useful information for several sorts of reader:

  1. AutoCAD users.
  2. BricsCAD users.
  3. People in the process of transitioning from AutoCAD to BricsCAD and who need to know what to do differently (if anything).
  4. People considering transitioning from AutoCAD to BricsCAD and who want to know about the differences and similarities.

Your First Toolbar

If you are using a ribbon-based workspace, you may want to have some toolbars visible, too. There are several reasons you might want to do this. You might want some buttons to be consistently visible, no matter what the ribbon state. Although the QAT in AutoCAD provides some toolbar space, you might want more space than it offers. You might also want toolbar controls that are not available in the QAT; several of them only work in conventional toolbars. You might want the buttons in a different place, such as down one side or on a second screen.

If you have at least one toolbar visible already, things are easy. If you right-click on that toolbar, you will get a menu that allows you to turn on any other toolbar in the same customization group (CUI or CUIx file). Here it is in AutoCAD:

Here’s the equivalent in BricsCAD:

Note that in BricsCAD, the list of toolbars is one level down because the first-level right-click menu in BricsCAD gives you many more interface options.

What if the toolbar you want to turn on is in a different customization group? You can get at those easily enough by right-clicking on any blank (unused) area of a docked toolbar area. AutoCAD:

You can do the same in BricsCAD:

The difference with BricsCAD is that you don’t need to have a docked toolbar with spare space in it to access toolbars in different groups. They’re all available by right-clicking any toolbar button, docked or not.

That’s all easy enough, but what if you don’t have any toolbars visible? You’re stuck in a Catch-22 situation. You need a toolbar to click on to load a toolbar. How do you get that first toolbar loaded?

AutoCAD Interactive Method 1

The first trap to avoid in AutoCAD is using the TOOLBAR command. From Release 13 to AutoCAD 2005, that was useful. With the introduction of CUI files in 2006, the TOOLBAR command became a near-useless cut-down version of the CUI command.

Ignore that. If you’re going to use the CUI interface, use the whole thing. Enter the CUI command. In the top left pane, pick the workspace you want to change:

In the top right pane, pick Customize Workspace. In the left pane, expand the Toolbars part of the tree and turn on one of the toolbars:

Pick Done (top right) and OK (bottom). Your chosen toolbar will appear.

AutoCAD Interactive Method 2

If you have your pull-down menu bar turned on, you can get at the toolbars using the Tools menu as shown here:

You can turn on your pull-down menu bar by setting MENUBAR to 1.

Thanks to James Maeding for pointing that out.

BricsCAD Interactive Method

In BricsCAD, you can turn on toolbars interactively even if there are none visible, without having to deal with the CUI interface. Just right-click in any part of the ribbon, and you will see the same menu you get when right-clicking a toolbar area. That gives you access to all of the toolbars in all of the groups.

AutoCAD Command Line Method

If you want to use the command line to turn on a toolbar, you need to use the -TOOLBAR command (note the leading hyphen). You also need to know the name of the customization group and what the toolbar itself. One example is the Object_Snap toolbar within the ACAD group. The command line required is therefore:

-TOOLBAR ACAD.Object_Snap Show

To be sure this will work in all environments, I recommend you add the special characters _ and . thus:

_.-TOOLBAR ACAD.Object_Snap _Show

BricsCAD Command Line Method

In BricsCAD, you don’t need the leading hyphen in the TOOLBAR command (although you can use it if you like). The customization group and toolbar names will be different, but the syntax is the same. For example:

TOOLBAR BRICSCAD.TB_EntitySnaps Show

The recommended special characters also do the same job in BricsCAD:

_.-TOOLBAR BRICSCAD.TB_EntitySnaps _Show

Adding Express Tools to BricsCAD

If you’re evaluating BricsCAD to replace AutoCAD, you might be put off by the apparent absence of the Express Tools. Don’t be.

First, some express tool commands have been added to BricsCAD as native commands, such as OVERKILL and TXTEXP.

Next, the Express Tools menu can be added, thanks to a free add-on by Martin Drese (CADwiesel). Here’s the step-by-step process:

  1. Go to the Bricsys Applications page.
  2. Start typing “EXPRESS” into the search box. You should be pleasantly surprised to discover that by the time you’ve typed four characters, what you are chasing will already be displayed for you:
     
  3. Click on the Express Tools box, turn on the checkbox and then pick Download.
  4. If you’re not already signed in with your Bricsys ID at this time, you’ll be prompted to do so. You should have created this ID when you downloaded the main product.
  5. The download (a straightforward one; no nasty download managers involved) is a 3.6 MB zip file. Unzip this to a location of your choice.
  6. As described in the file Install Notes Express Tools for Bricscad V18.pdf, copy the Express folder to the BricsCAD installation folder (e.g. C:\Program Files\Bricsys\BricsCAD V18 en_US). You’ll need admin access for this step.
  7. Add that location (e.g. C:\Program Files\Bricsys\BricsCAD V18 en_US\Express)to the BricsCAD search path (Settings > Program Options > Files > Support files search path).
  8. If you already have a file called on_doc_load.lsp in your search path (this is the equivalent of acaddoc.lsp), then add this line to it:

    (load “Acetutil.des”)

    If that file doesn’t already exist, you can just copy the one from the unzipped location to anywhere in your search path (e.g. the path you just added – C:\Program Files\Bricsys\BricsCAD V18 en_US\Express).

  9. Close and restart BricsCAD.

This is more involved than your typical AutoCAD app store installation, but as a CAD Manager I do like the fact that these are straightforward steps that I can automate in a custom environment such that the users have no need to get involved.

The end result is a Pull-down menu (if you have that turned on – MENUBAR 1 if you don’t) that will be familiar to you:

There are also four toolbar menus:

If you’re using a ribbon and don’t want to see toolbars, substantial manual effort is required to add Express Tools to the ribbon interface. If you are interested in me doing a further post explaining how this is done, please add your comments to this post.

Most of these tools will work with all BricsCAD variants. Some of them require OpenDCL support which is not available in the Classic version, so you’ll need a minimum of BricsCAD Pro (that’s the second level) for complete functionality.

It’s worth noting that the various API LISP functions (acet-xxxx) that are added to AutoCAD by the Express Tools are also there in BricsCAD. Unlike AutoCAD, they are native functions; they can be relied on to be there in BricsCAD, regardless of whether or not the Express Tools add-on is installed as described in this post.

Also unlike AutoCAD, the functions are supported. If there are any problems, you can report them (with, in my experience, a reasonable expectation of them being fixed in a short timeframe by Torsten Moses), rather than being fobbed off by an uninterested Autodesk.

If you go back to step 2 above, see the box that says LISP Developer Support Package (LDSP)? If you code in LISP (with or without BricsCAD), I suggest you download that package. Among many other things, it documents the acet-xxx functions.

Edit: I should point out that R.K. McSwain covered much of this ground earlier this year.

Why every AutoCAD CAD Manager should have a copy of BricsCAD – part 6, future proofing

This is the sixth and final post in this series where I explain why this statement holds true:

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.

This post explains why adding a copy of BricsCAD to your stable of AutoCAD licenses is a good thing for your future and that of your company.

A CAD Management thing I did a few years ago was to examine the options for replacing AutoCAD and other Autodesk products. I was an AutoCAD loyalist (albeit a somewhat critical one) with over a quarter of a century invested in it. I was looking after the deeply entrenched and very heavily customised CAD environment of a major public utility company that had been using AutoCAD as its primary CAD system since the late 1980s. Hundreds of custom commands were in place and providing priceless productivity benefits. Hundreds of thousands of DWG files were on file, with thousands more coming through every month. The inertia behind AutoCAD was very, very strong. Looking outside the cage was a pretty radical step to take. What led me to that point?

  • Autodesk business policy. Autodesk has become increasingly anti-customer over the years in ways that will be familiar to all readers of this blog. I won’t rehash them here. This leads to…
  • Increasing costs. Autodesk software is expensive and getting more so. Autodesk has made no secret of its intention to move to an all-subscription (rental) model. This is an attempt to treble the ongoing income Autodesk receives, in return for doing as little as possible. Which leads to…
  • Lack of progress. It had become clear that the days of AutoCAD seriously improving from release to release were over, never to return. This isn’t because there is no room for improvement, it’s because Autodesk doesn’t want to improve AutoCAD. AutoCAD won’t be permitted to become too capable because that would just eat into sales of Autodesk’s other products. You’re not going to see 3D parametrics or sheet metal capabilities in AutoCAD: buy Inventor instead. You’re not going to see BIM capability: buy Revit. Beyond the internal competition issue, some years ago, Autodesk leadership lost interest in what it perceived to be an old-fashioned dead-end product. The income from AutoCAD customers is being diverted to fund purchase and/or development of more fashionable and interesting products.
  • Frustration with Autodesk’s Beta program. The goings-on within the Autodesk Beta program must remain private, so what I can say here is limited. I can say that I spent many years contributing large numbers of hours to that program in order to attempt to improve the product. As time went on, the positive results that emerged from that effort decreased; that much is no secret because it is apparent in the product. I felt I was fighting against Autodesk to try to improve the product, and losing. There were a few final incidents that persuaded me to stop bashing my head against that particular wall. I wasn’t the only one. I stuck it out for years longer than many very valuable people who had already given up before me.
  • Proxy server issues. Over the years, Autodesk’s habit of attempting to do sneaky things to access the Internet had caused a variety of problems in a secure proxy server environment. This caused several things not to work, and harmed performance severely in some places. As Autodesk’s developers turned over, things that worked in one release would not work in the next. Attempts to get this addressed as a support issue would result in the environment being blamed. These problems increased over the years as Autodesk threw in more and more connectivity-requiring features. There was a non-zero and ever-increasing possibility that one day, Autodesk would screw things up altogether and leave us with non-functioning software. That has already happened for some people, and although the stoppage has generally been temporary, it is important to have redundancy.
  • Poor performance. AutoCAD has been getting bigger and slower. Downloads are huge and Autodesk does its best to make them as difficult as possible. Installations take an age, as do uninstallations. Startup times are terrible and getting worse. My users were complaining – a lot – and there wasn’t much I could do about it.

That’s what moved me to take a very, very serious look at alternatives. Your motives may differ. Just the desire to have a Plan B in case of disaster might be enough.

If you don’t feel moved to investigate, you may eventually be faced with no option. Sooner or later, the person who holds the purse strings at your company may point to this year’s much bigger Autodesk invoice and ask, “What are we getting for this? How can we reduce our costs?” When that happens, you don’t want to be scrabbling round for answers before that invoice needs to be paid. Look into the options in advance. Are you really wedded to AutoCAD or are you actually tied to DWG?

Days of Future Past

Here’s my suggestion. Examine the available alternatives to AutoCAD and the other Autodesk products you use. Do it sooner rather than later so you get the chance to determine the answers to non-trivial questions like these:

  • Capability. Does the alternative product do everything that AutoCAD does, that your users need it to do? Does it do other stuff that AutoCAD doesn’t that you might find useful? What’s the performance like? How does it work on the hardware you have? Does it have user interface elements that don’t just look good but work productively in practice?
  • Compatibility. You will almost certainly demand extremely good DWG compatibility, but this question goes well beyond that. Will your LISP work? How about DCL? ActiveX support? DOSLib? Other programming languages? Can you carry over your customisation files? Can you make the interface look the same? If you have custom toolbars, or ribbon, or even image menus, do they carry across? Can your users carry across their skills without downtime, extensive training and a productivity hit? Can AutoCAD and the potential replacement coexist without issues? Can you use a common set of custom support files pointed at by both products? Will it work well on your hardware?
  • Add-ons. If you’re using third party products on top of AutoCAD, or if you’re using an AutoCAD-based vertical, is that product or an equivalent available? Does it work well? What do the objects they create look like in plain AutoCAD? Can you round-trip through AutoCAD and back and retain your intelligence? You’re probably going to have to test this with evaluation software and your own data.
  • Licensing options. Is perpetual licensing available? Can you stick on a release for a few years and still purchase upgrades later? Has the company committed to providing you with licensing options or has it made noises about going all-rental? Is network licensing available? Does it coexist problem-free with Autodesk’s network licensing software?
  • Costs. Compare the likely costs for all your options over several years. You’re going to have to make some assumptions. It can be difficult to work out what they should be.
  • Track record. Has the company been around for a while? What reputation does it have? Does it treat its customers with respect? How good is the support?
  • Future prospects. Is the company likely to be around long-term? Is it actively developing the product you’re interested in? Is it innovating? Is it merely following AutoCAD at a distance or charging ahead? Is the product going to be limited by Autodesk-like internal competition?

I went through all of these questions and settled on BricsCAD as the best option in my company’s case. In fact, several aspects made it really the only viable option. The product impressed me with high performance, capabilities well beyond AutoCAD in several important areas, a very high degree of compatibility (particularly LISP but also other customisation files), the availability of perpetual licensing and much lower ongoing costs. The company impressed me with its honesty and attitude toward customers.

Most of all, I was won over because I could see that the product had a future. Subsequent improvements have only strengthened that view.

Obviously, you need to make your own judgement based on your own circumstances. I would suggest looking at all the options, including sticking with AutoCAD permanently, with or without subscription or maintenance. Maybe you can use my investigations as a starting point, but I encourage you to start investigating now rather than when you’re under time pressure and don’t have time to do a thorough job.

It will cost you a few minutes to download and install of an evaluation BricsCAD and start preparing for the possibility of a different future. Maybe it won’t turn out to be part of your company’s future, but it could still be part of your future.

Options are good. Learning is good. Best case scenario, your knowledge is going to save your company money and improve its productivity, and you will end up smelling of roses. Worst case scenario, you’re going to spend some very justifiable time doing something new, different and interesting. I recommend it.

Other posts in the Why every AutoCAD CAD Manager should have a copy of BricsCAD series:

Part 1, fixing drawings
Part 2, 3D operations
Part 3, parts on demand
Part 4, efficiency
Part 5, LISP

The game has changed – Robert Green migrates to BricsCAD

Is anybody left who still thinks BricsCAD isn’t a serious replacement for AutoCAD? If that’s you, perhaps the latest news might make you take it seriously. No, not the Heidi Hewett news. Even more recent news than that!

Robert Green, CAD Management guru, Cadalyst writer and consultant (not to mention a rather good guitarist) has been announced as the first Bricsys Certified Migration Consultant.

Image courtesy of Bricsys

Read all about what Robert has to say on this Bricsys blog post.

Anybody who has been reading this blog for the last few years will be surprised by none of what Robert has to say in that blog post. It’s not merely a repeat of what I’ve been saying for some time now, it’s all factually correct and easily verifiable by any competent CAD Manager.

I’ve been there and done that. I’ve gone through the process of taking a very complex custom AutoCAD environment, applying it to BricsCAD and giving it to my users. They loved it. No training was required to work as usual. Most things happened quicker, more conveniently, or both, starting right from the speedy installation. Once the product is in place and established, training can then be applied to take advantage of the places where BricsCAD is ahead of AutoCAD.

If you’re a CAD Manager where AutoCAD is used and you haven’t checked out BricsCAD yet, it’s about time you did.

This might come as a shock to those who see Autodesk domination of DWG CAD as a permanent fact of life, but the game has changed. AutoCAD’s stagnation and comments by senior figures show that the former flagship is clearly unloved by the powers within Autodesk. AutoCAD LT, even more so. An unimpressive AutoCAD 2019 shows that major improvements can no longer be expected in exchange for your ever-increasing annual payments, and with large numbers of people having been offloaded from the research and development teams, who would do it anyway? Meanwhile, BricsCAD development shoots ahead.

Thanks to decades of hostility towards customers that has only accelerated in recent years, Autodesk can’t even rely on customer loyalty for survival. When there’s a serious competitor that offers an easy migration path, the inertia that has kept Autodesk alive so far in the DWG space is no longer enough. The feeling among industry observers I meet is that Autodesk is in a decline of its own making. The only debate is whether that decline is temporary or terminal.

Back to Robert et al. Autodesk has lost many good people, and Bricsys is gaining them. The momentum is clearly with the Belgian company. Anybody want to run bets on who the next big name defector will be?

CAD Panacea tip – startup files in BricsCAD

One of the things that might initially baffle a CAD Manager or power user when investigating switching from AutoCAD to BricsCAD is how to set up the startup routines. Head over to CAD Panacea for R.K. McSwain’s concise, handy description of how to do it.

Due to BricsCAD’s high level of compatibility, you can maintain a common folder or set of folders containing LISP and other custom files for both applications. That way, you don’t need to do double maintenance during the transition period. I’ve done this successfully in a highly complex custom environment. Some code and other adjustments were required in places, but all but a handful of my hundreds of AutoCAD LISP files worked as-is in BricsCAD with zero effort.

Having added your AutoCAD custom folder(s) to BricsCAD’s search path, I suggest you make a common startup LISP file (e.g. rename your old acaddoc.lsp to something like CADStartupDoc.lsp) and have tiny stub startup LISP files for each application (acaddoc.lsp and on_doc_load.lsp) that each loads the common startup file.

acaddoc.lsp contents:
(load "CADStartupDoc")

on_doc_load.lsp contents:
(load "CADStartupDoc")

You can add error checking and messaging if you like, but if you have control of your environment you probably won’t even need that. If you find you do need any application-specific code, you can just add it or load it from the acaddoc.lsp or on_doc_load.lsp stubs as appropriate.

BLADE – putting things back to “normal”

Disclaimer: I’m making money using BLADE. I’m using it on a paying project right now (well, not while I’m typing this, but you get the idea). I’m developing a routine to automate a massively repetitive task for one of my AutoCAD-using clients, and I’m developing it in BricsCAD and BLADE rather than AutoCAD and VLIDE.

I can simply develop faster in the more modern environment, and BricsCAD’s significantly quicker start-up time helps with that. So does the fact that the routine runs several times faster in BricsCAD, making testing the large data sets much more efficient. I’m getting paid on results and not by the hour, so using BLADE is putting cash straight into my pocket while giving me more time to walk my dog.

Using BLADE in production, I’m discovering a few bugs, quirks and things I don’t like. That’s totally understandable with a new feature of this level of complexity and functionality. Where I think it makes sense, I’m submitting problem reports or feature requests to Bricsys. I’m sure Bricsys already has a bunch of these from other developers, so they’ll be very busy for a while. From past experience, I know my reports will be taken seriously and acted on appropriately in a timely manner, if it’s feasible to do so. Your LISP IDE feedback won’t be ignored for decades by Bricsys.

One of the things Torsten Moses mentioned to me that didn’t make it into the published interview was that many developers are very conservative. There’s some truth in that. I’m missing certain keystrokes, for example: 1978-era WordStar Ctrl-Y to delete a line, anyone? It’s a reasonable expectation that as more VLIDE users migrate to BLADE, many requests will come in for VLIDE-like things. I’m told that some of these things will be provided in coming months.

In the meantime, there are things we conservative developers can do to make ourselves feel more at home. One of these is to configure the editor appearance. Here’s the VLIDE editor:

Here’s the BLADE equivalent:

One of the great things about BLADE is how configurable it is, and I know Torsten’s working right now on making it even more so. Configurations are stored in the Registry in a version-independent location (HKCU\Software\Bricsys\BricsCAD\VLispDbgEditor). These can be exported and imported directly or via BLADE, so multiple complete setups and configurations can be managed.

In this post, I’m going to be going through the process of configuring BLADE’s editor appearance to make it look more like VLIDE. I’m not suggesting that’s necessary or even a good idea in most cases, but if you really want to do it, here’s how.

Note: before you do all this manually, please note that at the end of this post I will provide a configuration file that will do it for you.

  1. Start up BricsCAD V18.2 or later and start BLADE using either the BLADE or VLIDE command.
  2. Open a LISP file in BLADE so you can check the effects of the changes we’re going to make.
  3. Use Preferences > Show preference dialog…
  4. In the Preferences & Settings dialog, pick the Styles tab and the Lexer Styles sub-tab.
  5. I’m perfectly happy with Courier New 10, but if you want the VLIDE look, change 1 – Default text to Fixedsys 11.
  6. Click next to 3 – Comment, turn on the Background color toggle and change the Back Color to mid-grey (192,192,192) and Fore Color to dark magenta (128,0,128). You’ll need to specify that RGB value in the lower right corner and use Add to Custom Colors to do this.
  7. Click next to 5 – String and change the Fore Color to magenta (255,0,255).
  8. Click next to 7 – Operator and change the Fore Color to red (255,0,0).
  9. The 8 – Keyword 1 setting should already be blue as in VLIDE. If you want system constants such as T, nil and pi to also be that shade of blue then change 9 – Keyword 2 accordingly. Personally, I prefer a different shade so they stand out. Mid-dark cyan (0,128,192) works well.
  10. I like the pale grey background in BLADE that helps identify the current line. If you don’t, click next to 8 – Caret colour and turn off the Background color toggle.
  11. Switch to the Editor Colors sub-tab, click next to 5 – Selection colour and change the Back Color to a custom mid-blue (0,120,215).
  12. While you’re in the Editor Colors sub-tab, there are a few other non-VLIDE things you can play with. 1 – Brace hilight and 2 – Brace mismatch are dynamically applied to matching and non-matching parentheses respectively. I like my Brace hilight setting to be plum and bold (turn on the Attributes toggle to enable this):

I like my non-matching setting to be white on red (the inverse of a normal parenthesis so it shows up):

Changing all that should give you something that looks like this. Familiar enough?
There are several things in the above image that might be unfamiliar but which I suggest you leave turned on because they’re useful. If you really insist, here are the locations for these settings in the Preferences & Settings dialog:

  1. Line numbers  – View > Margins, Show line number margin
  2. Marker margin – View > Margins, Show marker margin. If this is turned off, bookmarks show up using the settings under Styles > Editor Colors > 13 – Bookmark marker.
  3. Edge marker (that vertical line on the right indicating 80 character width) – View > Edge marker > Type, No background.
  4. Indentation guides (those vertical lines that show you what your code is lining up with) – Tabs and EOL > Indentation, Show indentation guides.
  5. Code folding margin (the margin on the left that allows you to collapse functions, etc. – Folding and Wrapping > Show code folding margin.

Unlike VLIDE, the default in BLADE is to use spaces for indentation, not tabs. As I don’t know of any LISP developer who uses tabs except by accident, this is a much more sensible default. But if you really want to use tabs, turn it on using Preferences > Use tabs and set the width to the VLIDE default of 8 in Preferences > Set tab width.

If you’ve left opening parentheses on previous lines and have indented the following code as usual, then as you go on to finish off the code with closing parentheses, in BLADE a single backspace will take you back your indent width (2 spaces by default) rather than a single space as in VLIDE. If your coding finger can’t get used to this keystroke-saving feature, you can turn this off with Preferences > Backspace unindents.

Having done all that, and having arranged the rest of the interface to your needs (overall window size, pane and field widths, etc.), make sure you save it! It’s as simple as Preferences > Save preferences, but it’s not done automatically. If you want to keep a safe copy of your settings, you can do so with Preferences > Save preferences to file. This simply exports the relevant part of the registry to a .reg file of your choice. This is a text file you can hack about with at your leisure (using BLADE if you like!), and you can even make files that represent subsets of your preferences.

For example, I’ve removed all but the style settings from a .reg file I exported. I’ve uploaded it renamed as a .txt file because .reg files are considered dangerous by browsers, etc.

If you want to use this to give BLADE that old familiar VLIDE look, here are the steps.

  1. Download SteveVLIDE-likeBLADEStyleSettings.reg.txt.
  2. Rename the file to remove the .txt extension so it becomes SteveVLIDE-likeBLADEStyleSettings.reg.
  3. In BLADE, use Preferences > Load Config from File
  4. Close BLADE and BricsCAD.
  5. Restart BricsCAD and BLADE.

That should do it. Happy BLADEwork!

Interviewing the creator of BLADE – CAD’s best LISP IDE – part 2

This post continues my interview with Torsten Moses about BLADE, the new LISP IDE that arrived with BricsCAD V18.2. See here for post 1.

Steve: I’ve noted before that BricsCAD execution of AutoLISP and Visual LISP is several times faster than AutoCAD’s. How does the new technology affect that performance?

Torsten: All the new BLADE-related stuff doesn’t really affect normal LISP execution outside the IDE and debugger. The connection is made by a few callbacks, which take zero time in normal processing. Therefore there is also no chance of breaking things. The BLADE implementation is very safe, and performance remains high for normal usage. For the debugger and the synchronization, it is all home-brewed stuff, optimized for best performance even when debugging, and minimum system and LISP memory usage.

In the course of implementing the debugger and internal versus external synchronization, I also removed most emulations and implemented that as core OpenLisp functionality. That has the side-effect that the (repeat), (foreach) and (vlax-for) functions now run about five times faster at the loop construction. So rather than slowing things down, creating BLADE has actually speeded things up!

Steve: Will the Mac and Linux versions also get this feature?

Torsten: Yes, it is fully compatible. This is due to the implementations of WxWidgets and my own stuff. I have already verified BLADE running under Linux. There are no differences; even the implementation code has no Windows-specific stuff.

Steve: Can you give a simple example of the workflow of a debugging session?

Torsten: First, don’t pre-load any LISP file into BricsCAD. Such code loaded outside the debugger is fully functional, but it can’t be used for debugging. The special connection between internal and external representation is only established when loading the LISP code under a debug state.

Next, in BLADE open an existing FAS or VLX project, and/or a “Named Session”, or simply any LISP file you want to start debugging with.

Now you can select Start Debugging from menu or toolbar, or hit the F8 hotkey. The special Debug Toolbar will appear. You can either activate AutoBreak, which stops at first executable code, or activate the LISP source where you want to start debugging and place some breakpoints.

Then load the dedicated LISP file, either by the normal Load into BricsCAD function, or from the Load button in the Debug Toolbar. Now that loaded code is debug-enabled and you will see the file and debug-enabled functions in the two right tabs.

When the debugger halts at the first breakpoint, all debug-step modes are enabled in the toolbar, and you have all the usual debug step modes. More than in AutoCAD’s VLIDE, actually. You can set the watches (observed and tracked variables) as “Data Break Point” by activating the checkbox. Then, whenever that value changes, the debugger also stops automatically at the related LISP statement.

Steve: What if your code calls code in other files you haven’t loaded?

Torsten: Don’t worry about that. The debugger recognizes this and will ask to load the related LISP file on-demand. In normal LISP, you would get an unknown function error but the debugger catches this upfront. In fact, this is one of the high-end features – only load the primary LISP file, any further debugging into other files resolves by loading during the debugging session. This is very handy for dealing with complex apps – there’s no need to preload any other LISP source. I’m sure you’ve experienced Murphy’s Law, where the particular function you need is the one that’s not loaded. You won’t have that problem in BLADE.

Steve: Where to from here? Is this job done or is there still room for improvement?

Torsten: As BLADE is still a very young product, there is definitely a lot more to come. So far, the main target was to provide good debugging features, and a somewhat reasonable handling of projects, but not so much focusing on plain editor capabilities.

My to-do list still has a number of major key features to be implemented. We want to add a hotkey editor, because every developer loves his own keystrokes and learning others is a nightmare! We also want cross-reference checking on a per-file and per-session basis, mainly for bigger LISP applications.

Then, over time, the editor capabilities will be extended and improved, providing more features. One example is to provide an editor tooltip that shows a function signature and short help when hovering over a LISP function name.

And of course, I’m aware that when people start using this in production, a lot of feedback will arrive from developers in the form of wishes, hints for improvements and bug reports. It’s very likely there will be many wishes to implement several details to make BLADE resemble AutoCAD’s VLIDE more closely. This could be a bit difficult sometimes, and is also not the main target. I hope that developers will be open to a slightly different workflow, given the big advantages they get in return.

In general we are very open to developer ideas, needs and requirements, as we are with BricsCAD itself. In the end, it’s the developer who needs to work with BLADE, as easily and productively as possible. Even the initial release of BLADE is based on important feedback from beta testers such as Martin Drese (CAD Wiesel).

Steve: I can certainly attest to how well you respond to feedback. I’ve seen bugs I’ve reported fixed in a very short timeframe.

Torsten, thank you for your time. This has been very illuminating.

This interview is also available in one post on the Bricsys blog.

Interviewing the creator of BLADE – CAD’s best LISP IDE – part 1

Easily the most impressive new feature of BricsCAD V18.2 is the new Visual LISP IDE, BLADE (BricsCAD LISP Advanced Development Environment). The lack of any LISP IDE has been a BricsCAD stumbling block for a while, dissuading CAD Managers from adopting BricsCAD to replace their stagnant and increasingly expensive AutoCADs.

As I will relate elsewhere, Bricsys has not just caught up with Autodesk here, but has shot so far ahead it’s unlikely to ever be caught. BricsCAD’s BLADE is so superior to AutoCAD’s VLIDE in so many ways there’s really no comparison.

Yet it remains highly compatible. I have personal experience in making large amounts of AutoCAD LISP code (literally hundreds of routines) work in BricsCAD. That experience tells me that the vast majority of code will work just fine (and much faster) in BricsCAD. A tiny proportion of LISP or DCL code may need adjustment before it will work perfectly on both platforms, and that’s one reason an IDE that works within BricsCAD was an important step that Bricsys needed to take.

I had the chance to see this IDE privately in then-unnamed pre-release form when I attended the Bricsys Conference 2017 in Paris. I was surprised and delighted at the functionality demonstrated by its creator, Torsten Moses. I recently had the chance to interview Torsten about his creation.

Steve: I understand it was difficult to create a LISP IDE for BricsCAD because of the way BricsCAD’s LISP works. Can you explain that?

Torsten: BricsCAD LISP uses the OpenLisp core system, from French developer Christian Jullien. This is the only LISP engine still under development; the others I found stopped development in the mid-90s.

OpenLisp is a very modern implementation, not comparable to the old XLisp dialect used by AutoLISP. Even object-oriented features are supported. Therefore the internal representation of LISP expressions is different from the textual representation as seen in a LISP file.

Steve: So the AutoLISP code I write isn’t the code that BricsCAD executes?

Torsten: That’s right. A number of typical AutoLISP constructions were implemented by a kind of emulation, which drives the internal versus textual representation differences even further. That makes it a major challenge to synchronize the internal OpenLisp expression execution with the related textual representation in order to provide any debugging functionality.

Besides the plain technical details, which seemed to be virtually unresolvable, there was the expected heavy effort to implement a full-blown GUI. This was not just a plain editor, but the entire IDE GUI. It would have been a disaster, a major disgrace, if we had provided a VLIDE that was just up to AutoCAD standards. That was great in its time, but it’s 20 years later now. The idea of creating a LISP IDE for BricsCAD seemed so filled with difficulties that we put it off for a long time.

Steve: How did you finally manage to overcome these difficulties?

Torsten: First, it was a pure coincidence. [laughs] By luck, I discovered a hidden detail in OpenLisp – any LISP symbol (and expressions are a kind of anonymous symbols) can hold unlimited, attached custom data, very similar to XData in DWG database objects. I even knew about that for many years, but never worked out the shortcut to ‘misuse’ this for the LISP expression execution to editor and debugger bidirectional connection. Some initial quick tests showed that this approach was very suitable.

By another coincidence, I discovered that WxWidgets (our cross-platform system, not only for GUI) already includes support for the famous Scintilla editor, an OpenSource editor engine, widely used by many editors. WxWidgets even provides two levels of wrappers – a plain, core wrapper, and a high-level wrapper class system. This fits perfectly into the WxWidgets logic.

But still, that is only plain editor support – not a GUI. Then I found a very suitable, extensible editor and GUI implementation, based on that WxWidgets Scintilla system – as Open Source under the WxWidgets license. Hence, we are allowed to use that source code in a commercial application. That editor is called wxStEdit.

I verified that this source was suitable for our LISP IDE, and put in a lot of extra work to extend it. wxStEdit development finished in around 2008, and it still was compiling and working mostly fine. Nevertheless, in the course of extending that GUI, I found and fixed a lot of defects at all related levels (Scintilla, WxWidgets Scintilla wrapper and wxStEdit).

So it was this set of coincidences that suddenly opened both wings of a big gate!

See here for part 2 of this interview.

This interview is also available in one post on the Bricsys blog.

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.

Script for creating AutoCAD Classic workspace

Edwin Prakaso at the excellent CAD Notes blog has done something that, in hindsight, is blindingly obvious but nevertheless very useful to a multitude of people. He’s written a simple script file that sets up the Classic workspace (or something close to it). It works in any recent AutoCAD or AutoCAD LT. Here’s the blog post:

AutoCAD Script to Create Classic Workspace Automatically

Edwin uses Microsoft OneDrive to store the script file, so if your workplace restricts access to Cloud storage you might need to download it at home.

I’ve added a reference to this script to my post AutoCAD 2017 – Putting things back to “normal”.

Return of the bullshit – baked beans edition

In an October 2015 post I’ve only just noticed, snappily titled No More Software Like a Can of Baked Beans: Why Software Subscription Serves It Up Fresh, Autodesk VP (edit – now CEO) Andrew Anagnost bravely attempts to sell Autodesk’s move to all-rental software. This is a rather belated response, but fortunately there is no statute of limitations on skewering spin so let’s get started.

How does he go? On a positive note, top marks for creative writing! The general theme is a strained and somewhat Californian analogy in which perpetual licenses are like canned goods (bad), and rental is like fresh produce (good). However, it’s presented well and professionally written. Among the highlights are:

  • Perpetual software licenses are like high-fructose corn syrup – no, I’m not making this up. Stop laughing at the back there!
  • This is a change that is simply a better experience for everyone – everyone who likes the experience of paying more for less, that is.
  • It’s to create a better product, something tailored to customers – creating a better product seems beyond Autodesk, at least where AutoCAD is concerned. Actually, it’s to create a more expensive product. Tailoring is something we customers been doing for over 30 years without the use of rental software, thanks.
  • There will be less disruption – except a) how we pay for the product is independent of how/when the product is updated and the disruptions inherent in that, and b) even ignoring the erroneous conflation, it’s a mistake to assume that continuous updates are less disruptive. Recent history proves otherwise.
  • Companies (e.g. Autodesk) will work even harder to keep you happy as a rental customer – history gives the lie to this one, too; the closer Autodesk has got to this model and the more people have been locked into annual subscription/maintenance payments, the worse the value for money has become. It also ignores the various alternative ways Autodesk will use to try to keep you tied in. What do you think all that Cloud investment has been for?
  • Autodesk is focusing on helping customers succeed with its products and services – I don’t think so. Autodesk is focusing on trying to keep its shareholders happy.
  • Serial numbers are a terrible dehumanizing thing, rental will make them go away and relying on Autodesk’s internet expertise for Cloud-based licensing is a much more attractive proposition – serial numbers are fine, that’s just silly. There are a host of unnecessary problems introduced by Cloud-based licensing, even when dealing with companies that aren’t as crap at the Internet as Autodesk (e.g. the Redshift site won’t even let me scroll back up once I’ve scrolled past the end of the post). The idea of Autodesk disposing of serial numbers and implementing a phone-home scheme instead is pretty terrifying, and I can only hope that technical issues prevent it from ever reaching production. Mind you, the fact that some new thing is clearly unfinished to the point of uselessness doesn’t seem to prevent Autodesk releasing it these days, so who knows? Hmm, I feel another post coming on about this…
  • Autodesk will make all your customization work for you on all computers and other devices wherever you go – let’s put aside for a moment Autodesk’s total failure to even provide a usable vanilla AutoCAD on the Cloud so far. CAD Managers, would any of you care to hop in and let Andrew know what’s wrong with this picture?
  • Constant automatic incremental updates are like reading news articles daily and much more convenient than larger upgrades which are like getting a whole year’s worth of news at once – again, this makes the fatal error of conflating payment and upgrade delivery methods. Putting that aside, if we’re talking about virus definitions and OS or browser security hole fixes, then yes, automatic updates are the way to go. CAD software, not so much. Particularly software from Autodesk, given the incompetence shown to date in its attempts to make this model work. Even putting aside the practicalities, I could do a whole long post on why this concept is all wrong. Maybe I will later. Meantime, Andrew needs to talk to some CAD Managers to get some idea of how the real world works.
  • “OK, so there’s still the major elephant in the room: What about the cost?” – good of you to mention that elephant, tell me more.
  • For customers, there is real financial advantage by eliminating that huge upfront payment. – For some customers, yes. Not so many, though. Short-term customers are the minority. What about the millions of long-term users who would have their annual costs blown sky-high by falling into your rental trap? Andrew, I see you mentioned the elephant in the room and then tried to avoid meaningful discussion of it, giving the impression you had addressed the issue without actually doing so. Sorry, but I noticed. Care to try again? Tell me more about how you expect either a) customers to be better off by paying more, or b) Autodesk to be better off despite customers paying less. Pick either one of those and run with it, I’m sure it will be entertaining.
  • “And if you don’t need a product for months at a time, switch it off, and then switch it back on. It will be there ready and waiting for you” – strange, that kind of flexibility seems to work for perpetual licenses too, at a fraction of the long-term cost of rental. No guarantee that flexibility is a reality for rental products, though, because the vendor may not provide that product when I need it, or may have racked up the prices to exorbitant levels, or may have introduced new incompatibilities or other technical problems. Oh dear, the boot is very much on the other foot with that argument.
  • “After three years, software becomes obsolete…” – er, no. Many people (myself included) are happily productive using at least some software more than three years old. Some of it works better than the newer stuff. Hands up all those people who couldn’t possibly live without the latest version of Word or Excel, for example. Anyone? Didn’t think so.
  • “…and the pace of obsolescence is rapidly increasing” – if we’re talking Autodesk software, then the pace of obsolescence is doing the opposite. AutoCAD improvement has slowed almost to a halt, for example. There is little in any of the last few releases that gives an AutoCAD 2017 user a significant productivity advantage over an AutoCAD 2013 user, say. And anyone using AutoCAD 2010 or earlier has a much more efficient Help system than that provided in any of the last 7 releases. I guess that’s the kind of anti-progress that happens when you sack a bunch of knowledgeable people every few years and divert too many of the remaining resources to trendier projects that you end up junking anyway.
  • Customers of Autodesk can continue to renew their maintenance contracts for as long as they want – except that Carl Bass has now indicated otherwise. Andrew, maybe have a word with your boss and get back to me on that one?
  • “The company is always listening to how to improve the transition and setting out for the long road, not the short win” – except rental is all about the opposite: short term savings that cost big in the long term. And don’t get me started on the irony of claiming Autodesk is “always listening” while promoting an all-rental scheme that goes against the very clearly expressed wishes of customers.
  • “It’s this beautiful kind of world where things are connected and work together better” – does it have rainbows and unicorns, too? Strewth. Come off it, Autodesk is rubbish at CAD interoperability, even among the AutoCAD-based products. Why should anyone who’s been struggling with poxy proxy objects for a couple of decades believe that paying differently is going to act as some kind of magic spell to make everything exquisite in CAD Connectivity Kingdom?

Here’s the TL;DR version of my response to Andrew’s arguments if you can’t be bothered reading all that:

Bullshit.

 
What are the real reasons Autodesk is going all-rental?

  • Autodesk wants to charge us long-term users three times as much money for the same thing and leave us with nothing at the end of it.
  • Autodesk thinks we’re all stupid and don’t own calculators.
  • Adobe did this and made it work, and Autodesk thinks it can do likewise despite significant business differences, much higher prices and an untrusting customer base.
  • Autodesk has run out of motivation and/or ideas to improve its traditional cash-cow flagship products, to the extent that customers increasingly no longer see value in upgrades or maintenance.
  • Increasing income by product improvement is way too difficult; price gouging and spin is much cheaper.

I’ll conclude with my own strained analogy:

Autodesk spin is like a tin of baked beans. No matter how attractive the packaging, the end result is just a bad smell.

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!