Through the Interface

Jigging an AutoCAD circle from a JavaScript-defined command

Just to complement yesterday’s post showing how to define a simple jig using JavaScript, here’s the same code from a separate .js file:

var doc = Acad.Application.activedocument;

var center = new Acad.Point3d(0, 0, 0);

var radius = 0;

var trId;

 

function pointToString(pt) {

  var ret =

    pt.x.toString() + "," +

    pt.y.toString() + "," +

    pt.z.toString();

  return ret;

}

 

function createCircle(cen, rad, first) {

 

  // Build an XML string containing data to create

  // an AcGiTransient that represents the circle

 

  var cursor = '';

 

  var drawable =

    '<?xml version="1.0" encoding="utf-8"?>' +

    '<drawable ' +

    'xmlns="http://www.autodesk.com/AutoCAD/drawstream.xsd" ' +

    'xmlns:t="http://www.autodesk.com/AutoCAD/transient.xsd" '+

      't:onmouseover="onmouseover"' + cursor + '>' +

      '<graphics id="id1"><circle center ="' + pointToString(cen) +

          '" radius ="' + rad.toString() + '"/>' +

      '</graphics></drawable>';

 

  return drawable;

}

 

function circleJig() {

 

  function onJigUpdate(args) {

 

    var res = JSON.parse(args);

    if (res) {

 

      // The value being updated is the distance

 

      radius = res.distance;

 

      // Use it to create the XML for a transient

      // circle and ask for it to be displayed

 

      var x = createCircle(center, radius);

      doc.transientManager.updateTransient(trId, x);

    }

 

    return true;

  }

 

  function onJigComplete(args) {

 

    // When the jig is over, remove the transient

 

    doc.transientManager.eraseTransient(trId);

 

    var res = JSON.parse(args);

    if (res && res.dragStatus == Acad.DragStatus.kNormal) {

 

      Acad.Editor.executeCommandAsync(

        '_.CIRCLE ' + pointToString(center) + ' ' + radius

      );

    }

  }

 

  function onJigError(args) {

    write('\nUnable to create circle: ' + args);

  }

 

  function onPointSelected(args) {

 

    var res = JSON.parse(args);

    if (res) {

      center =

        new Acad.Point3d(

          res.value.x,

          res.value.y,

          res.value.z

        );

 

      // Now we can create our transient

 

      var tran = new Acad.Transient();

      trId = tran.getId();

 

      // And ask for it to be drawn

 

      var x = createCircle(center, 0, true);

      doc.transientManager.addTransient(tran, x);

 

      // Set up our jig options

 

      var opts =

        new Acad.JigPromptDistanceOptions('Point on radius');

      opts.basePoint = center;

      opts.useBasePoint = true;

 

      // Run the jig to select the distance

 

      var jig = new Acad.DrawJig(onJigUpdate, opts);

      Acad.Editor.drag(jig).then(onJigComplete, onJigError);

    }

  }

 

  function onPointError(args) {

    write('\nUnable to select point: ' + args);

  }

 

  // Ask the user to select the center point before we

  // start the jig

 

  var opts = new Acad.PromptPointOptions('Select center');

  Acad.Editor.getPoint(opts).then(

    onPointSelected, onPointError

  );

}

 

Acad.Editor.addCommand(

  "JIG_CMDS",

  "CJ",

  "CJ",

  Acad.CommandFlag.MODAL,

  circleJig

);

You can test this without the need for a separate .NET loader by just copying this into the command-line in AutoCAD 2014:

(command "_.WEBLOAD" "http://through-the-interface.typepad.com/files/CircleJig.js")

Then you should be able to run the CJ command to jig a circle from JavaScript.

Again, you’ll see the issue related to clicking the point on the radius (unless it’s system-specific, which would surprise me a great deal), but it’ll give you a sense of the kind of responsiveness to expect from a JavaScript-implemented jig.

On a general note, I’ve been finding that it’s simplest to code within a full HTML page – as the reference to the AutoCAD Shaping Layer JavaScript file gives more useful IntelliSense. It does mean you need a .NET loader module to test, but once you have it set up, it’s there. What’s also very handy about this approach is that each time the loader command (in my case it’s called JSP) is run, it reloads the palette from wherever it’s located. So you can change the code and re-run the loader command without restarting AutoCAD (something that’s really entered into muscle memory after all these years of developing with .NET and not having Edit & Continue). One caveat to this is if your code causes the AcWebBrowser to crash: if that’s the case (and it’s pretty common, at least with my code ;-) then you’ll need to restart AutoCAD.

