Check it out, guys: a mere day after creating the TaoControls project on BitBucket, I’m here with a sweet new update: the
I developed this control to address what I felt was a pretty big hole in the functionality of the
System.Windows.Forms.TextBox class (which happens to be the base class from which
DelayedTextBox derives). As just about any developer familiar with Windows Forms knows, the
TextBox (along with many other controls) has a
TextChanged event, which gets raised immediately as soon as the text in the box is changed in any way—even by a single character.
I don’t know about you, but I’ve gotten pretty used to UIs that update dynamically as I’m typing (consider the “search as you type” feature that Google introduced not too long ago, for example). But at the same time, as a user I also demand that my UI remain responsive, always (in my opinion, an unresponsive UI has got to be among the top 3 most frustrating shortcomings of any software application featuring a GUI). The problem with the
TextChanged event is that it’s indiscriminate, which makes it difficult to accommodate both of these requirements: dynamic updates + responsive UI.
For instance, the “Dashboard” application used by the traders at my company to monitor our overall trading activity includes a feature that allows the user to type in a symbol and immediately see the “book” (if any) where that symbol is being traded. Originally this was done by attaching a handler to the
TextChanged event of the text box in question and performing the search in there.
I turns out this posed a problem: on relatively rare occasions, for reasons outside the scope of this post, the search would take… kind of a long time. Like, maybe 1–2 seconds. Which, from the user’s perspective—especially a trader’s perspective—is pretty disconcerting. If I was standing in the trading office at the time this happened, I would hear one of the traders curse and grow quickly panicked: “Call the exchange, the system’s frozen!”
Of course, after everything went back to normal within a second or two, things settled down quickly. But it struck me that reacting to every single keystroke (effectively) within a
TextBox was, for our purposes, overkill. Really, I thought to myself, there’s no need to do that search until after the user’s finished typing.
We could always have done away with the FAYT (“find as you type”) functionality altogether and added a button labeled “Search,” of course. But this goes against one of the principles I mentioned earlier: having a UI that dynamically updates itself. So I set to work on a control that would offer the functionality I felt we really needed: a
TextBox that raises an event only after a certain amount of time has elapsed.
This is basically what
DelayedTextBox is: in addition to all of the properties and methods available to
Textbox (which, by the way, still includes that old
TextChanged event should you need it), it comes with two additional members: a
DelayMilliseconds property, specifying how much time to “wait” after the user changes the text to raise an event; and a
TextUpdated event, which gets raised after said time has elapsed.
Why not download it and give it a try? The downloadable .zip file includes an executable demo of all (2) controls in the library, so you can certainly give them a try before you decide whether or not you want to use them.
I’d include a screenshot, but it really looks just like a regular