Jeroen’s weblog

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.