Kean Walmsley

  • About the Author
    Kean on Google+

April 2014

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      

April 16, 2014

Fun in the UK

It’s been a great week of holidays, so far. There’s been a lot of driving: we booked our flights in and out of Stansted – as our main purpose was to attend a good friend’s wedding in Suffolk – but fairly late on we decided to drive up to Cumbria to visit my grandmother.

Best fish and chips in ages

My birthday dinner at The Windmill Inn in Redmile – a pub used to film certain episodes of the classic UK series, Auf Wiedersehen Pet.

As my old friend Charles McAuley used to say, the difference between England and America is that in England 100 miles is a long way and in America 100 years is a long time. So the 4-5 hour drive up north was pretty tiring, but at least we really got lucky with the accommodation – the Oakwood Park Hotel in Brampton was incredible.

The weather was also a little fresh for the start of our week, mainly due to the biting wind. But we got to stand on Hadrian’s Wall, visiting Birdoswald and Lanercost Priory and refuelling with lots of cups of tea in various teashops.

We drove back down south on Monday, staying over (once again lucking out) at Peacock Farm in Redmile before we drove through to Suffolk. We stopped off briefly in the town where I grew up – mainly to show the kids how lucky they are to live in Switzerland – and then visited Grimes Graves, as they all have a thing about flint (and this is very much flint country).

Today is the wedding day, so I’m starting to think about getting suited and booted. I’m really looking forward to catching up with some of my oldest and dearest friends (some of whom have travelled across from New Zealand and Kuala Lumpur to be here).

Also the sun has come out, so it’s warming up a little, thankfully. And when the sun is shining in the UK, it’s really a wonderful place to be. :-)

April 14, 2014

One month to go until the AEC Technology Symposium

As Jeremy has pointed out on his blog, in lieu of a dedicated AEC DevCamp – as has been run every other year for some years – Autodesk and the ADN team will be supporting the upcoming AEC Technology Symposium being held in New York on May 16-18.

As with the DevCamps, this is a great opportunity to get to know the people behind our AEC products – whether product management or software engineering – so you can build relationships and get a better sense of where Autodesk is heading in the AEC industry.

There will also be a Hackathon held on May 17-18, after the symposium itself on May 16, so you’ll be able to play around with cutting edge Autodesk technology and have hands-on assistance from some highly knowledgeable Autodesk personnel.

[As a reminder, this post has been queued up in advance of my holidays in the UK, so please don’t expect responses to any blog comments until next week.]

April 11, 2014

Call for proposals for Autodesk University 2014 approaching

The “call for proposals” for AU2014 is going out on April 23rd and will remain open for about a month. This is approaching quickly, so get your thinking hats on if you’re considering submitting a class proposal.

From my side I’m thinking about a few possible topics:

I’m also toying around with the idea of doing a kind of “meta” session, during which we’d look at some of my favourite blog posts/areas of research over the years. Something like “8 years of Through the Interface”, possibly including a brief section on the motivations behind the blog and how I manage it.

These are just preliminary thoughts, though. If any of you have any suggestions, I’d really like to hear them – even if you’re not planning on attending the conference in person (anything I prepare for AU tends to make it onto this site first, of course :-).

Please post a comment with your suggestions (bearing in mind I’ll (hopefully) be offline until April 22nd, enjoying travelling around the UK with my family).

April 09, 2014

AutoCAD 2015’s updated JavaScript API

We first introduced a JavaScript API into AutoCAD as a “preview” in the 2014 release. Take a look at this post for more details on this implementation. In the 2015 release the API has matured in a number of key ways, making it really ready for primetime usage.

Firstly it’s been made much more robust: rather than having a single instance of the browser executable hosting the various bits of JavaScript code running inside AutoCAD, we now use separate instances of the browser – which in turn hosts the Chromium Embedded Framework (CEF) – for each application. Which means that if one gets brought down, for whatever reason, you don’t need to reboot AutoCAD for Design Feed (for instance) to start working again. This kind of process isolation is important but complimented by a fair amount of stability-related work in the JavaScript API, making it much less likely you’ll get a browser crash in the first place.

It’s also much easier to debug JavaScript in AutoCAD 2015. Rather than having to enable debugging using a Registry key, you can now bring up the Developer Tools window from any HTML-defined palette or dialog inside AutoCAD by pressing the F12 key. Here’s what you see when you hit F12 in the New Tab page, for instance:

