It Didn t Work

It Didn t Work!

Well, it almost worked, but it didn t. What happened was that the text was added in the right place, but an extra newline was added. We saw quickly that it must be the newline that would have been added in a normal TextBox. But we re signaling that we handled the key, with that kea.Handled = true. Why are we getting an extra return?

We fiddled around a bit. We thought maybe that when we typed Enter, Windows was sending an Enter character and a LineFeed character, so we wrote a handler for that. That wasn t it. We thought maybe the TextBox used KeyUp instead of KeyDown, so we converted to that. That didn t help: we kept getting that extra newline. At some point we realized that whenever we typed any control character into our original prototype, the bell would ring, even when it was one of the characters that we were handling. That told us that our handlers were really not suppressing the handling of things by the TextBox. That realization didn t solve the problem, but it told us that either we had a generic kind of bug in our code or something was going on we didn t understand.

A bunch of digging through the TextBox documentation showed us that there was another event besides KeyUp and KeyDown, namely KeyPress. It turns out that Microsoft has this other event that abstracts the idea of key up and down into this key was pressed and produces three events for each key action: Down, Press, then Up. Wonderful. It also turns out that KeyPress doesn t use those nice mnemonic key definitions: it returns a char type. We suppose that s some historical deal, since the Up and Down events are so nicely object-oriented.

Anyway, we wrote a KeyPress event handler that checks for Enter and indicates that we had handled the event. It makes the extra line go away, and it looks like this:

 void XMLKeyPressHandler(object objSender, KeyPressEventArgs kea) { 
int key = (int) kea.KeyChar;
if (key == (int) Keys.Enter) {
kea.Handled = true;

From now on, when you see that second handler, you ll know why it s there. We decided to use the KeyDown handler for the bulk of our work because we prefer the interface that lets us refer to the keys by name . Still, this solution is fairly ugly, and we posted a note on the C# newsgroup (microsoft.public.dotnet.languages.csharp) for a better way to do it. If we get an answer, we ll change it and let you know. All that the code actually does, however, is indicate to Windows that the Enter has been handled. The result was the code working as expected: hit Enter and it inserts the two desired lines, after line 3, because CursorLine() always returns 3. So we went back and wrote a real CursorLine() method:

 private int CursorLine() { 
String[] lines = txtbox.Lines;
txtbox.SelectionLength = 0;
int start = txtbox.SelectionStart;
int length = 0;
int lineFound = 0;
int lineNr = 0;
foreach ( String s in lines) {
if (length <= start && start <= length+s.Length + 2 ) {
lineFound = lineNr;
length += s.Length + 2;
return lineFound;

This isn t pretty, but it works. It s looping over the lines and checking to see if the cursor position is between the beginning and end of each line. The +2 handles the CrLf at the end of each line. We suspect there might be a better algorithm, and cleaner C# code, and we ll try to clean it up before we re done. If we don t, you can write us an email and ask why we didn t. But for now it works, so we re going with it.

We were quite tired by now, since we had been going at it for a couple of hours and had been beating our heads against some unknown API thing for much of it, and we decided to call it a day.

start sidebar
Lesson: What Have We Learned?

Quite a bit. We have code, rough as it is, to figure out what line the cursor is on. We have code, rough as it is, to compute a new line collection. We have handled the keyboard events, and although we don t like what we had to do, we re now sure that we can do all the control sequences that the application needs to do, at least for the basic editing stories.

So far, this code isn t very good, and that needs to be improved. But our story isn t done: we still have to set the cursor to the correct new location, task 4. We ve done only a couple of hours work so far, so we feel it s OK that it isn t sweet yet. More important, though, is the fact that we ve been running without tests, other than visual ones. We feel a lot of fear when we work without tests, but we didn t know how to do the GUI stuff test first, and we felt it was better to learn how to do what we had to do. We ll rectify the testing problem tomorrow, I expect.

I d feel much better if we had known how to do today s exercise test first, but we didn t. If you have any ideas, let us know and we ll try it next time. As the book goes on, I m sure you ll see some better examples of how to test this sort of thing. At this point, we just didn t know enough C# to do it.

end sidebar

Extreme Programming Adventures in C#
Javaв„ў EE 5 Tutorial, The (3rd Edition)
ISBN: 735619492
EAN: 2147483647
Year: 2006
Pages: 291 © 2008-2017.
If you may any questions please contact us: