dwmkerr.com

I have written an article that describes commanding in WPF, Silverlight and WP7 in detail. It is on the CodeProject at: http://www.codeproject.com/KB/WPF/consistentmvvmcommands.aspx It uses the latest version of Apex (version 1.2) which will be released formally shortly. Enjoy!

The latest cut of the Apex Code (http://apex.codeplex.com/SourceControl/changeset/changes/6701) contains a very cool new feature - Asynchronous Command Objects. An Asynchronous Command is a ViewModelCommand - the standard object used in Apex for commanding. However, what is different about this function is that it runs Asynchronously. One of the problems with running a view model command asynchronously is that generally the view model properties cannot be accessed - as they're created on a different dispatcher.

It's been a long time coming, but the first Beta of SharpGL 2.0 is finally here! The Beta is on CodePlex at: http://sharpgl.codeplex.com/releases/view/74704 This includes the binaries, example applications and full source code. Some of the more exciting features are: Full hardware acceleration OpenGL Extensions Full core functionality up to OpenGL 4.2 Native WPF Control Below is a screenshot of SharpGL in a WPF application:       And here's a link to a new CodeProject article describing how to use SharpGL in a WPF application:   http://www.

My Solitaire and Spider Solitaire in WPF article is in two CodeProject competitions this month. The article is at: https://www.codeproject.com/Articles/252152/Solitaire-and-Spider-Solitaire-for-WPF If you think the article is worthy of a vote, then please go to the voting page for either of the two competitions! Best C# Article: http://www.codeproject.com/script/Surveys/VoteForm.aspx?srvid=1209 Best Overall Article: http://www.codeproject.com/script/Surveys/VoteForm.aspx?srvid=1212

One of the most exciting new features in the forthcoming SharpGL 2.0 (which was actually planned for 2.1 but has been moved to 2.0) is the facility to do OpenGL drawing in a WPF control. This isn't done via a WinFormsHost (which has unpleasant side-effects due to Airspace, see http://msdn.microsoft.com/en-us/library/aa970688(v=VS.100).aspx) but actually via an Image in a WPF UserControl. What does this mean? Well it means that when you use the SharpGL.

There are only a small set of the core OpenGL functions that can be imported via p/invoke - the majority of OpenGL functions are actually extension functions which are supported only on specific video cards. OpenGL offers a function called wglGetProcAddress which can return the address of a named function - but how do we deal with this in the managed world? Here's a brief description of how it's handled in SharpGL.

Today I was looking through some fairly old source code in a large solution, large in this case is ~300 projects and about 1 million lines of code. Parts of the code base are very old - at some stage a decision was made to disable warning C4996. The problem I came across is reduced to its most simple form below: // AnalysisExample.cpp : An example of how static analysis can help.

I have recently come to discover the ISupportInitialize interface and found that it is extremely useful when developing more complicated WinForms controls. Here’s the link to the interface on MSDN: ISupportInitialize - here I’ll describe how it can be useful. The Problem I have a fairly complicated WinForms usercontrol called 'OpenGLControl', which allows OpenGL commands to be used to render 3D scenes in a C# WinForms application. The control has properties which are interdependent to each other.

It took a bit of working out, but finally SharpGL can support hardware acceleration. Previously, all rendering in SharpGL was done to a DIB Section, the result of this would be blitted to the screen. Much playing around has shown that in fact this is problematic - rendering to DIB sections can never be hardware accelerated. To hardware accelerate rendering, the rendering must be to a window or a pixel buffer.

SharpGL 2.0 has no P/Invoke - all native functions are called by a C++/CLI class library (OpenGLWrapper if you're getting the code from CodePlex) which calls functions directly. This means there's no more importing of PIXELFORMAT structures and so on. The thinking behind this was that a C++/CLI wrapper is faster than P/Invoke for a talkative API like OpenGL - but is this actually the case? In my new article on the CodeProject I investigate the performance differences between these two methods.