The Windows Presentation Foundation (short WPF) is coming, and it will replace all Windows UIs as we know them today.

This means that no developer can ignore this technology. This article provides an introduction to WPF both from a general point of view as well as from a Visual FoxPro specific angle.

Windows great strength is its graphical nature. Users love it, and against the predictions of many developers who care more about the “guts” of an application, Windows easily won out over the non-graphical DOS world. In fact, today, all major operating systems in the client-space have graphical user interfaces. This makes sense considering that the only part of an application the user can ever “touch” is its interface. Clearly, personal computers would not be nearly as popular without graphical web pages and features such as digital photography.

Almost all visual output created by Windows today is based on a standard called “Graphical Device Interface” or short: “GDI”. GDI was a huge step forward from the cumbersome approach to computer graphics DOS provided, where graphics were both extremely slow and primitive, or had to be tailored for individual hardware devices (including printers). GDI solved this problem by providing an abstract layer on the operating system levels that applications could talk to, to create graphical output such as lines or filled rectangles, or even more complex things such as text rendered in a specific font.

Practically all output generated today is based on GDI. For instance, when Visual FoxPro draws a menu or a button on the screen, it uses GDI either directly or through additional APIs such as the Windows Themeing API. VFP pretty much travels down its own path in creating GDI-based UIs (which has to do with its legacy of cross-platform features such as Mac support). Other environments provide standardized APIs on top of GDI. C++ developers for instance use the MFC (Microsoft Foundation Classes) to create interfaces with standard controls such as buttons, rather than hand-drawing a button pixel by pixel. The MFC approach is also used by other development environments, but not by Visual FoxPro. .NET applications of the 1.x to 2.0 generation use “Windows Forms” to create Windows applications. This is a standardized set of controls (in their use very similar to creating an application in VFP) that is also based on GDI, or - more accurately - a feature enriched version of GDI called “GDI+”.

The Paint is Fading

Not all is well in GDI land. GDI has been created a long time ago. We are talking “Windows 3.x” and older. When GDI was originally designed, it was designed for computers that are hardly comparable to today’s machines. Screen resolutions were lower. Graphics accelerator cards were unheard of. 16 colors were a great improvement over monochrome displays. Nobody was reading mass text in web browsers or word processors, so creating interfaces with great readability was not a big concern. Multimedia was not even a twinkle in Bill Gates’ eye.

Today’s expectations are different. We expect smooth, high resolution UIs. We expect user interfaces of high quality with fonts that are easy to read even after hours of work. We expect seamless media integration. We expect advanced data visualization to cope with the amounts of data modern applications collect and maintain. We expect exciting experiences on web sites. Software providers are attempting to differentiate themselves from their competition by providing more intuitive, more professional, and more polished user interfaces. We expect to communicate important details and nuances to users in a natural and intuitive way. We generally expect to improve the still relatively primitive ways of communicating with the user by providing next generation interfaces. Needless to say, that us developers and UI designers expect to fulfill these expectations with as little effort as possible.

The short version of the long story is that GDI does not allow us to fulfill those expectations.

The list of reasons is long. Too long perhaps for this article, but I will investigate a few of them. One of the core problems is that GDI is a pixel-based rendering technology that performs all its operations on the CPU. In other words: An application issues a command - such as drawing a line on the screen - and the GDI API processes this command pixel by pixel just like any other application. This raises a number of issues. For one, the number of pixels displayed by a typical display today is very large. I am writing this article on a dual monitor system with each monitor sporting a resolution of 1600x1200 pixels, resulting in just under 4 million pixels needing to be managed and refreshed by the rendering API. With each pixel being a 32bit value to support “true color”, the CPU ends up doing a lot of work.

So it seems like we are running high screen resolutions today (especially compared to the Windows 3.x-typical 640x480 which had just over 300,000 pixels to worry about), but the trouble is, 1600x1200 is really nowhere near where we want to go! A display like the one I am using to write this article usually features a pixel density of about 96dpi. 96dpi is not a lot. For print media, we usually say that 300-600dpi is the absolute minimum for reasonable quality. 1200dpi would be much more desirable. You may notice that the magazine you are reading this very moment features font that is much more readable than text on a web site. That is because of the higher dpi. The near-term goal for a computer screen has to be that magic 300dpi barrier. (For an in-depth discussion of screen resolutions, visit my blog at www.MarkusEgger.com/Blog). This means that within a single inch, there are a lot more pixels.

