VB6 Application Overwhelmed by Rapid User Interaction

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.

I appreciate any advice which you can provide.

Thanks!

Joseph Geretz

How about something simple like this:

Option Explicit
Private Declare Function timeGetTime Lib "winmm.dll" () As Long
Private lStartTime As Long
Private Const lWaitTime As Long = 200

Private Sub TextBox1_KeyDown(ByVal KeyCode As MSForms.ReturnInteger, _
ByVal Shift As Integer)

If timeGetTime() - lStartTime < lWaitTime Then
KeyCode = 0
Exit Sub
Else
lStartTime = timeGetTime()
End If

End Sub


RBS


"Joseph Geretz" wrote in message
news:%

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.

I appreciate any advice which you can provide.

Thanks!

Joseph Geretz

Thanks,

This approach essentially solves the problem. With the paradigm you
suggest, the form remains active, and keystrokes are discarded by the
application if it is not in a state in which it is prepared to receive
them. I simply implemented a form level variable to set a flag while a
retrieval is in progress. While that flag is true, any keystrokes received
by the grid are simply discarded.

This is working well and the app is stable now.

Thanks!

Joseph Geretz

"RB Smissaert" wrote in message
news:

How about something simple like this:

Option Explicit
Private Declare Function timeGetTime Lib "winmm.dll" () As Long
Private lStartTime As Long
Private Const lWaitTime As Long = 200

Private Sub TextBox1_KeyDown(ByVal KeyCode As MSForms.ReturnInteger, _
ByVal Shift As Integer)

If timeGetTime() - lStartTime < lWaitTime Then
KeyCode = 0
Exit Sub
Else
lStartTime = timeGetTime()
End If

End Sub


RBS


"Joseph Geretz" wrote in message
news:%

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.

I appreciate any advice which you can provide.

Thanks!

Joseph Geretz

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.

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;

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 appreciate any advice which you can provide.

While that flag is true, any keystrokes received by the grid are
simply discarded.