Tomorrow is Thanksgiving here in the US, a day of commemoration of the first Pilgrims giving thanks to God for their successful harvest and settlement and the fact that they hadn't been eaten by the natives. 383 years later we're celebrating our first Thanksgiving, and also give thanks to God for our successful settlement here and the fact we also have not been eaten by the natives! Happy Thanksgiving, and thank you so much, to all those who've made us feel so welcome over the last two months since arriving here.

I'm very fond of the concept of Adobe Acrobat - being able to share a single PDF file that contains a non-volatile representation of a document, that you can view on-screen or via a printer without worrying about formatting issues caused by different fonts, operating systems or printer drivers. But I'm getting increasingly infuriated by the implementation: amongst other things, by the slow loading times and increasing bloat in the Reader software. I frequently have to wait 10-20 seconds for the application to load when all I wanted to do was view a single page. I don't want to complete an electronic form, verify a digital signature, print to a remote location, or manipulate a digital photo, so why do I have to wait for nearly 20 plug-ins to load before I can use the document. This is simply poor application design: most of these plug-ins could be loaded as a background task for starters, and the interface doesn't even offer a way to disable them.

As I browsed around the directory structure under C:\Program Files\Adobe\Acrobat 6.0\Reader, I discovered there's a subdirectory called Optional that contains a readme with the following text: "Put unused plug-ins in the optional directory." Super, I thought and promptly moved all the plug-ins. Hey presto - Acrobat Reader immediately transformed itself back into the speedy, lightweight tool that I loved back in version 3.

Searching around the web to see whether this was a safe thing to have done, I discovered this post from Darren Norton over a year ago with the same information. So I'm behind the times, certainly, but I suspect I'm not alone in having missed this "feature". I posted a quick mail to the "Cool Stuff" distribution list internally within Microsoft and received a number of replies from delighted colleagues, so I thought I'd share it here.

In the second developer preview release of Longhorn, distributed in May at WinHEC (build 4074), the Avalon team included a whole bunch of new 3D functionality. For the first time, Avalon surfaces could contain not just 2D shapes and brushes, but also 3D meshes that could be rotated, transformed and animated, with custom camera and lighting options.

In the new Community Technology Preview we've just released, a number of the 3D classes have been refactored, which of course means breaking changes to anything developed for the WinHEC build. That's the price you pay for being a "bleeding-edge" adopter, of course, but I wanted to at least highlight the major changes to hopefully help people sed their way through. This isn't exhaustive, but I'll update it if someone hits another change they need help with.

• The namespace has moved from System.Windows.Media3D to System.Windows.Media.Media3D;
• The ViewPort3D class has now changed to Viewport3D (notice the change in capitalization);
• PerspectiveCamera and other cameras have now become immutable by default: add StatusOfNextUse="ChangeableReference" to the element if you want to modify it programmatically after instantiation. The same is true of Viewport.Models;
• The MeshPrimitive3D class has now become GeometryModel3D, and MeshPrimitive3D.Mesh is now GeometryModel3D.Geometry;
• The Mesh3D class is now MeshGeometry3D;
• Model3DCollection has now become Model3DGroup.

Many of these changes seem arbitrary in isolation, but they improve FxCop correctness and consistency with the 2D namespace. Now is the time to make these changes before we hit a public beta: usually nobody finds out about this kind of thing, but the more technical preview and CTP releases we deliver, the more you're able to see our dirty laundry :-)

Thanks to Daniel Lehenbauer, one of the SDEs on the Avalon 3D team who helped me migrate my own samples across and was the source for most of this knowledge. He's also written some nice samples that are far better than my own attempts so far.

For those of you who are starting to experiment with Avalon for the first time as a result of the recent Community Technology Preview release, I thought it would be helpful to put together a quick guided tour of the SDK reference documentation and overviews to give you some sense of the major feature areas and technologies worthy of further investigation. Unfortunately, the online WinFX SDK is still under construction and as a result the contents list doesn't provide a hugely intuitive overview of where to start looking. This guided tour is based on an original list put together by Pablo Fernicola and will help you get to know Avalon better. My suggestion is that you use the links below as launch points for your own exploration: follow a trail to understand an area, then come back to this entry and move on to the next section.

1. Start off by reading the introduction of the November CTP article to understand the vision and goals of Avalon.
2. The Avalon layout engine controls the positioning and layout of Avalon controls. Find out more about how panel components influence this, and understand the difference between different layout types such as dock, flow, stack, grid and canvas.
3. Get to know the Avalon controls from Button to VerticalScrollBar. Then learn how you can use control styling to entirely change the look and feel of a control without modifying its behaviour.
4. The powerful data binding services in Avalon make it much easier to hook up control properties to underlying data sources, whether an in-memory array or a bound data set.
5. Avalon doesn't just limit you to controls: it includes rich 2D vector drawing capabilities, including brushes, shapes, transformations, effects, and animations.
6. You can also create and manipulate 3D vector objects on a display surface, with the added benefit of custom camera views and lighting effects.
7. Avalon isn't just about screen rendering. Read this article to find out about the document services for providing fixed- or adaptive-flow layout, and find out about the Avalon document container.
8. One of the focal areas for Avalon is powerful typography and rich screen reading experiences. Avalon has built-in support for ligatures, kerning, composite fonts, font embedding, subpixel character placement and text animation.

Hope you find this useful in your Avalon explorations!

Although the .NET Framework contains a comprehensive catalog of classes that encapsulate much of the operating system, real-world applications often need to go beyond the Base Class Libraries and interact directly with the underlying Win32 APIs, either because a managed class doesn't exist for the required method or because it doesn't go far enough. If you're integrating deeply with the shell, want to interact with other windows, or just want to use a service such as fax or RAS, then you'll be getting to know the vagaries of Platform Invoke, the technology which allows you to cross the managed / unmanaged boundary.

The problem is that declaring external functions to be accessed via P/Invoke is a somewhat arcane science, with pitfalls ranging from string mutability to struct layout. Adam Nathan has written a brilliant book that acts as a comprehensive reference to P/Invoke and COM interop, but its sheer size can be daunting for someone who just needs to make a couple of simple calls.

I was pleased therefore to be reminded in a recent email thread of the existence of PInvoke.NET, a wiki that provides sample code for many of the external signature declarations you might need. It comes with C# and VB samples, along with documentation or example code for the majority of well-used calls. Check out the User32, Gdi32 and Kernel32 sections for the majority of the Win32 APIs, or simply search for the API function you're looking for. Lastly, there's even a Visual Studio Add-in so you don't even need to leave the comfort of your IDE to take advantage of the interop help given. The site is a little weak on navigation - it would be nice if there was more "discoverability" of the various APIs so that you didn't need to know in advance what you were looking for, but it's a valuable asset to any VB or C# developer's toolbox.