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