Today's wild WPF(ish) Wednesday project by Bryan Prendergast is one that might make the WPF purest cringe, might cause you to lift an eyebrow or three, but provides a very unique way of thinking about building WPF applications. If you're looking for a "think outside of the box" for building WPF applications...
"WPF Composites makes WPF so easy that a baby could do it. Think of building blocks . . ."
WPF Composites is a project designed to provide an alternative, concise, C# code-behind approach to managing UI Element composites. Composites are normally managed via WPF Databinding and DataTemplates but this library uses ID's and X-Y Coordinates instead to position elements on the screen. This is currently for synchronous apps only or apps that invoke on the UI Thread when working with Composites. This library is still alpha and under-construction. However, I welcome volunteers! NO XAML. NO DATATEMPLATES REQUIRED!
BEGIN COMPOSITE . . . END COMPOSITE
Below is an example for creating a new composite, adding a new Rectangle (automagically instantiating it) to the composite, followed by adding two Textblocks underneath the Rectangle (all in column 0):myDockPanel.BeginComposite(myGuid) .AddAnything<Rectangle, DockPanel(0,0) .AddText(1,0, "Hello World 1") .AddText(2,0, "This is text at Row 2 Column 0 in the composite") .EndComposite(new DockArgs(Dock.Left));
The entire composite is then added to myDockPanel at Dock.Left.
Typically, objects retrieved from or saved to a SQL database will have a record ID associated with them, either a GUID or a basic IDENTITY number (1-...). It follows then that composites of UI Elements on the screen may also readily be associated with this same ID, the same ID as that used in the database. However, a GUID is not required (as one can be created automatically behind the scenes.)
This can be an effective way of binding and retrieving a composite set of UI Elements (which may correspond to properties within a C# Class.) Within a single composite tied to an ID, identify X-Y Coordinates for positioning child elements within a Grid within a parent container.
I started with a working example of this code-behind approach via extensions to the WPF ListBox. I used extension methods because I didn't want developers to have to implement a new custom control.
Want to see more?
See C# Demo App Screenshots here: Demo App Screenshots
This library isn't limited to C#. See an IronPython example here: Iron Python Example
Remaining To-Do Items: To-Do List
Tutorials and Details: Dictionaries, Easy as 1-2-3-4-5, Selectors
These screenshots are taken in 1280x1024 screen resolution. The demo app should scale up fine to higher resolutions as long as they maintain this same aspect ratio (better choices could be made in terms of layout and relative positioning in a live production app.)
A key thing to focus on in these screenshots is the fine-grained control over colors/styles . . . note how many little pieces are exposed for styling via code-behind with no XAML required by the developer.
In other words, my color choice may be hideous, my design skills old-school or flat, but it's just to show off what is possible, how many items you can change/modify/override?
In this first shot, I showcase the Grid, TabControl, ListBox, DockPanel, TreeView, DataGrid (with Composites), GroupBox, ComboBox, Dialog, and multiple ScrollViewers.
A new, very different means to build WPF applications, one that might appeal to those in the WinForm world.
Oh and you get the entire source behind this approach too!
Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.