exotribe

In WPF, the Visual class is the base class for everything that ends up on the screen. In this respect, it is sort-of comparable to an HWND in classic Windows. Most of the time you end up working with things that are derived from Visual, like Controls, but every now and then you end up with a Visual by itself. For example, when working with FlowDocuments, if you extract a page, the page is returned as a Visual.

Well, for those of you who didn't know, Maxx and I have been working on a WPF book for the last 6-8 months--which is part of the reason why we have not been terribly good at getting up blog entries here.

The book is now in its final review, and should be coming out some time in December. Still lots to do, though, including making sure we are up-to-date with Visual Studio 2008, indexing and so forth.

The book is called WPF In Action, and is part of Manning's In Action series.

I am not really a web developer, and find the entire process of doing web development to be really painful. One of the more painful aspects, to me, is having to constantly restart IIS (I can't use the built-in web server in VS 2005 for various reasons).

So, today I spent about 20 minutes and built a little system tray utility. When run, it puts a little globe icon in the system tray. You can right-click to start/stop/restart IIS or launch the IIS control-panel applet. There are probably others out there that do the same thing, but I was too lazy to search extensively.

My last post was on the merits of using a StringBuilder vs. concatenating strings. For those of you who are really worried about performance, there is another thing to think about when using the StringBuilder – using Append vs. AppendFormat.

AppendFormat is sort-of handy. You can build up a string with replaced values in the middle:


StringBuilder sb = new StringBuilder();
sb.AppendFormat("The field {0} has the value {1}",strField,nValue);


However, you should be aware that this is significantly slower than building the string in pieces:

Nothing very earth-shattering, but I’ve noticed that there are some misunderstandings related to the trade-offs of using the StringBuilder vs. concatenating strings, and thought I would pitch in my 3 cents.

First off, I will assume that you already know not to build massive pages of text (say an HTML page) by joining dozens or hundreds of strings together. I do think, however, that there should be a compiler feature that runs a couple of thousand volts through any programmer who does that.

This is more about the edge cases. First of all, how many strings should you be joining together before it makes sense to use a StringBuilder, vs. just straight concatenation? With two strings, it is easy – concatenate the strings! This is clear if you just count the number of objects:


string str3 = str1 + str2;


Vs.


StringBuilder sb = new StringBuilder();
sb.Append(str1);
sb.Append(str2);
string str3 = sb.ToString();


Forget anything going on behind the scenes – using the StringBuilder is adding an object that has to be cleaned up, so it is a net loss. When you consider the actual work being done, it is even more or a net loss – StringBuilder has to allocate and maintain a buffer.

My compatriots on this blog have been pretty heavy on the theoretical so far, so I thought I would see if I could come up with a first entry that contains some actual code.

Of course, that doesn’t mean that I’m not going to philosophize a bit first.

When a developer first moves from C++ to C# or another .NET language, arguably the biggest shift is learning how to work with a garbage collector, and going from deterministic destruction (i.e. knowing when your stuff is going to go away) to non-deterministic (don’t worry about, your stuff will go away at some point).