Developing For .NET

I can’t believe it’s been almost a month since I posted something. Time sure flies when… well, it pretty much always flies, doesn’t it?

I’ve got a new tool to share with you called PropertyBuilder. It is simple enough: a couple of entries and it will generate the code for a variable and its related Property. I can’t take credit for the idea, I saw Richard Hale Shaw use something similar last year at VSLive! Dallas. Several times since then, while developing code with lots of properties, I thought that it would be a handy tool to have. Also, I have been reading Code Generation in Microsoft .NET, Kathleen Dollard’s book on .NET Code Generation, so I thought I could put some of this stuff together and write my own tool.

The tool itself is very simple. It stores a few basic templates that contain replacement values. It then replaces those values with the user entered values, and viola! Property code. Copy and paste the code into your application and there you have it. You could easily do a whole slew of variables/properties at one time. Obviously, the benefit of such a tool is fairly apparent: faster coding and less time spent slogging through the same-old same-old. Isn’t that worth a few hours of development time? Code Generation in general has enormous potential to ease your development burden.

But how often do we take the time to write code like this? With the constant demands of clients, bosses, and deadlines, probably not nearly often enough. The truth is I should have done this last year after the conference when it was new and fresh. Which brings me to my next point: just like we need to take some development time for ourselves, we also need to take training time. Yes, it’s time away from the demands of the job, and yes it costs money, but the cost of the effort, like the return on the time spent developing our tools, can pay huge dividends in the long run.

So, download the tool or write something like it for yourself. And sign up for a conference or take some classes. I’ve just cemented my plans for attending VSLive! Austin in November. I plan on doing a little live-blogging, and who knows what else I’ll come away with.

I just thought I share with you another example of using an event in the current application I am developing. As I mentioned in the previous post, I like to develop GUI applications that can be entirely managed by the keyboard, especially for data entry applications.

In this current application, I have a tab control. Inside the tab control, I place a UserControl. Inside this UserControl, I place four other UserControls whose designs are all identical, with each one representing a “screen” (and it takes four of these screens to represent an entire data record). Sort of like a Wizard Control (and I may write about this design more in the future) that allows web-like backwards and forward navigation. For now suffice it to say that only one of the four screens may be shown at a time, so I use a combination of the Parent property and Visibility to show the correct screen based on user navigation.

And it is the navigation that I want to discuss. The navigation controls are all on the Parent UserControl (we’ll call it Editor), which handles the switching of screens, etc. To enable keyboard events, I chose the easy route of adding a ContextMenu to Editor, and creating ContextMenuItems for each of the navigation options I wanted. Using the built in options of Visual Studio, I then assigned each of these items the keyboard shortcut I wanted. In this case, I wanted the screens to navigate like a web browser, so I wanted Alt-Left and Alt-Right to switch backwards and forwards between the screens. (I actually have seven of these, but these two will suffice for this example.) I then of course wired the events up in my code to react to the ContextMenuItems being clicked.

This worked great… as long as Editor was the control with Focus(). Once the user clicks inside one of the child UserControls, the Focus() shifts to that UserControl! Now my keyboard navigation ceases to function. But I had to allow the screen to retain Focus(), so that the user could continue to use the Tab key for form navigation. So, what to do?

I did some research and found an option in overriding the UserControl’s ProcessDialogKey method. This is an interesting method, and really opened my eyes to the sheer number of items that can be overridden and taken advantage of. I’m going to have fun examining some of these, but for now let’s get back to this one. The easiest way to use this is to use a Switch statement based on the method’s KeyData parameter to compare this to the values available in the Keys enumeration. I wrote some code to do this, thinking that I had solved my problem, but alas it did not work… or at least did not appear to work. Pressing the Alt-Left or Alt-Right keys did not fire the event. Instead, the Alt key would send Focus() to the Main Menu of the Main Form Window.

Since I was getting no joy, I decided to go another way. I copied Editor‘s ContextMenu onto each of the screens and wired up the items events. Unfortunately I experienced the same problem as above. It turns out that I was not managing Focus() enough. I had to add code to assign Focus() to each screen when it was activated. Doing that began allowing the Events to fire as desired. Because of this, I believe the ProcessDialogKey approach would have worked, but since I had already ripped it all out I did not put it back to test my theory.

So now that the event is firing as desired, the problem is that is is firing within the screen: but all the navigation is in the Editor! So now the task is to notify Editor that a navigation event has been requested. The answer of course is to create my own Event. Following the approach outlined here previously I created an EditorNavRequestedEventHandler delegate in the Editor code. Then in each of the screens I created the actual EditorNavRequestedEvent and fired it whenever the ContextMenuItem event fired. Rather than create a separate event for each of the possible navigations types (again I have 7 of them), I created my own EditorNavRequestedEventArgs class that I used to pass what navigation had been requested.

Now in my Editor code I added the EditorNavRequestedEvent listener and method for each of the four screens. It sounds like a lot of code, but it really isn’t. What it is is another great example of how simple events can make communication between objects very simple. Now I have a Wizard-like control that allows browser-style keyboard navigation. It also has the added benefit of a ContextMenu, which users are fairly comfortable with, thereby increasing flexibility and user options. If you don’t want a ContextMenu, remember you can still use the ProcessDialogKey approach: just make sure your Focus() is in the right place.

EDIT:

There is another way to handle this: you can have ToolStripMenuItems that activate this behavior.? The trick there is to have them percolate downwards to the currently displayed Editor control (remember this was inside a TabControl, so you could have multiple Editors at any given time.)? You would then need to execute public methods on the Editor instance to control navigation from the outside.? While it would work, I preferred all the navigation to be private, which the Event approach allowed me to do.? Also, I would not only need to identify which Editor instance was active, I would also have needed to monitor when and if there were any active so that I could set Enabled statuses for the ToolStripMenuItems.? This would need to be done everytime the TabPages property changed and whenever the SelectedIndex property changed for the TabControl. Overall, I felt like this added too much overhead, but it does offer an alternative approach.

Because of the type of data processing applications I develop, I try to design them in such a fashion that the mouse is largely unnecessary. This means a lot of function keys, hidden context menus, tab order, and Focus() manipulation. For the most part, with just a little forethought and effort, you can make an app very responsive to a “heads down” data processor.

Here is one example I ran in to today while working on a fairly typical database management type utility. The user performs a database search and is presented with a list of records that match the query. These records are listed in a DataGridView control and immediately after the search is complete, Focus() is transferred to the DataGridView control. Now the user can easily use the Up and Down arrow keys to navigate the Grid, but record selection becomes a little tricky.

Intuitively, the user should be able to highlight the desired record and press the Enter key on the keyboard to select the record. Unfortunately, the default behavior of the DataGridView control does not function this way: when the Grid has the focus, pressing the Enter key will advance the highlighted cell to the one immediately below it, just like pressing the down arrow key. This is not intuitive and in my case is down right unacceptable.

To bypass this behavior, we need to monitor the KeyDown event, and if the Enter key has been pressed, instruct the Grid control to ignore its default behavior. We do so by setting the KeyEventArgs Handled property to true:

private void dataGridView1_KeyDown(object sender, KeyEventArgs e)
{
    if (e.KeyData == Keys.Enter)
    {
        e.Handled = true;
    }
}

Now the highlighted cell will not change when the Enter key is pressed. Then in the KeyUp event, we can instruct the Grid to perform whatever task we wish to process the record:

private void dataGridView1_KeyUp(object sender, KeyEventArgs e)
{
    if (e.KeyData == Keys.Enter)
    {
        this.RecordSelected();
    }
}

And now we have a DataGridView control that handles the Enter key in a more intuitive fashion.