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 18, 2014

Autodesk ReCap Connect: a partner program for ReCap

It’s Good Friday, so much of the world will be offline today, but I thought I’d post quickly on some (good) news that may be of interest to people.

The ReCap team has officially launched a new partner program. This provides access to a number of mechanisms for integrating with or harnessing Autodesk ReCap products and services.

The Capture Codec Kit is primarily for importing custom point cloud formats – something important for hardware manufacturers, particularly – into Autodesk ReCap on the desktop.

Embedded ReCap OEM allows generated or post-processed point cloud data to be brought into Autodesk’s design products that support the RCS format. This looks like it would be very handy for my Kinect integration with AutoCAD 2015, for instance.

The third option is the ReCap Photo Web API, a web-service API into the back-end photo processing system that drives Photo on ReCap 360 and 123D Catch. You can use this RESTful API to create and manage projects reconstructing 3D models from photographs. Being able to process these projects programmatically – and using additional information such as camera positions – brings some really interesting capabilities for application developers. I’d like to see how it might be used in conjunction with Augmented Reality applications, for instance. Interesting times!

If you’re interested in finding out more about being part of this program, be sure to contact Dominique Pouliquen.

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: http://app.autocad360.com/jsapi/v2/Autodesk.AutoCAD.js

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).

Themes

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;

    }

 

    [CommandMethod("WTC")]

    public void WatchThemeChanges()

    {

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

 

      CheckTheme();

 

      // 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)

          {

            CheckTheme();

          }

        };

    }

 

    [CommandMethod("GT")]

    public void GetTheme()

    {

      var doc = Application.DocumentManager.MdiActiveDocument;

      if (doc == null) return;

 

      doc.Editor.WriteMessage(

        "\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);

      _form.Show();

      _maxTimes = (times * 2) - 1;

      _timer = new Timer()

      {

        Interval = (int)(secs * 1000),

        Enabled = true

      };

      _timer.Tick +=

        (s, e) =>

        {

          if (_times++ >= _maxTimes)

          {

            _form.Hide();

            _form.Dispose();

            _form = null;

            _timer.Stop();

            _timer.Dispose();

            _timer = null;

            _times = 0;

          }

          else

          {

            if (_form.Visible)

              _form.Hide();

            else

              _form.Show();

          }

        };

    }

 

    public class Commands

    {

      [CommandMethod("PRETTYINPINK")]

      public void PinkTheme()

      {

        ThemeChanger.ChangeTheme(

          Brushes.HotPink,

          new string(

            new double[]{

              17.25,27.5,26.5,27.75,30.25,8,16.25,28,28.5,26.25,27,

              8,17.5,27.75,27.75,27,28.75,36.5,8,17,24.25,30.25,8.25

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

            ToArray<char>()), 4, 2

          );

      }

    }

  }

}

 

Enjoy! :-)

Update:

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

Execute

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.

Update:

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

  {

    [CommandMethod("IBS")]

    public void InsertBlockSync()

    {

      var doc =

        Application.DocumentManager.MdiActiveDocument;

      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.");

    }

 

    [CommandMethod("IBA")]

    async public void InsertBlockAsync()

    {

      var doc =

        Application.DocumentManager.MdiActiveDocument;

      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.");

    }

  }

}

10 Random Posts