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


.



Relevant Pages

  • Re: Unchecked_Conversion and task pointer.
    ... you should definitely use an interface. ... > entry call, and they will work as an entry in that case. ... > with such a procedure that you can do with an entry (other than requeue it; ... similarly to class-wide subroutines there could be class-wide entries. ...
    (comp.lang.ada)
  • [PATCH] Add a non-blocking I2C interface
    ... Here's the code that I have so far for adding a non-blocking interface ... But this mostly is using the queue entry for data, ... of the IPMI SMB driver. ...
    (Linux-Kernel)
  • Re: Unchecked_Conversion and task pointer.
    ... >> You can declare a task interface in Ada 200Y: ... be called as an entry. ... >> no one can figure out how a dispatching requeue could work - it couldn't ...
    (comp.lang.ada)
  • Getting prefix length for IPv6 interface address?
    ... What is the correct way to get the prefix length for an IPv6 interface? ... in FirstUnicastAddresses would map to the 2nd entry in FirstPrefix). ... calling GetAdaptersAddresses, it seems to work, but that's a little hack-ish. ... to workaround the FirstUnicastAddress and FirstPrefix lists being ...
    (microsoft.public.win32.programmer.networks)
  • Re: VB6 Application Overwhelmed by Rapid User Interaction
    ... 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 while, at the same time, an embedded browser control is implemented to bring up a web application interface for the focused entry. ... However if the user will 'attack' the interface by scrolling rapidly up and down the grid from entry to entry, up, ...
    (microsoft.public.vb.winapi)