I also tend to load the HTML page from the local file system (using a URL such as  “file://C:\Path\To\MyPalette.html” in the loader module), as this avoids the pain of having to push it to a web-server and deal with the caching issues when loading. It may not have been obvious from prior posts that you can load from a local file system, so I should confirm that it’s possible and furthermore works very well.

In terms of debugging, I’ve been using the technique shown in Fenton’s very handy blog post to enable some level of debugging of HTML-defined palettes (another advantage over a separate .js loaded via WEBLOAD). The server that hosts the HTML inspector tool has changed, however – the URL needs to be changed to “http://drawingfeed.visualtao.net/DevTools/inspector/devtools.html” – but I’m sure the DevBlog post will be updated soon (and may well have been by the time many of you end up reading this).

That said, I still find I’m inserting lots of write() statements into my code (which causes messages to be written to the AutoCAD command-line, the equivalent of acutPrintf() or Editor.WriteMessage()). Maybe that’s another bit of (this time web-development focused) muscle memory that I’ve retained in spite of the world having moved on, but I find it’s a quick enough way of working out what’s going on in the code. Once I get around to using more capabilities provided by the JavaScript debugger, I’ll hopefully find I can afford to unlearn this particular behaviour, but then the fact the debugger also gets blown away when AcWebBrowser crashes means there are a lot of scenarios that write() is still better suited to report on.

Blinking lights with a Netduino Plus 2

After blinking LEDs with an Arduino Uno R3 and its younger step-sibling the Digispark, I decided to give the same treatment to their beef-cake second cousin, the Netduino Plus 2.

James Meading had been telling me to take a look at the Netduino for ages, so when I ordered some parts for my (optimistically speaking) forthcoming Kinect for ZX Spectrum integration, I decided to throw in a Netduino Plus 2.

Now the Netduino Plus 2 retails for $60 in the US (and 80CHF here in Switzerland, as the device is assembled in the US), which means it’s at least twice the price of the Arduino Uno R3 (which retails for $30 or just under 30CHF).

But there’s a reason for this: while it’s the same size – it fits perfectly onto my existing Arduino mount, for example – the Netduino Plus 2 comes with a very different set of components and corresponding performance profile.

Aside from some immediately obvious additions – such as a Micro SD slot and an Ethernet port – the Netduino Plus 2 has an STMicro 32-bit microcontroller that runs at a whopping 168 MHz (as does its own younger sibling, the Netduino Go, which has fewer onboard components – making it around $10 cheaper – but implements a plug-and-play architecture for peripherals). This is more than ten times the clock-speed of the Arduino Uno R3 with its 16 MHz ATMega328P. More on this in a little while.

The Netduino’s name comes from the fact it runs a version of the .NET Framework – in this case, the .NET Micro Framework 4.2 – which means you can code for it using Visual C# Express 2010 or (as is my case) Visual Studio 2010 and debug directly from that environment, too. Which is clearly great if you’ve worked with .NET languages in the past, although I personally haven’t found it very painful to adapt to Arduino’s C subset, at least not for smaller projects.

But the .NET Micro Framework clearly comes with some runtime overhead, both in terms of capacity and performance, so some would argue there’s a need for the more advanced hardware profile.

Whether the Arduino or the Netduino is the better choice for a particular project will depend on various factors: toolset familiarity, library availability, cost, OS support (for the development environment), power consumption, network connectivity (which comes at extra cost for the Arduino Uno), etc.

Beyond evaluating the various factors, the question of which to go for ultimately comes down to a religion discussion, as you’ll soon find when you search for opinions. I’m not yet familiar enough with developing for either device to want to join one camp or the other (and I may never – there’s probably a reason I feel so at home in Switzerland, after all ;-).

I’m personally happy to have a number of different tools available to me that I’ll choose between depending on the project at hand (Digispark, Arduino, Netduino Plus 2 and Raspberry Pi – I have a 128M and a 256M Model B, but I’m also reading interesting things about the Model A, particularly with respect to power consumption). I expect that I’ll tend towards using the Netduino when I know for sure the peripherals I need to connect with are supported and when having additional storage and/or Internet connectivity is important (adding Micro SD and Ethernet support will add $45 to an Arduino Uno project, for instance). And when I don’t want the overhead of running a full OS (as is the case for the Raspberry Pi). I dare say there are other dimensions to the decision that will occur to me, over time, but that’s my sense based on my initial playing around.

Anyway, to at least check whether the basics worked on my Netduino device, I went ahead and built and deployed the multiple LED project. This time I went with a comparable but slightly different effect, as it came pre-coded in the sample project.

Inaugural Zurich .NET Developer meet-up

I headed cross to the Zurich area on Tuesday afternoon – which is quite a trek from where I live, around ~2.5 hours by train – to attend the first Zurich .NET Developer meet-up. The event was held in the Microsoft office in Wallisellen: they kindly provided beer and the meeting room, while the session itself was organised by members of the local .NET community. Considering the weather – a pretty serious snowstorm hit the country that day – the event was surprisingly well attended.

The main topic of the session was MVVM Light, a lightweight framework developed by Laurent Bugnion that makes it easier to implement the Model View ViewModel architectural pattern. Laurent spent some time introducing Windows 8 development and then went on to talk about how MVVM Light can be used to develop for both Windows 8 and prior releases of the OS (and Windows Phone, for that matter):

It was an interesting session: I’d made use of MVC before, but not MVVM. I admittedly tend not to do very much with UI frameworks – I dabble with WPF from time to time, but it’s a rare thing – but I’ll certainly consider using MVVM Light for UI-centric projects in future.

After this session I stayed around to chat with other attendees, the organisers and some Microsoft employees I’d met at previous events. It was a fun evening, and has certainly sparked my interest in going to other such events. I may even offer to present some of the work I’ve been doing to integrate Kinect with AutoCAD, which some members of the local .NET community may find of interest..

After checking out the other groups of interest on meetup.com, I’ve signed up for Zurich FSharp Users, 3D Printing Zurich and ARCH-Swiss Augmented Reality, although I know I’ll end up having to pick and choose between the various physical meetings, if nothing else because of the distance involved. I see there are also meetups in Basel and Geneva – both of which are a bit nearer to my home town – so perhaps I’ll look for interesting groups to join there, too.

The latest on Windows Azure

A few things have happened over the last week or so that have got me looking, once again, at Windows Azure:

Firstly, there was an exciting release announced last week (I attended the webcast online from San Francisco, where the event happened to be taking place), prior to this week’s TechEd. Among the key features were:

• Support for Linux instances
  • These will presumably be cheaper, given the lack of OS licensing costs
• Virtual Machine capability
  • IaaS for those that prefer it over PaaS (something no doubt learned from the popularity of AWS)
  • Select from the online Image Gallery or upload a Virtual Hard Disk (.vhd)
• Web-site hosting that scales flexibly
• VPN support for private virtual network creation
• New cache clustering capability
• A nice new management portal (image below) and command-line admin tools

One additional piece of information I noticed that looked quite helpful was the ability to update web-sites by just uploading the modified files. A seemingly small detail, but one that will be appreciated by many, I suspect.

The other event that had me looking at Azure was the fact my 3-month trial period was coming to an end. I had less that two weeks left on it, and so if I wanted our Apollonian service to stay up, I needed to work out the best way to make this happen.

Thankfully, MSDN license benefits allowed me more than enough hosting capability that I didn’t (or shouldn’t) need to pay anything additional to host the service. The first hurdle was getting my MSDN subscription to be recognised by the system – I ended up finding out it had lapsed (!), so it needed to be recreated – but after that it was plain sailing to get my subscription added to the portal.

The second major hurdle – and the reason I ended up looking at Azure 1.7 (at least that’s the SDK version) more closely – was that I couldn’t just transfer my existing service across to be under the new subscription: I actually had to remove the existing service and redeploy the distribution to Azure to make that happen. And rather than just taking the existing project and redeploying it, I thought I might as well get some practice re-enabling an ASP.NET app to work with Azure.

Which meant I inadvertently got exposed to the fact that caching – something I mentioned in this previous post, which I’d apparently left off (but have now added to) the mobile & cloud series summary – has had a serious make-over in this release of Azure. Rather than relying on a centralised cache – which can apparently work out to be quite expensive – it’s possible to carve out a percentage of each instance’s resources to devote to caching. This seemed interesting, but as my service runs on extra-small instances (I know – what a cheap-skate ;-) there wasn’t much by way of resources to carve out and dedicate to caching.

So I ended up sticking to my existing caching approach – the basic 128MB cache that comes for free with my MSDN subscription – rather than increasing the instance size and sharing the load across them. What’s a little worrying is that the new preview management portal doesn’t show information on the former cache implementation at all, which presumably means at some point I’ll have to shift across to the new distributed cache model.

Moving the deployment across from one subscription to another did involve a somewhat scary moment: I had to stop and delete the existing deployment before I could create an equivalent deployment with the same DNS name under the new subscription. This resulted in about 10 minutes of down-time, but also a few nail-biting moments before I knew whether I’d even be able to claim “apollonian.cloudapp.net” under the new subscription (to avoid having to change the various client samples I’d written). Luckily it all worked out… the moral of the story is probably to avoid switching subscriptions, if at all possible (i.e. if you have MSDN, use that from the start rather than using the free trial, first).

I know I’ll need to overhaul the implementation prior to AU – if nothing else because there’s now a Release Candidate available for ASP.NET MVC 4 – but I’m figuring I’ll see if I can wait for VS 2012 to be released and update the project to use that at the same time.

Speaking of which, I’ve just installed the Windows 8 Release Preview and put the VS 2012 Release Candidate on it. I had to update the project for the Apollonian Viewer for WinRT to use a newer version of SharpDX (version 2.2.0) for it to work on this new version of the OS, but the source-code changes from my side were trivial (I had to remove one event handler and update the SystemStyles.xaml). I’ve posted more details – including the updated project – on the last post devoted to this topic.

The new developer experience in Visual Studio 11

I'm sure several of you have formed opinions on the new look & feel of the Visual Studio 11 Beta, whether you've installed it on your existing OS or have tried it on one of the preview versions of Windows 8 (or perhaps you’ve just seen screenshots on the web). I've been using it now for a couple of weeks – on and off, admittedly – and have mixed feelings about the new monochrome styling. A lot of people have stronger views (which is basically a polite way of saying it’s fairly universally hated, judging from the feedback).

I do like the modern look of the UI, even if it’s not Metro-based… I'm someone who's quite influenced by aesthetics, although not to the extent of form over function. The logic behind the new design is to reduce the use of colour in order to more effectively draw attention to colour when it's used. Colour is now being dedicated to presenting notifications and status updates to the user.

Fair enough, I suppose, although I admit I’m having trouble differentiating the icons on the debugging toolbar, and am constantly having to check the tooltips to work out how to step over a function rather than into it. I suspect it works better at lower resolutions – as it does in the below video.

I tend not to watch “user experience” videos as a rule, preferring to spend my video-watching time on coding technologies or industry strategy. But it was very interesting to see some of the time-saving features in Visual Studio 11.

For instance, I’m thrilled that I can search the properties and methods in the Solution Explorer using Ctrl-; and then navigate using arrow keys through the results, previewing the various documents prior to opening them for editing – very cool. And the ability to peel off new instances of the Solution Explorer for specific classes, attaching document preview pages to them, is just fantastic.

Another useful point of which I’d previously been unaware is the availability of Productivity Power Tools for Visual Studio 2010, which seem to include at least some of the new VS11 functionality. As I’m still likely to be using Visual Studio 2010 alongside VS11 for some time to come, this looks well worth taking for a spin.

A simple MRU browser for AutoCAD data using WinRT

As promised in my last post, I spent some time hacking together a basic application to get a feel for what it’s like to develop inside the WinRT sandbox for Windows 8.

If you’re interested in the source code, here it is. Be warned: the code is really just to prove a concept – there’s a lot therein I’d consider sub-optimal for a production application.

If you’re more interested in seeing the application in action, but haven’t yet installed the Windows 8 Consumer Preview, then here’s a quick screencast I recorded:

A few comments on the experience of developing with WinRT:

• Thankfully it’s a familiar experience if you’ve played around with WPF and/or Silverlight, even if you’re not actually creating a .NET application.
  • I’ve only used WPF, myself, so it’s definitely a shift for me to not have full access to the file-system, etc.
• The WinRT sandbox does limit you, but it’s there for a reason…
  • Developers have to state when they’re going to access OS capabilities in the application’s manifest – and that includes the type of files the application will access from the file system – which will give better transparency for the user on what applications are doing.
  • Applications hosted on the Windows Store will be more trustable, which has to be a good thing for the platform.
  • Existing desktop applications will continue to work and co-exist with WinRT apps… I can certainly see how companion apps could be used to add value to desktops such as AutoCAD, for instance.
• It’s all about async and await.
  • I’ve had some experience using asynchronous programming with the Async CTP, so this wasn’t a big shock, but WinRT really drives you towards using asynchronous operations for many activities that might take > 50ms (apparently), even when loading local files. This will certainly help with the perception of application responsiveness, I expect.
• For testing certain UI-related operations, it really helps to have a touch-screen.
  • You can debug using the Simulator – which creates a touch-screen emulation environment from which you can load your app – but it’s just a bit more unwieldy.
  • I happened to have a touch-screen I bought some time ago that worked really well for testing semantic zoom, etc., even when connected to my Mac with Windows 8 sitting inside a Parallels Desktop 7 virtual machine.
    • That said, I had some fun recording the demo: Jing doesn’t yet work on Windows 8, so I ran it on my Mac and recorded the extents of a non-full screen Windows 8 instance, all of which threw the touch-screen’s calibration a bit. In normal, full-screen mode it worked very well, though

Overall it was interesting getting to grips with some of the capabilities of – and limitations around working with – WinRT. It’s clear that full applications will take considerable work to move across – and that many software developers won’t bother, quite understandably. Desktop applications will certainly continue to co-exist comfortably with WinRT, thankfully. That said, this new framework will enable a whole generation of applications that work across Windows 8 devices – full PCs, ARM tablets and even phones – which is all pretty compelling.

Attended the Windows 8 TechConference

I’ve just arrived home from a long day (mainly because of the 4-hour round-trip rail travel) at the Windows TechConference in Baden, Switzerland, focused on Windows 8. It was a pretty interesting day – thankfully, as I’m still a bit jetlagged from my trip to California, and I didn’t want to doze off in the lecture theatre. And yes, I’ve certainly dozed during a few lectures in my time, but not since leaving University.

The main developer-oriented session I attended – which covered writing a WinRT application to pull down Teletext into a XAML + C# application, which was just my kind of demo – taught me a valuable lesson: do not sit up front during a demo focused on Metro UI development – which tends to involve lots and lots of horizontal scrolling – especially when the amphitheatre has cinema-style seating (it was held in a cinema) and you’ve been plied with lots of free food. I nearly had to leave when motion sickness made me feel distinctly nauseous. :-S :-)

But there were some genuinely interesting takeaways from that session: Microsoft are doing a typically pragmatic job of marrying the new with the legacy. Windows 8 will provide an interesting environment for applications, with legacy “desktop” applications (whether using native and/or managed code) will happily co-exist with code running inside the WinRT sandbox. I’m itching to install and play with Windows 8 preview (now that that the Windows 8 consumer preview is available, I expect it’s better to go with that), using the Visual Studio 2011 Beta to build my first Metro-style app.

Another comment on the XAML + C# session: all the coding during that session was performed on a tablet device – albeit one with an external keyboard and mouse – which was pretty cool. A lot of comments were made around the slate’s array of external ports and extensibility options, which was a clear dig at the iPad’s lack of them.

And it was interesting to see every tablet demoed during the day – at least that I saw – had Autodesk SketchBook Express installed (even if it wasn’t shown running), which was either an indication of how cool the app is (and it has been receiving good press, it seems) or how little competition it has on the Windows 8 platform (it is early days, after all). All hot on the heels of SketchBook Ink’s coverage during the iPad 3 launch last week, which came as a surprise to lots of us at Autodesk, too.

There was a fun session talking about the Metro design language, and how it was inspired by bauhaus (being reductionist and functionality-focused), Swiss typography (clearly a crowd-pleaser, here) and motion design.

The other interesting developer-oriented session was a deep dive into WinRT, which showed some of what was going on under the hood in Windows 8. I have a better understanding of the Windows 8 architecture, at this stage, but still need to look into it more deeply (which I expect to share via this blog).

Copying & pasting code from this blog into Visual Studio

I’ve been meaning to post on this topic for some time, and a recent comment reminded me to do so.

As many of you will have noticed, when you do a straight copy & paste of code from this blog into Visual Studio, it comes with unwanted line feeds.

For instance, taking some recently posted code using Internet Explorer 9:

And pasting it into VS2010 results in unwanted linefeeds in the code:

Less than ideal, to say the least. The reason this happens is probably the way the HTML gets formatted by the CopySourceAsHtml tool I use to get the code from Visual Studio into Windows Live Writer (my preferred blogging tool).

When posting code to his blog, Jeremy Tammik runs a Python script to edit the clipboard contents and minimise the code created (replacing hardcoded styles with CSS, adjusting the inclusion of linefeeds, etc,.), but I prefer not to: as far as it goes I’m actually pretty happy with the way the code comes across into the blog using CopySourceAsHtml, and don’t see the need to introduce an additional step in my posting process.

But I certainly acknowledge the ugliness of the linefeed issue when trying to reuse the code. To that end, this post lists three options for getting code from this blog cleanly into Visual Studio.

1. Copy using Google Chrome

This is, in many ways, the simplest solution I’ve found: if you copy the code from this blog using Google Chrome, it comes across into Visual Studio without the additional whitespace. This is a nice option as it’s simple and free. But obviously means you have to install an additional browser, if you don’t already have it.

I happen to have Chrome installed in OS X on my system, but as Parallels Desktop shares a clipboard with OS X, it works well pasting into Visual Studio for me, too:

2. Use ClipboardFusion to search for & replace double linefeeds

ClipboardFusion from Binary Fortress Software is a free tool (with optional subscription pricing for ClipboardFusion Online) that allows you to “scrub” your clipboard. This may mean removing HTML tags, or some other activity. In our case we want to perform a simple search & replace operation: we want to replace double-linefeeds with single ones.

Once the tool has been installed, you can edit the ClipboardFusion settings, to specify the desired “Text Replace” operation, to match “\n\n” and replace it with “\n”:

You can set the scrubbing to occur on “double-copy” (if you copy the same text twice it scrubs), which is a nice feature:

Then, when a scrub occurs, you will get notified via a balloon (unless you prefer to opt for a sound being played, etc.):

3. Use ReSharper in Visual Studio

Thanks to Kerry Brown for this suggestion.

ReSharper from JetBrains is a productivity tool for Visual Studio that – among other things – helps with formatting and refactoring code you copy from the web. This is not a free option – outside the 30-day evaluation period – so do be aware of that.

One possible advantage of using ReSharper is its ability to apply various rules when reformatting your code – pretty handy if you have (for instance) a standard column width of >70 (I use 70 characters per line to get code to fit my blog). You can also set up and deploy such standards acorss your programming team fairly easily, from what I can tell.

You can then run ReSharper –> Tools –> Cleanup code… (with a custom profile just specifying you want to reformat, should you wish) and your code will get reformatted.

Conclusion

Any of these three options seem valid, depending on your preference: Chrome is a straightforward option, but may mean browsing with another tool. ClipboardFusion is handy, but means some installation (and the need to live with the risk of it scrubbing your clipboard when you’d rather it didn’t). ReSharper gives you a lot of power to impose standards upon your code (and code you find from elsewhere), but will take time to set up, and doesn’t come for free.

I assume there are other options out there… if you have one to suggest, please post a comment!

Incidentally, I'm going to be on vacation in Egypt for the next two weeks. I've queued up a few posts to keep things moving, while I'm away, but please don't expect me to respond promptly to comments (despite me having asked people to post comments in this very post). I'll do my best to catch up quickly on my return.

No source available when debugging an AutoCAD plug-in

Given the fact AU 2011 is quickly approaching, I decided it was time to dust off my Kinect-related code and getting it working with the Beta SDK from Microsoft Research. Part of the reason I haven’t been able to do this sooner is that my primary work machine is currently a MacBook Pro running Windows 7 via Parallels, and the Microsoft Kinect driver currently does not support working inside a Virtual Machine.

I did start to try to get my previous implementation using OpenNI + NITE to work on this system, but as it uses the nKinect component that is currently (and will probably remain) dependent on the 32-bit versions of the OpenNI/NITE SDKs, I couldn’t easily get that working with my 64-bit AutoCAD 2012 installation. Ho hum.

Anyway, thankfully our IT department came to the rescue and loaned me an old system, re-built with 32-bit Windows 7, so that I should now be in a position to demonstrate integrations using both the OpenNI and Microsoft SDKs inside AutoCAD during my Kinect-related session at AU. Which also means I’ll be carrying two machines with me to Las Vegas, but so it goes.

I now have a basic implementation using the Microsoft Kinect SDK working inside AutoCAD, but it’s not generating the point cloud as I’d expect it to. Which means I need to debug it. Unfortunately, the breakpoints I’ve set in my jig – while they appear to get hit while executing my command inside AutoCAD – do not lead to source code being displayed inside VS 2010:

[To help people find this post via a search engine, here the text in the dialog: “No Source Available. No symbols are loaded for any call stack frame. The source code cannot be displayed.”]

It took me some time to work out how to resolve this. I searched on the web and found a number of suggestions that I hoped would help:

• Enable “Just My Code” in the Debugging options
• Disable “Require source files to exactly match the original version”, too
• Set “Automatically load symbols for all modules”
• Clear the symbol cache
• Launched the debug session with my left hand, while crossing fingers on my right hand and whistling the Imperial March from Star Wars

[In case you’re wondering, the last approach didn’t seem to have any less effect than any of the others: the source was still not found. :-( :-) ]

Then, feeling somewhat foolish, I remembered the most likely source of the problem.

AutoCAD still uses fibers, which can cause a problem when debugging. I’ve known about this issue for some time, but had worked around the problem on my main system, and so no longer his the debugging issue.

The workaround is to set the NEXTFIBERWORLD system variable to 0, and then restart AutoCAD. You can check the current value of FIBERWORLD, to see what it is prior to doing so, of course:

Command: FIBERWORLD

FIBERWORLD = 1 (read only)

Command: NEXTFIBERWORLD

Enter new value for NEXTFIBERWORLD <1>: 0

Command: QUIT

You have to restart for FIBERWORLD to be updated, as switching fiberless operation on or off is not something that can be done on-the-fly.

Now this approach is really something that you should enable and use sparingly: while we expect to make AutoCAD work perfectly without fibers, at some point, this is currently an unsupported mode of operation and can cause problems with WPF, in particular. In fact, one major issue I had on my system (one I only just realised was related to this) was that my ribbon would simply not work: while I could switch ribbon tabs and even successfully use ribbon customizations such as TransTips and the expanding textbox control, the actual commands selected from the ribbon were not getting executed. A problem which went away when setting NEXTFIBERWORLD back to 1 and restarting.

For ADN members interested in a bit more background on this topic, see this DevNote and an article in this newsletter edition.

Right – now that I can at least see what’s happening in my code, I’d better go fix it and get it ready for posting. :-)

Debugging AutoCAD .NET projects using Express Editions

Visual C# Express and Visual Basic Express can be used successfully to build .NET applications for AutoCAD: in fact many developers use these tools to do so. One long-standing issue with using these tools with AutoCAD relates to debugging: the ability to debug using an external application is not directly exposed via the user interface Visual C#/Basic Express, which – as AutoCAD implements a plug-in hosting framework for .NET Class Libraries (or DLLs) – makes life complicated.

The workaround for addressing this issue has been documented in this previous post and also on the ADN web-site, but thankfully this manual approach of modifying the .vbproj.user/.csproj.user file is no longer needed: the latest version of the AutoCAD .NET Wizard (6.7 MB) (which can also, of course, be found on the AutoCAD Developer Center) takes care of this automatically.

The reason this download is a bit bigger than in the past is that Stephen Preston has recorded a 5-minute screencast to accompany the use of this new version of the Wizard. In it, he explains the new configuration option pointing to the AutoCAD executable which enables the Wizard to populate the debugging information appropriately in the .user files it creates:

If you’re interesting in learning more, please download the Wizard and take a look at the accompanying screencast.