If my monitors actually were 300dpi displays, they would have a resolution along the lines of 5000x3500 pixels or so. Between my two monitors, we would now have some 35 million pixels to manage. Clearly, this is not what GDI was originally designed for. And going to 300dpi is not the ultimate goal by any means. To truly provide high display quality, we will ultimately have to go even higher. A core problem with these numbers is that the number of pixels rises much faster than processing power goes up. Using GDI, we would put more and more burden on the CPU, leaving a smaller percentage of CPU power to the “useful” things, such as running an application’s business logic, until we would ultimately use all the CPU power just for the UI.

When I talk about high-resolution displays, I am not talking about making things smaller. I am simply talking about using more pixels to render things of the same size. For instance, a standard 8-point font is 8/72 of an inch tall. At least it is supposed to be. In Windows, it ends up as just under eight pixels tall. This is hard to render, so Windows generally uses a font size of 8.25 points, which maps to 8 pixels. (Points are not the equivalent of a pixel… a pixel is supposedly 1/96th of an inch, while a point is 1/72nd of an inch). Today, Windows really just guesses at the resulting size of fonts, because depending on the size of your monitor and its exact pixel density (which can vary between something like 72dpi and 130dpi), 8 pixels will end up at a different size. What we really want is for an 8 point font to be 8/72nd of an inch tall, and if the display happens to be 300dpi, than 33 vertical pixels should be used to render that font. So in short: Everything would be the same size as we know it today, but it would be super-crisp.

There is a significant problem with this though. To render an 8.25 point font at anything but 8 pixels, Windows would have to support a good scaling algorithm. But as everyone knows who ever tried to use large fonts in Windows, this does not work well. Similarly, a Visual FoxPro form that works well in a 1024x768 resolution may look tiny on a 1600x1200 display, and there really is no good way to scale the form up to appear bigger. This is why people generally do not go to high res displays today. Things simply get too small to read. The trouble is that a pixel-based system like GDI does not lend itself well to scaling to different sizes. You want that Word toolbar to appear 50% larger? With GDI you are basically out of luck. A fact that is painfully obvious when you try to zoom into a web site, resulting in a complete layout mess. Clearly, a better approach to scaling UI components is needed.

Graphical Apartheid

Performance is an issue with GDI+ even with today’s screen resolutions. Although it often amazes me how fast GDI actually is, it simply is too slow to create 3D UIs, animations, full-motion videos, and other advanced UI concepts we have just begun to experiment with. For this reason, Windows provides a second approach to creating graphical output: DirectX.

DirectX - in particular Direct 3D, DirectDraw, and DirectShow - is a high performance graphical API that provides more direct access to the graphics hardware that today is present at some capacity in almost every PC. DirectX is the technology that allows us to play games or to watch videos on a web site. It also sports some features that lend itself very well to creating advanced data visualizations for business application. However, DirectX is not easy to use. It used to be reserved for C++ developers, although .NET developers also have a pretty good way to use it. Developers using environments such as Visual FoxPro or Visual Basic up to version 6.0 do not have a feasible way of using DirectX.

The trouble is that DirectX and GDI do not play well together. It works well to run a game in full-screen mode, but one could not write a game where a 3D world is done in DirectX, but the score board in the corner of the world is drawn with the simpler GDI API. The two just do not mix. The problem is also obvious when you watch a video on a web page. Try this: Start the video and then start moving the browser window (or the media player window if that’s where the video plays). The effect you will see is the window moving and the video lagging behind, moving around as if it was connected to the main window with a bungee cord. If you have a dual monitor system and move the window to a different monitor, chances are you will lose the video altogether. Another example I really like has to do with Tablet PC development and support for digital ink. Using the Tablet PC API, it is very easy to support pen input on all GDI based UIs (there are several articles on my web site about this, including one specific to VFP). It is also doable, although much harder, to support digital ink in DirectX UIs. However, if would not be feasible to ink from a GDI UI over a DirectX UI, such as a video.

As a result of this difference between the two major Windows UI technologies, constructs such as buttons that have a video or a 3D animation as their caption are not feasible. Similarly, documents with integrated multimedia content do not work very well, so people restrict multimedia to small snippets, such as a video on a web page, but there is little significant use of multimedia beyond that. Where are all the manuals with advanced training videos or animations in every paragraph? Where are the web sites that feature advanced product visualization so you can actually tell what the product you are about to buy looks like? Where are the professionally designed windows with a subtly animated background that looks so good (yet hardly noticeable) on consumer UIs such as the TiVo interface?

