 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / Win API / June 2008VB6 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 >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. [quoted text clipped - 38 lines] > > 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 > How about something simple like this: > [quoted text clipped - 60 lines] >> >> 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. [quoted text clipped - 13 lines] > steps to even trap this condition and rectify it. All I can do is try to > implement code which will prevent it. I know you have worked around it now by ignoring the keyboard, but does telling the browser control to stop its previous download before starting the next help?  SignatureDean Earley (dean.earley@icode.co.uk) i-Catcher Development Team iCode Systems Hi Dean, > I know you have worked around it now by ignoring the keyboard, but does > telling the browser control to stop its previous download before starting > the next help? It's a fair point. I don't know. Possibly this would contribute to a solution. Thanks for the suggestion. I'll keep this in mind. 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 [quoted text clipped - 17 lines] > telling the browser control to stop its previous download before starting > the next help? > 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. In another post you state: > While that flag is true, any keystrokes received by the grid are > simply discarded. Does that mean that the user is held back from advancing too fast? I was just going to mention another approach that would allow the user to move the focus to the row they want, at the speed they want. If, instead of calling the DB and web page on a row change, you store the new row index in a queue, you could use a timer to read the queue and display the data. That way the user is simply filling a queue which can happen rapidly, and not overwhelm the system. The trick to keeping up with the user is, in the timer event, where you are going to get and show the data, you check the size of the queue. If the queue has more than one item, remove all but the last one and use that. The timer could be set at a rate that will not overwhelm the system, so that no matter how fast the user types, the data is called up at a moderate pace.... LFS >> If the user clicks reasonably, or even moderately quickly from entry to >> entry the application behaves fine. However if the user will 'attack' the [quoted text clipped - 31 lines] > so that no matter how fast the user types, the data is called up at > a moderate pace.... A similar approach is to disable and reenable a timer when a row is selected, then in the timer event, just get the latest row. This means it wont start getting anything for 20ms (for example) after stopping scrolling. I use this concept in a video progress slider very successfully. SignatureDean Earley (dean.earley@icode.co.uk) i-Catcher Development Team iCode Systems Hi Larry, > Does that mean that the user is held back from advancing too fast? Well, yes and no. In the absolute sense, the user can scroll through the grid as quickly as they wish, because data retrieval isn't triggered on the RowChange event, it's triggered by the KeyUp event. So the user can advance through the grid as quickly as they wish, simply by holding down the arrow key. Once the user picks the key up though, initiating a request for data, then at that point the user is prevented from continuing until the requested data is retrieved, since with my implementation keystrokes are discarded from the commencement of data retrieval until it has completed. > The trick to keeping up with the user is, in the timer event, where > you are going to get and show the data, you check the size of the > queue. If the queue has more than one item, remove all but the last > one and use that. Thanks for this suggestion. I will take a closer look at this. Joseph Geretz >> If the user clicks reasonably, or even moderately quickly from entry to >> entry the application behaves fine. However if the user will 'attack' the [quoted text clipped - 36 lines] > > LFS |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.