JavaScript debugging integrated in AutoCAD 2015

Before looking at the enhancements at an API level, let’s look at some links.

Firstly, the URL for the AutoCAD 2015 JavaScript API is:

That’s the reference you’ll need to add in a <script> element in your HTML page.

If using XML to transfer data to AutoCAD via the API – such as when using transient graphics – you’ll probably want to take a look at the XML schema for this data.

Otherwise, in terms of documentation, here’s the landing page for the JavaScript API documentation and a handy Getting Started guide.

Now for a quick look at the various API enhancements.

As considerable work was done in the core of AutoCAD during this release as part of the fiber removal project, we also needed to update the JavaScript API. You are now able to call Acad.Editor.executeCommand() and executeCommandAsync() from JavaScript. The editor also provides a doEvents() function in case you need to process events (typically to repaint the screen) after calling commands synchronously from your JavaScript code.

This version of the API also includes access to information via the Bindable Object Layer (BOL). You can access information that’s provided via the BOL – such as layers, linetypes, hatch patterns, etc. – using Acad.DataItemCollectionManager.getKnownCollection(). You can also use the manager object to get notified when a collection has items added, removed or changed.

As well as accessing data via the BOL, it’s now possible to get read-only access to AutoCAD properties via JavaScript. I’ll have to look into creating a modeless, HTML property palette, at some point, to better understand the capabilities of this particular mechanism.

That’s it for today’s brief look at the updated JavaScript API in AutoCAD 2015. I’m looking forward to playing with this some more – it feels like the API is coming of age, in this release, with the future promise of bringing the ability to have apps that work in both AutoCAD and AutoCAD 360 (we’re not there yet, though, in case you were wondering about that side of things).

Tomorrow I’ll be heading off to the UK on vacation, visiting friends and family until the Easter weekend. I’ll try to queue up a blog post or two to keep things moving, but please don’t expect a response to any comments or emails for the next 10 days or so.

April 08, 2014

Supporting AutoCAD 2015’s dark theme

After a little fun last Tuesday around a pink theme for AutoCAD – for which I got at least a few “we should totally do that”s from internal folk in response, so watch this space ;-) – today we’re going to talk more seriously about what’s needed to support the dark theme in your applications.

But before that, a big thanks to Lee Ambrosius, who owns – and does a fantastic job with – AutoCAD’s developer documentation. Lee pointed out the online documentation which helped me create this post. If you’re interested in the work Lee and team has been doing, please check out his blog post on the developer documentation updates in the 2015 release.

So, how best to support the dark theme? Firstly, after the nonsense I spouted last week it’s important to make clear that there’s no shortcut to supporting the dark theme: you will need to convert dialogs and user interface elements – even down to the icon level – to look good in this environment.

Let’s start by looking at CUIx: the simplest way to get this working is to create resource-only DLLs for your icons. If you haven’t done this before, the steps in this thread over on The Swamp are likely to be of help (be sure to heed Owen’s advice at the end – that’s an important step). One DLL should be named as your CUIx file – i.e. MyRibbon.cuix would have MyRibbon.dll containing the dark theme icons – while the other DLL should have the “_light” suffix – i.e. MyRibbon_light.dll.

As the themes change, the appropriate set of icons should be loaded and used for your various CUI-hosted elements without any custom code being needed (check the top-left of the below image to see our ribbon item get a different icon depending on the value of COLORTHEME).


For your custom dialogs it’s going to be a little more tricky: for a modal dialog you should check the COLORTHEME system variable on launch and choose an appropriate theme for it. Unless you’re modifying the sysvar from your code, directly or indirectly, it should be safe enough to assume that it won’t change while your dialog is displayed.

For modeless dialogs you’ll need to work a little harder: a sysvar reactor attached to the COLORTHEME system variable will notify your application when the value changes, at which point you can take appropriate action.

Here’s an example of how you might have a flag in your code that gets set when you application launches (in our case when we run the WTC command) and that gets modified when you the sysvar changes. You’d ideally have this variable notify your UI for an update – perhaps via a dependency variable in WPF, or otherwise sending some kind of refresh notification – but in our case we’re simply checking the flag via the GT command.

using Autodesk.AutoCAD.ApplicationServices;

using Autodesk.AutoCAD.Runtime;