A WPF Face-Lift

To solve many of these problems and to move towards next generation user interfaces, Microsoft is gearing up for the first revamp of Windows UI technology since the dawn of Windows-time. Out goes the GDI approach (although it will be supported for backwards compatibility for the foreseeable future) and in comes the Windows Presentation Foundation (a.k.a. “WPF” formerly codenamed “Avalon”).

WPF represents a new way of rendering user interfaces. It does not concern itself with pixel drawing. Instead, all WPF elements are based on graphical “primitives” such as lines, rectangles, fonts, and even not so “primitive” elements such as textboxes, buttons, videos, or 3D models. All these elements are intrinsically based on vector graphics, which means they can be displayed at any resolution or size without losing quality. They nice thing is that they can all be combined in any desired way. If a component can render a video or a 3D model, then that video or 3D model is usable as a button’s caption or inside a text document. Gone are the days of “Interface Apartheid”.

This sort of composition happens on an operating system level. While GDI can only create very primitive things such as lines, WPF produces more complex elements such as buttons, which can then be used by all development environments, which desire to use WPF. Gone are the days of individual development tools rendering their own buttons.

The fact that WPF bases all drawing operations on vector graphics also lends itself very well to using advanced graphics hardware (if present). Instead of using the CPU to render output, that burden is offloaded to the graphics card, which means that WPF can render significantly more sophisticated UIs and at the same time free up the processor to do other work. Graphics cards are also easily able to handle the resolutions we are aiming for.

WPF provides a very wide range of features. A comprehensive list is way beyond the scope of this article. However, it is worth considering some of the scenarios WPF is aiming to satisfy:

  • WPF provides controls to build typical Windows applications. This includes things like textboxes, buttons, and the like. In this sense, WPF can be seen as the spiritual successor of Windows Forms. It is also not entirely unlike building Windows applications in VFP. However, the aim of WPF is to create more polished and more professional UIs.
  • WPF aims to create next generation web experiences. Although Microsoft doesn’t put it that way (probably for political reasons), I look at WPF as a better Flash.
  • WPF provides many features of DirectX, such as 3D rendering, real-time lighting, and the like. Internally, WPF is really based on the DirectX engine. So this is a simpler way of using DirectX.
  • WPF provides an animation engine. Animations in WPF are storyboard and timeline based. In many (although not all) ways, the WPF animation engine is much more powerful and at the same time easier to use than Flash’s animation engine. WPF is capable of rendering very powerful animations, many of which I would have had to do with professional (and extremely expensive) tools such as Maya or 3DMax in the past.
  • WPF can be used as an image format. Those images are based on vector graphics. Conceptually, this is very similar to creating images in Adobe Illustrator. In fact, there is an AddIn for Illustrator that can save in a WPF format (known as “XAML”… we will discuss that later). WPF images are of very high quality, especially when scaled.
  • WPF is a document rendering engine. WPF allows for the definition of documents, similar to (but drastically more advanced than) HTML. For instance, WPF can create multi-column layouts with rich media integration. WPF rivals many professional desktop publishing and layout applications.
  • WPF not only renders document content on the fly, but it also defines print and digital documents using a WPF incarnation called “XPS” (which stands for “XML Paper Specification”, formerly codenamed “Metro”). Again, Microsoft doesn’t put it that way, but I like to think of it as a much better PDF format.
  • Finally yet importantly, WPF aims to enable completely new types of applications. Applications that move away from text presentation to innovative new ways of rendering information. As a smart man once said: “It occurred to me that no matter where I look - and I mean absolutely everywhere - I see things!”. Clearly, humans are very visual creatures, yet most computer programs are visually very dull, using simple lists of text to communicate information. WPF enables us to go beyond what is currently possible with Windows user interfaces.

At this point, it is somewhat difficult to say whether WPF is a Windows or Web technology. Fundamentally, WPF is a Windows technology, which falls smack in the middle of Smart Client development. The overall goal of WPF is to further push the limits of what can be done with Windows UIs. At the same time, WPF is directly supported in web scenarios. In other words: It is possible to browse to a web site built upon WPF using Internet Explorer or other browsers. It is even possible to view WPF applications on other operating systems such as the Mac or even on mobile devices using a special flavor of WPF called “WPFE” (the “E” stands for “Everywhere”). In the world of WPF, we really need to abandon the notion of Windows, Web, and mobile devices being completely separate. The days of being a “web developer” vs. a “Windows developer” are probably numbered.

