I have a VB6 app with a somewhat complication user interface screen. The UI
consists of a grid through which the user can navigate from entry to entry.
As each entry is focused, data is retrieved from the application database
(synchronous) while, at the same time, an embedded browser control is
implemented to bring up a web application interface for the focused entry.
This latter operation is inherently asynchronous.
If the user clicks reasonably, or even moderately quickly from entry to
entry the application behaves fine. However if the user will 'attack' the
interface by scrolling rapidly up and down the grid from entry to entry, up,
up, up, down, down, down, up, up, up, down, down, down etc. in rapid
succession, the application will throw an unanticipated application failure;
AppName has encountered a problem and needs to close. We are sorry for the
inconvenience. Etc. This particular type of error is trapped by the Windows
environment, it's not trapped within my application and so I can't take
steps to even trap this condition and rectify it. All I can do is try to
implement code which will prevent it.
What I've done is to insert Me.Enabled = False and Me.Enabled = True to
bracket the RowColChange event of the grid. This doesn't seem to be working
because it seems as though keystrokes which are queued up while the form is
disable are held in the queue and then fed to the UI as soon as the Form
becomes enabled again. Thus, locking the interface doesn't do anything to
cut down on the rapidfire navigation.
I've tried a couple of approaches to try to clear the keyboard buffer prior
to re-enabling the form, but noeither of these seem to work. I've tried a
DoEvents statement just prior to Me.Enabled = True. And I've tried to use
SetKeyboardState as well to flush the keyboard buffer, but neither of these
approaches seems to work. If these were working I'd expect to hit down,
down, down, down, down but just see the focused lineitem move down two rows
since after moving to the first row the interface would be locked, and if
the interface is ready to unlock just prior to the fifth down, I'd expect
keystrokes 2 - 4 to be flushed. But that's not happening. What's hapening is
the keystrokes are all queued, eventually the application UI gets
overwhelmed, and the application crashes.