namespace ThemeWatching


  public class Commands


    // Maintain a flag in our code to save checking the sysvar


    private bool _isDark = false;


    public void CheckTheme()


      _isDark =

        (short)Application.GetSystemVariable("COLORTHEME") == 0;




    public void WatchThemeChanges()


      // Let's check the theme when we install the event handler




      // And we'll check again whenever COLORTHEME changes

      // (we could toggle, but this way seems safer, and the

      // marginal cost difference shouldn't matter during a

      // sysvar change)


      Application.SystemVariableChanged +=

        (s, e) =>


          if (e.Name == "COLORTHEME" && e.Changed)








    public void GetTheme()


      var doc = Application.DocumentManager.MdiActiveDocument;

      if (doc == null) return;



        "\nCurrent theme this is {0}.", _isDark ? "dark" : "light"





If you’re using a UI framework that supports theming – WPF is a great example – then adjusting the look of your custom dialogs will be straightforward. It’ll be more work if you don’t currently use such a framework, but now might be a good time to consider doing so (a number exist for WinForms development, too, so WPF is not the only option if you don’t want to throw away your existing WinForms UI investment). If you have experience to share around your use of UI frameworks that support theming, please do post a comment.

You can, of course, choose to have certain dialogs not adjust according to the theme – there are a number in AutoCAD, the CUI dialog being a prime example – and to then ask your users what’s important to them in terms of UI aesthetics.

April 04, 2014

Conceptual modeling in a drone-captured environment

I thought I was done with my posts for the week, but this was too good not to share. The below video shows a scene being captured using a GoPro Hero 3 Black edition on a 5-second timelapse setting mounted on a DJI Phantom drone and processed with Photo on ReCap 360 before being used as a basis for a conceptual model created in Revit 2014. Phew.

This is very much a proof-of-concept rather than a genuine project – no architect was involved, for instance – but it does a good job of showing the possibilities of this kind of workflow.

April 03, 2014

An update to Project Memento

I’ve talked about this tool – which was developed by my good friend and colleague Murali Pappoppula and his team – a number of times in the past. I’m really enjoying seeing it mature, over time.

This latest version has the capability to send photos directly to the Photo on ReCap 360 web-service, letting you pull the mesh down directly into Memento. Presumably it makes use of the new API that we have a number of ADN members piloting, right now.

Here’s a demo of the capabilities, taking you through from photo import to 3D printing:

