Through the Interface: A simple MRU browser for AutoCAD data using WinRT

Kean Walmsley

May 2015

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


« Extracting MRU information from AutoCAD using .NET | Main | Updated AutoCAD + Kinect for Windows samples »

March 19, 2012

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.

blog comments powered by Disqus


10 Random Posts