Programming WPF

WPF is a technology entirely based on “managed code”, meaning it is based on .NET. This also means that it is not directly available to Visual FoxPro developers (although there are ways to interop as we will discuss below). WPF is basically a collection of .NET classes. For instance, there is a System.Windows.Button class that can be used in a very similar fashion to the Windows Form button control (called System.Windows.Forms.Button). One can use these classes programmatically. For instance, the following example creates a window with a single button on it:

System.Windows.Window wnd = new System.Windows.Window();
wnd.Title = "My First Window";
System.Windows.StackPanel pnl = new System.Windows.StackPanel();
wnd.Controls.Add(pnl);
System.Windows.Button btn = new System.Windows.Button();
btn.Content = "Hello World";pnl.Controls.Add(btn);

While this is a possible way to go, WPF also provides a second alternative known as “declarative programming”. Using this technique, UIs can be defined in a special XML dialect called “XAML” (pronounced “ZAML”). The above code snippet can also be expressed in the following XAML snippet:

<Window Title="My First Window”>
    <StackPanel>
        <Button>Hello World</Button>
    </StackPanel>
</Window>

While there fundamentally is a choice between the programmatic and the declarative approach, developers seem to be compelled to use the declarative approach a lot. It simply makes a lot of things much easier. For this reason, many of the WPF tools use the declarative approach. (Note: Despite this looking very much like creating HTML tags, this is different in that XAML generally gets compiled just like the programmatic example above).

Talking about tools: Of course WPF developers do not type in XAML or programmatic UI code any more than VFP developers do. Quite the contrary. The examples above use the direct API, which is comparable to using the GDI API low-level in C++. Clearly, the WPF approach is much easier and more productive to use. Nevertheless, tools are needed to make this more feasible. And there isn’t one, but a whole set of tools available to create WPF UIs. For instance, the next version of Visual Studio currently codenamed “Orcas” (which is available as a CTP) has a completely new UI designer for WPF. The designer is codenamed “Cider”. This tool is geared towards developers who want to use WPF to build business applications.

In addition to “Cider”, Microsoft is creating a whole new product suite called “Microsoft Expression”. You can check it out at www.Microsoft.com/Expression. This suite includes two tools specific to WPF: The Microsoft Expression Graphics Designer is a drawing and design tool comparable to Adobe Illustrator, except it has support for many WPF specific features. This tool can save images in XAML format.

Another tool of interest for WPF developers is Microsoft Expression Interactive Designer. This tool is specifically designed to create WPF and XAML based interfaces. The tool is not entirely unlike Visual Studio, but it is more geared towards designers. People who like Flash feel at home immediately in this tool. And to be perfectly honest, I even prefer Interactive Designer to Visual Studio’s Cider as a developer. But perhaps that is a matter of Cider being not nearly as complete as Interactive Designer.

In addition to these Microsoft tools, there are third party tools. Some are specific to WPF, such as Electric Rain’s Zam3D designer (www.erain.com). This program is used to create 3D interfaces or interface elements for WPF applications. Other tools support WPF and XAML as part of their feature set, such as Adobe Illustrator.

All these tools are rather sophisticated. However, there also is a simple tool called XAMLPad, that ships with the WPF SDK. XAMLPad allows to simply enter UI XAML and see the result immediately, without the need to create a complete project and compile it.

A WPF Example

