At work, we do our development in VB6. The change to VB.NET probably won’t happen until we are forced to do so by competitive pressures. I just finished dealing with a VB6 bug, and I think it makes a good illustration of how VB.NET might make my life easier.
I’ve been developing an internal UserControl that is a frame with dynamically loaded controls. The control supports textboxes, combos, and checkboxes, which may be loaded in any combination in any order. The UserControl has an invisible textbox, combo, and checkbox that is set to Index 0 to create a control array for each type of control. The control also maintains a collection of references to every dynamically loaded control (Index > 0). This collection is updated during AddControl and RemoveControl procedures.
I quickly ran across a problem with tabbing through constituent controls.
The suggested workaround is to detect and handle the problem in the KeyPress event of the last control on the form. Normally, the KeyPress event isn’t raised for the Tab key. However, it is raised in the problem scenario.
Since I’m dealing with three control arrays, any of which any could contain the last control on the form, I have to deal with the problem in three places.
Here’s a sample of the solution I implemented:
Private Sub txtText_KeyPress(Index As Integer, KeyAscii As Integer) ' Are we getting a Tab key? If KeyAscii = vbKeyTab Then ' Throw away the keypress to suppress beep from VB. KeyAscii = 0 ' Is this the last loaded control? If txtText(Index) Is mcolLoadedControls.Item(mcolLoadedControls.Count) Then ' Move focus to the first control. mcolLoadedControls.Item(1).SetFocus Else ' This must be the first control, so move focus to the last control. mcolLoadedControls.Item(mcolLoadedControls.Count).SetFocus End If End If End Sub
I copied this code into each of the other controls and tweaked the txtText references. I could have refactored the code into a generic Control reference that is called from each of the KeyPress events, but I chose not to because of the performance hit due to calling another subroutine.
In any case, if the user control is enhanced in the future to support another editable control type, perhaps a rich textbox, I’ll have to remember to add code in the KeyPress event handler.
This just made me think how I would deal with this kind of a bug in VB.NET. I don’t know if this is even an issue in VB.NET, but if it were, would it be easier to deal with?
In VB.NET, I’d probably solve this problem with a single routine that accepts the KeyPress event arguments. As I added and removed the controls, I could use AddHandler and RemoveHandler so the procedure is always attached to the first and last control that is added.
When support is added for the rich textbox, I wouldn’t have to worry about this issue since the procedures adding and removing the controls will automatically attach the KeyPress handler to the last remaining control, which could be the newly supported rich textbox.
Thinking about these kinds of things makes me impatient about digging into VB.NET for a useful project.