This is the second part of my journey to creating an application using WPF, wrapping the Renderer demo I made earlier. You can find the first part here.
Subconscious Intentions
So, initially in this post, I was going to introduce the concept of the model-view-viewmodel, and code inline and code behind. Or at least, how I understand them. Yet due to recent activity, that will have to wait till the next post.
The great thing about writing these blog posts is that in order for me to seem like I know what I’m doing, I have to do the research. I’ve always been taught that during an exam, always answer the question as if the examiner doesn’t know anything about the subject bar the basics. This way, you should answer the question in a detailed and chronological order, thus making complete sense and gaining full marks. In a way writing these posts are quite similar. Sure, I may have broken the rule more than a few times, especially when I’m rushing myself, but I try to explain the topics I cover in enough detail for others than myself to understand it. After all, although I am writing this primarily for myself to refer back to for when I get stuck, it’s nice to know that others are benefiting from this blog too.
It’s not because I haven’t done the research that I can’t bring to the table what I know (or seem to know) about the model-view-viewmodel, code inline and code behind. It’s because during the research and much tinkering around, that I thought I should cover the main drive for using WPF in the first place, and that is to incorporate an OpenGl control.
From Scratch
So a couple of weeks ago, I did actually manage to create an OpenGl control, and place it inside a WPF form. The way I did this was a bit long-winded compared to how I used to, by creating it in a Win32 form. Instead of using the SimpleOpenGlControl provided by the Tao framework, I went about by creating the control entirely from scratch.
For this, I could have done all the research, and become an expert at creating the control manually. But that simply wasn’t my intention. Luckily for me, the examples provided by Tao included the source code ,and a quick copy and paste, I more or less had the code ready and waiting to be used.
One thing I am more aware of now is that you need two things, a rendering context and a device context. The rendering context is where the pixels are rendered; the device context is the intended form for where the rendering context will sit inside. Of course, the only way to interact with these are using their handles.
To create a device context in the WPF application, I am using a Windows Forms Host. This allows you to host a windows control, which we will use as our device context. The XAML code for this is relatively simple. Inside the default grid, I have just inserted the WindowsFormsHost as the only child element. However, for the windows control, I have had to take from a namespace other than the defaults provided. To declare a namespace, declare the alias (in this case I have used wf, shorthand for windows forms) and then follow it with the namespace path. Inside the control, we are also going to use the x namespace. Using this, we can assign a name for the control, and thus allowing us to retrieve the handle to use as the device context.
<Window x:Class=“OpenGlControlInWPF.Client”
xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentation”
xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml”
xmlns:wf=“clr-namespace:System.Windows.Forms;assembly=System.Windows.Forms”
Title=“Client” Height=“480″ Width=“640″ WindowStyle=“SingleBorderWindow”>
<Grid ClipToBounds=“True”>
<WindowsFormsHost ClipToBounds=“True”>
<wf:Control x:Name=“control”/>
</WindowsFormsHost>
</Grid>
</Window>
With the form done, we can now dive into the code in the C# file attached to the XAML file. It is here where we create the rendering context, and attach it to the device context. I’m not really an expert on OpenGl at all when it comes to this kind of thing, so I’m not going to show the full code. If you’re really stuck, the best place I can point you to is to look at NeHe’s first lesson, making an OpenGl window. If you’re using the Tao framework and you installed all the examples, the source code should come with it.
The WPF interaction in the C# code is very minimal. All we need to do with the XAML file is to retrieve the handle associated with the control we declared beforehand. This is done simply by using the name we gave it in the XAML and letting Tao do the rest. We hook this up to retrive a rendering context, and then we show the form.
Gdi.PIXELFORMATDESCRIPTOR pfd = new Gdi.PIXELFORMATDESCRIPTOR();
// use this to create and describe the rendering context – see NeHe for details
IntPtr hDC = User.GetDC(control.Handle);
int pixelFormat = Gdi.ChoosePixelFormat(hDC, ref pfd);
Gdi.SetPixelFormat(hDC, pixelFormat, ref pfd);
IntPtr hRC = Wgl.wglCreateContext(hDC);
Wgl.wglMakeCurrent(hDC, hRC);
this.Show();
this.Focus();
All there is left to do is to go into the OpenGl loop of rendering the scene at each frame. Unfortunately, because I am used to the SimpleOpenGlControl provided by Tao, I’ve never needed to go into it whilst I’ve been on placement. All I had to do was to call simpleOpenGlControl.Invalidate() and the frame would automatically refresh for me. As a result of this, I decided to place the draw scene method in a while(true) loop so the rendering would be continuous. And true to my thoughts, I knew this wouldn’t work. As a result, the loop was “throttling” the application when running – I was unable to interact with it because all the runtime concentrated on rendering the scene – there was no interrupt handling so pressing a button or typing a key didn’t have any effect whatsoever.
I did try to look for answers to the throttling, and I stumbled across something else. Another solution to hosting an OpenGl control in WPF.
The Better Solution
Going back to the first post of this multi-part blog, you might recall I am using a Canvas to host the OpenGl control. I found this solution only a couple of days ago, due to a recent post on the Tao forums. It uses this canvas in the C# code and assigns a WindowsFormsHost. This in turn is assigned a SimpleOpenGlControl. A SimpleOpenGlControl! This means that I am able to use all the abstractions, methods and properties that the SimpleOpenGlControl has to offer without having to manually create my own.
First of we have to assign the canvas a name in the XAML code so we can reference it in the C# counterpart.
<Grid Background=“AliceBlue”>
…
<Border Grid.Row=“0″ Grid.Column=“0″ Background=“Black” BorderThickness=“1″ BorderBrush=”Navy” CornerRadius=“5″ Margin=“6, 6, 3, 3″>
<Canvas ClipToBounds=“True” Margin=“2″/ x:Name=“canvas”>
</Border>
</Grid>
The C# code for creating the SimpleOpenGlControl is short and sweet. We create the WindowsFormsHost, attach a newly created SimpleOpenGlControl and attach the whole thing to the Canvas. Here is the entire code for creating this.
namespace OpenGlWPFControl
{
using System.Windows;
using System.Windows.Forms.Integration;
using Tao.Platform.Windows;
/// <summary>
/// Interaction logic for Client.xaml
/// </summary>
public partial class Client : Window
{
public Client()
{
InitializeComponent();
this.windowsFormsHost = new WindowsFormsHost();
this.simpleOpenGlControl = new SimpleOpenGlControl();
this.simpleOpenGlControl.InitializeContexts();
this.windowsFormsHost.Child = this.simpleOpenGlControl;
this.canvas.Children.Add(windowsFormsHost);
}
private WindowsFormsHost windowsFormsHost;
private SimpleOpenGlControl simpleOpenGlControl;
}
}
Now we have the SimpleOpenGlControl set up, we simply just add the event for rendering and we’re nearly done. There is one problem however, and that is the windows forms host does not know what size to take. We add an event for when the canvas is resized to update the windows forms host size too.
public Client()
{
…
this.simpleOpenGlControl.Paint += new PaintEventHandler(simpleOpenGlControl_Paint);
this.canvas.SizeChanged += new SizeChangedEventHandler(canvas_SizeChanged);
}
void simpleOpenGlControl_Paint(object sender, PaintEventArgs e)
{
// do your normal opengl drawing here
this.simpleOpenGlControl.Invalidate();
}
void mainCanvas_SizeChanged(object sender, SizeChangedEventArgs e)
{
this.windowsFormsHost.Width = this.canvas.ActualWidth;
this.windowsFormsHost.Height = this.canvas.ActualHeight;
}
A Revelation To An Even better Solution
So I said I was going to talk about other topics before delving into my journey of placing an OpenGl control inside a WPF application, and that’s because of what I found myself accomplishing last night. In the first blog post of this multi-part series, I found myself using a Canvas to hold a Windows Forms Host, and in turn, to parent a SimpleOpenGlControl. Yet with further understanding of WPF, a revelation came. The reason I was unable to insert a SimpleOpenGlControl directly into the application beforehand was because I wasn’t entirely aware of namespaces in XAML. Soon after finding more about them, I find I am able to access the SimpleOpenGlControl by referencing Tao, and hence solving all the background work the C# had to do.
<Window …
xmlns:tao=“clr-namespace:Tao.Platform.Windows;assembly=Tao.Platform.Windows”
…>
<Grid Background=“AliceBlue”>
…
<Border Grid.Row=“0″ Grid.Column=“0″ Background=“Black” BorderThickness=“1″ BorderBrush=“Navy” CornerRadius=“5″ Margin=“6, 6, 3, 3″>
<WindowsFormsHost Margin=“2″ ClipToBounds=“True”>
<tao:SimpleOpenGlControl x:Name=“simpleOpenGlControl”/>
</WindowsFormsHost>
</Border>
</Grid>
So the only thing extra that to add to this is the event for rendering, which I included before. I can omit the need for having to resize the canvas, partially because there is now no canvas, and also because the WindowsFormsHost ClipTobounds property is true.
In the next part of this series I will hopefully be touching upon what I intended on touching upon in the first place, the model-view-viewmodel pattern.
.gif "Publish/Subscribe")