So what does a WPF application look like and in particular, how do they look different from today’s applications? After all, the reason for going through all this trouble is not that we want to create the same applications we do today, but in new technology. Instead, we want to create applications that look and work better. Of course, it is difficult to come up with a revolutionary example in a short introductory article, so the example I will present here is more of an evolution, than a revolution. For further (and more revolutionary) examples, check out some of the videos Microsoft has made available on Channel 9 (http://channel9.msdn.com) under the “WPF” category. An example I like particularly well is the Accruent real estate application (www.accruent.com). Here’s a screen shot of that application:

Of course, as a first example, such an application is much too complicated. Instead, we will stick with a simpler example. In fact, I will use the Fabrikam Catalog example that ships with the Microsoft Expression Interactive Designer, since it is available to everyone who downloads the CTP and it deals with a subject matter familiar to most VFP developers: It represents an interface to a product catalog, with a list of products on the left-hand side, and details for each product on the right. In Visual FoxPro, we might use a databound grid for the list of products, and databound textbox and label controls for the detail. As the user clicks on a product in the grid, databinding will automatically display the selected details.

The general idea is the same in WPF. The following is a screen shot of the fundamental design-time setup of the form in WPF (using the Expression Interactive Designer):

On the left, we have a list of all the available products, similar to the grid we might use in VFP. However, instead of a grid control, WPF uses listboxes. In the current Windows world, listboxes are a very simple control showing a list of items in a single column. In WPF, listboxes follow the same fundamental idea, except that just like any other WPF control, they can be “styled”, which allows the developer (and the designer) to completely change the appearance. This includes the ability to set up fancy graphical styles for each item. In fact, we could go as far as defining a small form-like setup for every single item within the list. We could for instance define that each list item uses a certain graphical background (glass and bubble styles seem to be particularly popular these days). We could also define that each list item is a composition of multiple labels and perhaps even a thumbnail image of the actual product. These labels could be arranged in columns as well as any other conceivable configuration. The ability to style the control with this degree of freedom elevates the listbox control from a very simple control to being one of the powerhouse controls available to developers.

Note that the list is databound. Interestingly enough, the data shows up during design time. In this example, the data comes from an XML file, but that is just one of the possible options, which - in addition to XML - includes data from objects as well as more conventional data sources. The following is Interactive Designer’s UI for the setup of the list’s data source:

Similarly, labels on the right side of the form are also databound, and since they share the overall context of the list, they automatically refresh when a different item is picked in the list. This of course is something we are used to from VFP, but think about this for a moment: VFP is a system that sits on top of Windows, while WPF should be seen as part of Windows. Having sophisticated databinding supported at operating system level is quite exciting.

Another aspect of this UI that is rather interesting is the overall organization of the layout. Rather than dropping controls on a form and positioning them in an absolute fashion as we would do it in VFP, WPF organizes controls in hierarchical layout elements. One such layout element is called “Grid”. This is a bit confusing to VFP developers, since grids generally are associated with tabular data display. In this case however, a grid is simply a mechanism that divides an area on screen into sub-areas and it has nothing to do with data. Controls can be arranged relatively to those “areas” (the cells of the grid). This has the advantage that if the grid changes, all controls aligned relative to that grid replace themselves. For instance, if the grid is scaled to appear larger, all controls within the grid will change (resize, scale, or move) according to rules defined relative to the grid.

Our example uses multiple such grids. There is a main grid that aligns the listbox and the detail display in the center of the form. Inside this grid, there are two other grids. One that contains the list, and another that contains all the details. Depending on what part of the form we edit, the grid actually becomes highlighted. In the following screenshot, the grid containing the product details is highlighted yellow:

Note that the product image is positioned relative to the grid, rather than being positioned in an absolute fashion. While in VFP we would set the top, left, height, and width of the image, in WPF we set the margins of the picture relative to the grid. In this example the margin is 0 on every side except the bottom. This means that if the grid gets resized for some reason, the margin to the bottom stays the same, making the image grow. Unless the grid is scaled (“zoomed”) that is, in which case the image would not be resized but zoomed, and the distance to the bottom would change proportionally. For the image, the effect in both cases may be similar, but for the descriptive label below, the effects of these two operation would produce drastically different results, with the scaling operation changing the dimensions of each character, while a resize just changes the amount of space allocated for the text.

Adding Some Pizzazz

So far, things have been relatively trivial and not that different from VFP. However, with WPF, the idea is to provide visual finesse that is not achievable without WPF. To give you an idea of what’s possible without much effort, we can add a few bells and whistles to this example. To begin with, we can add some color. (Forget about battleship gray applications that were considered the “professional look” before… in the WPF generation, we will add design!) Of course, it is possible to simply add controls or change background colors, but to make things more feasible, the desire is to change the appearance in a more general fashion. This can be accomplished with styles. The following image shows the design-time view with a visual style attached to the master and detail grids:

Conceptually, WPF styles are similar to Cascading Style Sheets (CSS) in HTML, except WPF styles are more powerful. In this example, the grids are styled to have rounded corners. The background is a blue gradient. In addition, there is a rounded rectangle placed at the top of the style, which provides the glassy top edge. To create this effect, one has to apply a gradient of transparency. This is called “alpha blending”, which is natively supported by WPF. What is really significant about this (asides from the alpha-blending) is that a style is not just the ability to set properties globally, but in WPF, a style allows for the composition of new elements. For instance, in WPF it would be easy to create a style where labels are preceded by an image, which is not possible with CSS as CSS can only set properties but not add new controls.

Alpha-blending is in fashion in the WPF generation of UIs, probably because the effect was very hard to achieve without WPF. Another feature people really like are reflections. WPF makes it relatively easy to achieve a reflection effect through a technique called “Visual Brushes”. A Visual Brush allows the developer to show any part of a UI again in a different part of the screen. This includes dynamic parts, such as textboxes. Using this feature, we can place a rectangle below our current UI, and then specify that we want it filled with a Visual Brush. In this case, the Visual Brush is linked to the contents of the grid that contains both the master and detail area of our form. We can also specify that the brush is to be transformed. We want the brush to be mirrored so the contents appear upside down. Also, we apply a gradient of transparency to the mirror effect, so the parts towards the top of the reflection show strongly, while further down towards the bottom of the form, the dark background blends through a lot more.

The result can be seen in this screenshot of the form at runtime:

Note that the effect is very noticeable now that I drew your attention to it, but to people who just use the form, the effect is subtle. It makes the form look professional. Reflections are very common in the real world, and the brain simply recognizes it as looking realistic, without it becoming detracting. As a general rule of thumb, well designed WPF interfaces should look professional, but the applied effects should never be distracting. Whenever an effect is really noticeable, it is probably too blunt. (And yes, no doubt, we will see many WPF UIs with awful designs).

In addition to a nicely designed style, one of the staples of a WPF application is animation. In this example, the goal is to animate the appearance of the detail area. This can be done easily through the use of timelines. Using Interactive Designer, we can add a new timeline that will allow changing something gradually over a set amount of time. We can then wire that timeline up to a certain event such as the click on an item in the list.

The definition of the animation by means of a timeline is simple. We can select the initial state of the timeline and then set properties on the form as they will appear at that point of the timeline. In our case, we simply select the entire detail grid, move it to the left, rotate it by 90 degrees, and scale it way down. Then, we will move the timeline by a half a second, and move the detail element back to its original state. This way, we can achieve a rotating fly-in effect. The following screenshot shows the design time view of the animation, about a quarter of a second into the animation:

At runtime, the animation adds polish. At the same time, the animation is short enough to not interfere with the users interaction. This is another important concept for designed UIs: Add professional animations, but never interfere with the user’s interaction flow!

The following image shows 3 frames from the animation in action during runtime:

Note that the reflection at the bottom of the form is still accurate (compliments of the Visual Brush) despite the transformation applied dynamically to the detail area.

Voila! This is how simple it is to spice up a relatively simple user interface with WPF and the Microsoft Expression Interactive Designer. This interface isn’t as revolutionary as Accruent’s real estate application, but I hope it gives you an idea of what is possible and how easy it is to implement some of these features. Imagine spinning this example a bit further by replacing the product images with true 3D models created by Zam3D.

WPF and Visual FoxPro

So where does that leave us as VFP developers? Fundamentally, WPF is a .NET UI technology, and as such off-limits for VFP developers. However, it is possible to use WPF through .NET interop. For instance, it is possible to create a VFP COM object and serve up data for a WPF interface from that object. In those scenarios, one uses VFP to create COM objects. These objects are then exposed to .NET by means of a wrapper, which Visual Studio can create automatically. One can then create WPF interfaces by normal means such as Expression Interactive Designer or Visual Studio’s “Cider” designer. Finally, the WPF interface can call the VFP COM objects though the created wrapper.

There even have been successful attempts to make WPF elements available on VFP forms. In that case, one first creates a WPF interface and then imports the interface similar to an ActiveX control, by means of a third party container. While this works, the approach is even more cumbersome than the first option. It is difficult to expose UI elements within the WPF control, which makes it difficult to interact with the UI programmatically for things such as data loading. Also, many of the advantages of WPF, such as the unification of UI technologies or the resolution independence, are lost in this case. It is technically possible to use WPF interfaces in such a way, but due to these reasons, I personally doubt that WPF within VFP forms will be used in any significant projects, or - frankly - whether it makes sense to do so.

As a VFP developer, I look at WPF with one laughing and one crying eye. What troubles me is that WPF will never be integrated in VFP the way current Windows technology is. One the other hand, as an interface design enthusiast, WPF technology clearly fascinates me and I can’t wait to use it to implement some of my ideas. So much so that we decided to create a community portal focusing on this technology. If you have any questions about WPF, feel free to visit us at that portal (www.WPFExperts.com) or send me an email!

Markus Egger