June 2004 - Posts
Wednesday is also shaping up to be an interesting day at TechEd. After meeting up with Wolfgang Manousek, a Microsoft developer that actually lives in Germany (I didn't know that was possible!) early in the morning to talk about XML and its relation to the new SQLServer, I attended Herb Sutter's session on the future of C++ and .NET entitled "Visual C++ 2005: New Language Design and Enhancements"
I originally didn't plan to go to any C++ sessions, since I've mostly switched to C# nowadays, but after seeing all this stuff I have to admit I might consider having a look at C++ in the VS.NET 2005 beta. There was a lot of emphasis on combining traditional C++ features such as templates and the ability to do incredibly cool stuff that totally destroys your application if a single scenario shows up you never considered along with doing everything .NET has to offer, such as garbage collecting and generics. What I liked especially was the way destructors/finalizers/disposing are done in the upcoming Visual C++ 2005, although I'll have to look at the slides a couple of times and try the VS.NET 2005 beta before I fully grasp how these things relate. But the idea of mapping your delete statements to a generated dispose method sounds excellent. Especially since I've recently been having a more or less conceptual struggle with IDisposable. I'm not entirely sure if these things are avoided in C++'s new approach, but I guess I'll find out shortly.
After that I went to see Ingo Rammer at the Ask The Experts stand in the exhibition hall. We had a very interesting conversation about remoting and application domains. What I especially appreciate is his ability to start up his laptop and illustrate what he's explaining in more or less actual code without any preparation. I've seen him do this during last monday evening's presentation at the DotNed usergroup as well, but wasn't sure whether that was part of his presentation.
I'm at TechEd Europe! So far I've just dropped in yesterday for registration and today I've attended the opening keynote along with Rockford Lhotka's Building Occasionally Connected Applications, which was about the Smart Client Offline Application Block.
The keynote was interesting, one of the main things for me was the opening where a blind user demonstrated that Outlook Express is easy to use using enhancements that speak to him and a special braille reading strip, but that navigating websites is horrible: he kept running into loads of navigation text and other things unrelated to what he wanted to do. A good tip from him: always create a link to the actual content at the top of the page!
Furthermore there was the announcement of Express editions of popular development tools like Visual C# and SQLServer, of which the latter will replace MSDE. I'm just wondering whether TechEd is the right place to present products like these though. I mean sure I do software development in my free time and I enjoy it a lot, but those $150 standard editions of Visual C# are good for that. These versions appear to have lots of things built-in such as code snippets that are targeted at home users instead of professional developers that want to program at home. Still, the ideas are cool and I'm sure this will pull in more people to create software.
There was also a demonstration of Visual Studio .NET 2005 which included what looked like a full workflow, where you get a task assigned to you and people can see what everybody is working on. Along with a bunch of integrated software design tools and a tool to map the actual application onto the infrastructure, so you can work together with the admins to get everything in sync. Again looks very nice but I'll have to play with these things myself to get a feel for what's really possible.
What I liked the most though was the integrated testing environment where you can run unit tests and VS would actually detect that there are pieces of your code that aren't covered by the appropriate tests yet. I can really imagine this being very useful as I've run into this myself a number of times: quickly inserting something to workaround an issue that came up or to change some behaviour, passing all unit tests and thinking that everything must work. Until a user runs into a bug and you discover that your tests didn't cover everything. In theory when using TDD, you'd never write a line of code if you don't have a failing test, but in practice it just doesn't work that way, not when you're under pressure anyway.
Now to check for the next session I'm attending!
There are several ways to create XML files using the .NET FCL, but none of the standard methods allows simple extension of an existing file, such as a logfile, without needing to put the entire file into memory first (because that's what would happend if I use the DOM to add nodes somewhere near the end of a tree).
Now XmlTextWriter is the ideal candidate for logging since from a user's perspective it's basically a standard
filestream writer that has some standard formatting built-in. But unfortunately, everytime I Flush(), it wants the
things I've written to be well-formed. Actually this is an advantage but not for what I'm trying to do here: if I'm extending a file, I want to rewrite the closing tag without having written the opening tag (since that's at the top of the file and was potentially created weeks ago).
So here's a quick solution I came up with. Basically what I do is derive from this class and then use its
protected XmlTextWriter to write logging stuff. An implementation of this same idea (it's not a copy/paste because I don't have that code handy) has been running for a couple of weeks and it works well:
internal class Xmlog : IDisposable
private bool first;
private bool disposed = false;
protected XmlTextWriter xw;
public Xmlog(string logfile)
xw = new XmlTextWriter(logfile, System.Text.Encoding.UTF8);
first = true;
FileStream fs = File.OpenWrite(logfile);
fs.Seek(-6, SeekOrigin.End); // length of is 6 characters
xw = new XmlTextWriter(fs, System.Text.Encoding.UTF8);
first = false;
public void Dispose()
xw.Flush(); // flush here or XmlTextWriter will suspect something :)
byte endtag = System.Text.Encoding.UTF8.GetBytes("");
xw.BaseStream.Write(endtag, 0, endtag.Length);
disposed = true;
When I was coding up this class I stumbled upon something that keeps confusing me: IDisposable. In the MSDN
documentation is an example where its use is illustrated in combination with a finalizer, demonstrating that you can clean whatever you want when the Dispose()-method is explicitly called, but when you're in the finalizer, you need to only clean unmanaged resources because during finalization the existence of those managed resources is not guaranteed anymore. But then I wonder: in the example above, if someone forgets to call the Dispose()-method, I can't use the finalizer to ensure he ends up with a valid XML file. At least, that's what I make of the way it's explained.
I ended up looking through the SLAR to see if there's any further mention of it there, but it basically contains the same information as in the MSDN documentation (except for some interesting background on how the interface came to be along with an annotation by
Jeffrey Richter where he predicts my confusion :))
Frans has announced
that his company has released a new version of LLBGen Pro
. Most important changes are the inclusion of support for Oracle 10g and Firebird 1.x/Interbase 6.0. Furthermore the demo application is no longer feature-limited, so there's no reason not to check out this excellent O/R mapper for .NET (and if you're heading to TechEd Europe 2004
next week, don't forget to stop by the O/R Mapper BOF session on Wednesday June 30th at 14:45 in Room R!)
As the button in my sidebar shows, I'll be attending TechEd Europe 2004 next week in Amsterdam. Last week I received my entry pass and login information for the event's website.
I'm building a Windows Forms application that's fully extensible through a plug-in interface and that'll be used in several countries. So naturally I'm interested in "DEV463: Windows Forms: Controls Tips and Tricks". For some insights on how the extensibility should be working, I'd like to be at "DEV401: Building Extensible Applications Using Attributes, Reflection and Code Generation" and finally, since this localization stuff always gets put below a pile of other work, I figured it would be worthwhile to attend "DEV404: Creating a Klingon Culture - More about Globalization and Resource Management".
Unfortunately however, all three of them take place at the same time on July 2nd, from 16:15 to 17:30! Perhaps I can persuade these guys to hold one big session titled: "DEV499: Building Extensible and Globalized Windows Forms Applications Using Attributes, Reflection, Code Generation and a bunch of Winforms Tips and Tricks"?
Today I created a small GUI application to wrap a library I had written that was apparantly confusing to use for some of my users. The GUI application was not only meant to simplify the input of data to the library, but also to explain how and why the library works the way it does. After putting tooltips behind all the labels, inputfields and buttons I decided they're only useful if you can explain everything about every control in a single sentence. Also, I wanted to use diagrams in my explanations, which probably look kinda silly in tooltips anyway.
So I settled on writing some user documentation. And to make it completely interactive, I figured it would be best that when you hover over a control that it pops up a tooltip and then if you press F1 it takes you to the HTML documentation related to it, indexed by an anchor with the name of the control. This probably sounds far-fetched but remember I don't usually code GUIs.
I created the eventhandler for the KeyPress event in the constructor of the form class (or rather, VS.NET created the eventhandler after pressing TAB twice) and then proceeded to test the pressed key for F1. Somehow this didn't work, so I fired up MSDN and got the explanation: KeyPress is not fired on non-character keys. I replaced the KeyPress event by a handler for the KeyDown event hoping this would solve it. Unfortunately, it didn't.
Again back to MSDN to read the entry for the KeyDown-event. There I read something about setting the KeyPressEventArgs.Handled property to true to prevent the other controls from acting on it. It didn't sound like something that would disrupt the F1 from coming through (since it would have to be detected in order for it to prevent other controls from acting upon it) but since something like this takes five seconds to test I gave it a shot, naturally without success.
After browsing around a bit I couldn't find anything, so I decided to scroll through the form's instance (this) intellisense listing and found a Form property called KeyPreview. Its tooltip claims it does exactly what I was looking for. After setting it to true in the form's constructor the F1 presses were caught by the eventhandler.
Now for determing where on the form, if at all, F1 is pressed. I was looking through Control's intellisense listing (since this tactic served me so well only minutes before) looking for something with a name such as HitTest, but to no avail. I did find a static property on Control called MousePosition which I knew I would need as well, along with PointToClient, an instance method on Control to convert the screen coordinates to client coordinates if I turned out needing that later on. I found it in the example code of MousePosition's MSDN entry.
But how to find the controls inside the form? I figured that it had to be a method or property of Control since controls can have controls inside them. GetChildAtPoint was the answer, a quick Google Groups search pointed out and along with the previously found property and method I got everything working.
I'm not sure if this is the typical way non-GUI people go about solving these things: poking around looking for useful things much like BA and Hannibal after getting locked up in some old hangar. Which made me think about what would make developing something like this easier. I think a lot of this could be done by improving intellisense so that it doesn't just show the things that are available, but highlights the things that could be useful. Like when you have an instance of a Point sitting at your cursor, it could show methods that take or return those.
Also, instead of those classic posters that come with books showing purely hierarchical class diagrams, perhaps something showing the relationship between all events, properties and behaviour like the KeyPreview's effect on the KeyDown event. Then again, I'm vague about this because I don't really know how to go about making something like that because everything is probably way too much intertwined. And besides, I don't have an eight-dimensional wall to put the resulting poster on anyway.
The last couple of days I've been reading the .NET Framework Standard Library Annotated Reference (often called SLAR) by Brad Abrams (who's actually requesting feedback I just noticed) et al. I saw a lot of recommendations for this book on Amazon and .NET-related weblogs, which caused me to give it a try as I'm normally not really interested in plain API books, since especially for Microsoft technologies, there's the excellent MSDN library. I believe the last API book I bought was about Java 1.1 around 7 years ago.
As a reference to the Standard Library I'll say that whenever I want to find out about how a class or member works, I'll still use MSDN and not open up this book. I wondered about using the PDF provided on the included CD-ROM since it includes descriptions of all members (making it a 4000-page book if you'd print it!) but using a PDF even when indexed is still clumsy compared to MSDN (not to mention that the size of the PDF makes it sluggish even on my dual Xeon workstation). The reason I did consider it is because after doing some comparisons between MSDN and SLAR entries, I noticed that sometimes the SLAR provides a little more info, but the MSDN wins out in the end because it has lots of links to related articles. The SLAR is not lacking these since they're often outside of the context of this book, but from a developer's point-of-view this does make MSDN more worthwhile as a reference. Anyway, nowhere does anyone claim that this book was intended to replace the MSDN Standard Library documentation, but I was wondering about this myself when I bought it.
That's not to say the book is not a good read, because it is, just for different reasons. For me, this book was interesting because of two things. First, it was good to browse some documentation by hand again, since you learn a lot by just reading all this stuff. Quite a lot of things (like some of the attribute-related information) I would probably have never looked up myself and in retrospect I can say that I have some cleaning up to do in some of my existing code. The same is true for all the listed interfaces - I feel I have a better grasp of how and when to use which interface on one of my own classes.
But second and most importantly (that doesn't sound right but you know what I mean) the annotations give a great insight in what goes on when you're developing a class library that's supposed to be used by other developers. I'm doing this myself and reading this book has given me loads of advice in this area. From small things like how to think about exception hierarchies to which interfaces to select when implementing base classes of a large system. Especially since the writers include a lot of material on how they would do things differently in retrospect and the discussions they had about some of the types. Even the naming scheme is discussed quite often, which is great since it puts all the different arguments in perspective.
My conclusion then is that it's not a great reference book, but an interesting read for .NET developers in general and a must-read for class library developers.