Archive
My first real WPF and Blend 2 application
I’ve been familiar with WPF since December 2006 and the release of C# 3.0, and I’ve had Expression Suite installed for almost a year. While I’ve toyed with it here and there, I have never devoted the time and effort necessary to really begin to become proficient.
However, since last week’s Silverlight 2.0 release, I have been burying myself again in learning new technologies. I finally decided to take the plunge, so I installed Silverlight 2.0, the Visual Studio updates, and upgraded to Expression Suite 2 SP1. I spent a couple of days going through ScottGu’s tutorials and some others on Silverlight.net. I followed along and built the samples, some in Visual Studio and some in Blend.
Most of these have been around for a while, so I’m not claiming any kind of leading edge stuff here. What I wanted to do was to share some of the insights I’ve had in attempting this project.
What’s the big deal
XAML marks a sea change in how user interfaces are developed. The end result of XAML is still .NET objects, and as such they can be created and managed programmaticaly, but the ability to simply describe what you want is very attractive. For a long time, I did not like XAML itself, and one of my reasons for putting off learning WPF was that I wanted to wait until something like Blend made all XAML interaction obsolete. After diving in for a few days, I no longer feel that way, but I’ll share more about that later.
What really makes all this so attractive is the ability to do basically whatever I can imagine for an interface. More importantly, I can do it without a ton of hand coded control drawing, something I never liked doing in the first place. The behavior of a control truly is separate from its presentation, and the presentation can be altered or replaced in any number of ways. In other words, you can achieve some pretty cool effects with a reasonably small effort.
Visual Studio or Blend?
I’ve been having an ongoing discussion with a friend of mine at RVNUG about the usefulness of writing WPF applications within Visual Studio. Having seen some demos and had some training on Blend, I was staunchly in the Blend corner on this one. While you can drag and drop controls in Visual Studio, it takes a lot of hands on XAML coding to get anything more than a rudimentary window up and running. As I mentioned previously, after seeing some XAML presentations I really wanted to avoid that as much as possible, which is what makes Blend so intriguing.
But, having gone through ScottGu’s Silverlight tutorial and building an application in Visual Studio, I have a better appreciation for it now. One thing I do like about using Visual Studio is that it is keyboard centric. As a classic Midrange developer I have always shied away from using the mouse as much as possible, so it appeals to my keyboard-philia. And of course, Intellisense is still the killer feature and makes it much more palatable. Also, as a seasoned and grizzled web developer who still likes the occasional dip into VI and Notepad, it only took a little time with XAML to feel comfortable with what was going on. Anyone familiar with XHTML and CSS should find XAML completely doable. It is, of course, a lot more complex, with numerous options and quirks, but it is still familiar territory.
Now, all that being said, I still prefer Blend 5 to 1 over Visual Studio for Visual XAML development. I have only run into a few things that I couldn’t accomplish easily through Blend, and I’m new enough to it that I still chalk it up to just not knowing the tool well enough. Applying and developing styles is still one of these areas: I so far have not figured out how to do them in Blend, so I revert to XAML editing.
Which brings me to my question of the day: “Should I use Visual Studio or Blend?” The answer is a resounding “both!” OK, I’m sure you saw that one coming, but let me explain my position. If you are a developer, there is no question that you are going to use Visual Studio. After all, it is our bread and butter, and all the real code will still be developed in our beloved IDE. But designing serious WPF solutions in Visual Studio would be far too painful, even with great Intellisense support. There are simply too many options to have to code them by hand.
It reminds me of my first Windows application: a Java Swing application that I wrote in Wordpad. Believe me, the pain of that experience made me instantly recognize the value of Visual Studio and is largely responsible for my shift to Microsoft technologies. On the same order, as soon as I saw Blend I knew that this was the tool I needed to design good WPF applications. So, for layout and Visual Tree management, use Blend. When you find a problem that you think you must solve using XAML editing, switch over to Visual Studio and take advantage of Intellisense, which Blend does not have.
Quirks
A couple of things so far have jumped out at me. While Blend and Visual Studio do a pretty good job of keeping each other in synch, there are a couple of irregularities.
The first real problem I had was in adding existing projects to my solution in Visual Studio. I started my solution in Visual Studio and then opened it up in Blend to work on the design. Later in the same session, I went back to Visual Studio and added several projects. Now that I had some CLR objects to work with, I wanted to try Data Binding, so I followed one of the online tutorials but no joy. No matter what I did, I could not get Blend to find the objects. Every time I tried, I received a slew of “file could not be located” errors. Finally, I restarted Blend and when I opened my solution, there the missing objects were.
Second, there have been several times when I’m not sure that I am being properly prompted to reload. I could be imagining it, but I feel pretty strongly that I have made changes in one without being prompted by the other to reload them. Perhaps this is just a matter of timing Saves.
Conclusion
Well, I don’t really have any as of yet. I do think that a lot of developers are going to struggle against the designer learning curve, yours truly included. But I think in the long run we will be much better off. So far, I am pleased with my efforts. I like the combination of resources the two applications provide me, and I amd getting more comfortable in deciding which to use for certain scenarios.
I’m not quite ready for a tutorial series, but I will try to share some of my learning with you all as I go. In the meantime, give it a try yourself and let us know what you think. Happy Coding!
Storing an Image in an XML file
I recently had a project that required a custom subset of data from a database be stored in an XML file. Each “row” of data also had a related image on a separate server. The project required that both the data and the image be transferred to a client for subsequent consumption by another program. In designing the project, it seemed unnecessarily complex to transport the data and the images as separate entities. Mostly the problem was that this process would simply add more moving parts, which would add to the complexity and increase the probability of “user inspired difficulties.”
Since both the data and the images were to be consumed by the same process, it appeared logical to embed the Image objects directly in the XML file as part of the data description. I found several examples on the web and eventually hobbled together my own version.
Saving the Image to XML
Since XML is ultimately just a formatted text file, the first step is to find a way to represent the Image object as text.
Bitmap bmp = new Bitmap(imageFileName);
TypeConverter converter = TypeDescriptor.GetConverter(typeof(Bitmap));
XElement img = new XElement("image",
Convert.ToBase64String(
(byte[])converter.ConvertTo(bmp, typeof(byte[]))));
element.Add(img);
There are several things going on here. We want to convert the element to a byte[] so that we can extract a string representation of the object. To do this we create a TypeConverter object over the Bitmap type. Now we can use the TypeConverter to convert the Bitmap to a byte[]. Now, to properly encode the byte[] for writing to the XML file as a string, we convert it to a Base64 String.
Reading the Image from the XML file
Now that we have the Bitmap as part of our XML file, we need a way to read the Base64 String back into a Bitmap object:
string val = currentXml.Element("image").Value;
byte[] bytes = Convert.FromBase64String(val);
MemoryStream mem = new MemoryStream(bytes);
Bitmap bmp2 = new Bitmap(mem);
In this example, we retrieve the XML text, convert it to a byte[] using Convert.FromBase64String(), use that to create a MemoryStream, and finally use the MemoryStream to create the Bitmap. Naturally, you can make this more concise:
Bitmap bmp = new Bitmap(new MemoryStream(Convert.FromBase64String(currentXml.Element("image").Value)));
Wrapping it up
I’m a novice when it comes to encryption and such things, so I’m not claiming that this is the best solution. It did work and the application is functioning as designed, but I’d like to get some feedback about this method, comments, alternatives, etc. If there is a problem with this solution or a better way to do it, please comment below.
Developing For .NET 