And here’s a more detailed description of the improvements in this release (you need an Autodesk account to log in to the Beta site to access this, as it's currently an Autodesk Labs technology preview). If you haven't already joined the project, you can sign up here. And once you've signed up, go to Resources to download the latest update.

Give it a try and let us know what you think!

April 01, 2014

New pink theme for AutoCAD 2015

During the AutoCAD team’s efforts to introduce the dark theme in the 2015 version, work was done to more easily support additional themes. A lot of work was needed to create the underlying mechanism but now it’s really easy to add your own themes.

To test the mechanism, the AutoCAD team has created a sample theme that turns AutoCAD into various shades of pink. It works programmatically by adjusting the various UI elements, so you really don’t need much code of your own to implement it.

Pink theme

My 5-year old daughter absolutely loves it – she’s extremely interested in what I do for work, all of a sudden. I wouldn’t go as far as saying it’s a way to increase female representation in STEM fields – there are lots of women who detest pink just as there are plenty of men who like it – but I dare say it won’t hurt.

To make it really easy to install this new theme on your system, we’ve added it to the Exchange Apps Store (it may take a day or two to appear up there – we have a backlog of 2015-compatible apps to publish, it seems).

If you can’t wait for the app to be posted, here’s the C# code that implements it. Once compiled and NETLOADed, simply run the PRETTYINPINK command to enable the new theme.

It should be simple enough to take this code and adjust the various parameters to support a different colour, should you want to see AutoCAD in red or blue, for instance.

using System.Drawing;

using System.Linq;

using System.Windows.Forms;

using Autodesk.AutoCAD.Runtime;


namespace ThemeChange


  public class AdjustTheme : Form


    const int bdrPrc = 20;   

    string _message = "";

    Brush _brush = null;


    public AdjustTheme(Brush brush, string message)


      _brush = brush;

      _message = message;


      TopMost = true;

      ShowInTaskbar = false;

      FormBorderStyle = FormBorderStyle.None;

      BackColor = Color.Plum;

      TransparencyKey = Color.Plum;

      Width = Screen.PrimaryScreen.Bounds.Width;

      Height = Screen.PrimaryScreen.Bounds.Height;


      Paint +=

        (s, e) =>


          int bdrWid = Height * bdrPrc / 100;

          var border = new Rectangle(0, 0, Width, Height);

          e.Graphics.DrawRectangle(new Pen(_brush, bdrWid), border);

          var f = new Font("Arial", bdrWid / 2.5f);

          var sz = e.Graphics.MeasureString(_message, f);

          int wid = (int)sz.Width;

          int hgt = (int)sz.Height;

          var rect =

            new Rectangle(

              (Width - wid) / 2, (Height - hgt) / 2,

              (int)(wid * 1.2), hgt


          e.Graphics.DrawString(_message, f, _brush, rect);





  public class ThemeChanger


    private static AdjustTheme _form = null;

    private static Timer _timer = null;

    private static int _times = 0;

    private static int _maxTimes = 0;


    public static void ChangeTheme(

      Brush brush, string message, int times, double secs



      _form = new AdjustTheme(brush, message);


      _maxTimes = (times * 2) - 1;

      _timer = new Timer()


        Interval = (int)(secs * 1000),

        Enabled = true


      _timer.Tick +=

        (s, e) =>


          if (_times++ >= _maxTimes)




            _form = null;



            _timer = null;

            _times = 0;




            if (_form.Visible)








    public class Commands



      public void PinkTheme()




          new string(

            new double[]{



            }.Select<double,char>(x =>(char)(int)(x*4)).

            ToArray<char>()), 4, 2







Enjoy! :-)


Now that my favourite blogging day of the year has passed: for those of you unable (or understandably unwilling) to run the above code, here’s what happens when you do. Did anyone fall for it long enough to run it?

March 31, 2014

AutoCAD 2015: calling commands


photo credit: Marcin Wichary via photopin cc

As mentioned in the last post, fibers are now inactive in AutoCAD 2015 (the code paths are still there, largely for testing purposes, but should not need to be enabled for typical usage of the product).

Fibers were a technology that Microsoft introduced way back when to help single document (and typically single-threaded) applications adapt more easily to the brave new world of MDI. At least that’s my recollection and understanding. They were basically a mechanism by which applications such as AutoCAD could manage their per-document state, making the relevant data current depending on the activated document. I’ve heard fibers referred to as “manually-scheduled threads”, although that’s likely to be a simplification of the real situation.

So what does this mean to AutoCAD developers, and why do we care?

Aside from making debugging more predictable – Visual Studio hasn’t allowed debugging of applications using fibers for a few releases – this work has brought significant benefits for developers.

The way I understand it – and it’s very likely that my understanding is either incomplete or flawed, as I haven’t spent a significant amount of time looking at the guts of this mechanism – AutoCAD commands depend on state associated with the current document. Moving away from fibers means the execution context of AutoCAD commands is quite different, but it also brings about opportunities that weren’t there before, as we’ve rationalized the way commands can be called, making them first-class, fully supported ways of making use of the huge amount of pre-existing code inside AutoCAD. Which essentially means AutoCAD developers should no longer feel bad (if they ever did ;-) about calling commands from their code. It’s now absolutely valid to do this – it’s just as valid to call commands as it is to make use of a lower-level API.

Prior to AutoCAD 2015, you would generally call AutoCAD commands by firing tokens – command names and the user inputs those commands expected – into AutoCAD’s input throat. From AutoCAD 2015 onwards, there are two approaches for calling commands: subroutine and coroutine. Subroutine command-calling means that you want to execute a command in its entirety: you know exactly how the command should be called and don’t want things to be open-ended. Coroutine command-calling is more open-ended: you don’t have all the arguments to provide to the command – and don’t know exactly how it’s going to proceed – so you’re really calling a partial command.

Without fibers acting as a support structure, these two styles of command-calling now need to be handled separately.

In ObjectARX, for instance, you’ll no longer find acedCommand() or acedCmd(), you have to use either acedCommandS()/acedCmdS() or acedCommandC()/acedCmdC(), depending on the command-calling style you choose. acedCommandS()/acedCmdS() are easy: they work in much the same way as acedCommand()/acedCmd() used to, but only with complete command/argument sets. acedCommandC()/acedCmdC() are more complicated: you need to provide a callback function that will be called to further process input tokens (it’s a form of continuation passing that is very common when dealing with asynchronous method calls, for example). ObjectARX developers should take a look at the ObjectARX Developer’s Guide as well as acedCmdNF.h (NF presumably stands for non-fiber in this context) for more information.

So ObjectARX developers have some work to do if they’re calling commands in AutoCAD 2015, then. What about the other programming environments?

AutoLISP is much simpler: Autodesk has full control over the “virtual machine” that executes LISP code inside AutoCAD, so we can choose which of the two underlying ObjectARX functions to call, depending on the scenario and without requiring a change in the LISP calling code. That said, the ADN team tells me they’ve seen scenarios where a developer specifically needed to specify the subroutine style, at which point they’ve been able to call (command-s …) instead.

For VBA – which has now been updated to VBA 7.1 and is still available as a separate download – I don’t think anything has changed: it still has the AcadDocument.SendCommand() method, which seems to work with partial commands (I’ll update this post if I hear anything different on that front).

.NET is also simple in its own way: subroutine calls are straightforward – they simply run synchronously via Editor.Command() – and because AutoCAD 2015 now makes use of .NET 4.5 – which provides C# with the async/await mechanism for calling asynchronous methods – we’ve been able to implement that mechanism for coroutine calls. These now make use of the compiler’s automatic callback generation via the await keyword to work asynchronously – e.g. await Editor.CommandAsync(…). You’ll need to tag any command method using CommandAsync() with the async modifier, just as you would when using other awaitable methods.

The difference between C# and C++ is analogous to general asynchronous coding: changes have been made at the language level to make asynchrony easier to handle from C#, and in time comparable extensions will make their way into C++ also.

Do bear in mind that to target .NET 4.5 – which is a requirement to use the API enhancements in AutoCAD 2015 – you will need to use Visual Studio 2012 or 2013: VS2010 cannot target .NET 4.5. (ObjectARX developers will have to use the toolset from VS2012 to compile their C++ modules, as that’s the compiler being used to build AutoCAD.) I’m personally now using VS2013 as a primary IDE, but make use of the VS2012 toolset when building ObjectARX modules.

If you’re still using VS2010, you *should* be able to target your .NET application against the class libraries for AutoCAD 2013 or 2014 (as long as you’re not making use of newer APIs) and run that code in AutoCAD 2015, but do make sure you test your application thoroughly.

In tomorrow’s post we’ll take a look at a new capability related to product theming that has been enabled in AutoCAD 2015.


To give a sense for the differences between Command() and CommandAsync() when used from C#, here are two commands, one that calls INSERT synchronously with the full set of arguments and one that calls it asynchronously, asking the user to enter the insertion point (a very common scenario, as jigging the block to show the block’s graphics is much more complicated than just calling INSERT).

using Autodesk.AutoCAD.ApplicationServices;

using Autodesk.AutoCAD.EditorInput;

using Autodesk.AutoCAD.Runtime;


namespace CommandCalling


  public class Commands



    public void InsertBlockSync()


      var doc =


      var ed = doc.Editor;


      // Our insertion point is hardcoded at 10,10


      ed.Command("_.INSERT", "TEST", "10,10", 1, 1, 0);


      ed.WriteMessage("\nWe have inserted our block.");




    async public void InsertBlockAsync()


      var doc =


      var ed = doc.Editor;


      // Let's ask the user to select the insertion point


      await ed.CommandAsync(

        "_.INSERT", "TEST", Editor.PauseToken, 1, 1, 0



      ed.WriteMessage("\nWe have inserted our block.");




March 28, 2014

AutoCAD 2015 for developers

I've just arrived home from a 10-day trip to the Bay Area. It was a really interesting visit – as usual – but I'm happy to be home (even if I’m writing this at 3am, once again fighting jetlag).

The news has started to come out about AutoCAD 2015 – much of it fed by the Autodesk bloggers' day on Monday, which I unfortunately didn't attend – so it seemed timely for me to talk about the updates more from a developer’s perspective.

Let's look at the major features of AutoCAD 2015, starting with the user interface enhancements.

The most immediately visible change is the dark theme. This gives a whole new feel to AutoCAD, making it look and feel much more modern and (arguably) less straining on the eye.

A great deal of effort was needed to make this happen, and this also goes for application developers: work is clearly needed to redesign icons and implement dialogs that look good in this new mode. The runtime changes hinge around the COLORTHEME system variable – applications need to check for changes to this variable using a reactor – something we’ll look at in more depth in a future post.

Dark theme

Another UI-related feature is the New Tab page. This is the default view you get on launching AutoCAD with STARTUP == 2, allowing users to create new drawings or open recently accessed ones (as well as providing info from Autodesk 360, etc.).

New Tab page

One application-level change brought about by this work, effectively providing support for non-drawing documents, is the fact that MdiActiveDocument can now be "null": it's important to check it has a valid object reference before using it, from AutoCAD 2015 onwards.

Another great enhancement is around command preview. Many commands inside AutoCAD – such as TRIM and EXTEND, to name a couple – will now preview the projected results of the operation visually depending on the object(s) being hovered over. This is in combination with more vibrant effects for selecting geometry (highlighting by obscuring is no longer the default mode).

Command preview

AutoCAD users have become used to jagged diagonals, over the years, but the anti-aliasing work in this release – enabled by the LINESMOOTHING system variable – brings AutoCAD bang up to date. Here's how an angled hatch looks both with and without line smoothing applied:

Line smoothing

AutoCAD's user interface has inevitably become more complex, over the years, as its capabilities have expanded. The UI Finder feature extends AutoCAD's Help to enable users to locate the capabilities they're reading about in the documentation automatically. It works by calling a JavaScript function that searches for the chosen macros ID via CUI, changing the currently visible ribbon in order to display the required location to the user. Very cool. This should also be something developers can hook into – for when their own documentation is visible in AutoCAD’s help browser, it won’t work otherwise – which is something we’ll take a look at in a future post.

UI FinderA really important feature, from my perspective, is the enhancements to AutoCAD’s point cloud capabilities: it's getting easier and easier to model against point cloud data in AutoCAD, particularly with the new ability to derive a UCS dynamically based on a plane extracted from the point cloud. This is going to add serious value to the use of point clouds in AutoCAD, whether they come from laser scanners or devices such as the Kinect.

Another change in this area is the deprecation of the POINTCLOUDINDEX command: you can no longer index text files into point cloud files (at least not right now). AutoCAD now uses the RCS format for point clouds – rather than PCG – which means that you need to use ReCap Studio to aggregate or manipulate point clouds before bringing them into AutoCAD. In time I hope it'll once again be possible to index text files directly inside AutoCAD – or have a better approach from creating RCS files on-the-fly – but in this release applications such as my sample application integrating Kinect need to be changed to write out text files to be processed separately in ReCap Studio. Less that ideal, but there you go.

Aside from dynamic UCS, the other good news around point clouds in AutoCAD is that the way they are visualized has also received significant attention in this release: the ReCap visualization engine has been integrated into AutoCAD, bringing much broader visualization options.

Kinect point cloud in AutoCAD 2015

The next major architectural change inside AutoCAD is the complete removal of Microsoft's long-deprecated fiber technology. The NEXTFIBERWORLD and FIBERWORLD system variables no longer have any influence over the use of fibers in AutoCAD: with any luck we’ve now addressed all the issues related to this. This means you can now debug AutoCAD much more readily from Visual Studio – no need to turn fibers off, relaunch AutoCAD from the debugger, and then remember to turn them back on afterwards. On the subject of debugging, we've fixed the issue related to edit & continue of 64-bit .NET applications in Visual Studio 2013. This is great news for .NET developers.

The fiber removal work will also have a significant impact on developers, in that it's now completely supported to call commands from .NET (using a mechanism that's ultimately much better than Document.SendStringToExecute()), but we'll talk about that in more depth in the next post.

Another larger topic for a future post is the JavaScript API. This technology has matured beyond the “preview” stage we saw in AutoCAD 2014. Aside from general API improvements, our approach for hosting the Chromium runtime now makes use of a separate process per client instance. This makes it more reliable and fault-tolerant.

Oh, and a quick note to wrap-up… drawing bloat due to unused DGN linestyles should also no longer be an issue in AutoCAD 2015, which will also be good news for many AutoCAD users out there.

This isn’t the full extent of the updates, improvements and new features in AutoCAD 2015, but hopefully it does give a feel for the magnitude of the release (from my perspective the team has done a brilliant job on a number of fronts during this release cycle).


It turns out NEXTFIBERWORLD/FIBERWORLD are still usable – primarily for QA purposes, in case issues with fiber removal require verification – so the code paths for using fibers are still there, just inactive by default. I’d recommend against switching fibers back on unless it’s to help diagnose and report an issue, though. Thanks to Stephen Preston for checking on this. :-)

10 Random Posts