If the main thread is staying responsive, so that the UI is responsive, the keystrokes will appear in the current control in the UI -- they will not (need to) be buffered anywhere. If the UI is not responsive, then you can't be running any code (other than a "keyboard hook") that can see the keystrokes in order to buffer them.
Is this an example of what you're trying to do? The user has put in an "incident number" (in your bug tracking system), and the request to get data about the incident (from a database or web service or remoting call) has not yet returned -- but you want to let the user type into the "Add comments" control on the incident form that hasn't yet been displayed. If that's what you want, I _think_ that if you keep the UI responsive (by using an asynch call to retrieve the info) the keystrokes will appear normally when the form finally appears (in the control that first gets the focus). However, it's also the case that if there's an error returned (e.g. "incident 123 not found") those same keystrokes will be played into the error dialog -- and if one of the keys is Enter, it may clear the dialog. (But that's sort of the user's fault. Avoiding having a "default button" on the error dialog might help avoid that problem.) I suppose you could make your app display the blank incident form (with focus in the "Add comments" control) without waiting for the server response, and fill it in when the response comes. However, that assumes that the control into which the user is typing ahead will always be blank -- hence my "Add comments" contrived example. (You should not want to be doing a keyboard hook; it's traditionally been quite painful. There's a set of tools from Desaware that purport to make it [much] easier, but I have not used them.) Good luck... At 10:19 PM 6/23/2005, Jonathan wrote >My question is how we cache the keystrokes or just let the system to do it. >Does it have any build-in keyboard buffer that we can manipulate? For >example, we tell the system to stop generating any key event and store the >keystrokes until we say so. Otherwise, we have to manually catch all key >events and put into our buffer then replay the action later. > > >-----Original Message----- >From: Unmoderated discussion of advanced .NET topics. >[mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill >Sent: Friday, 24 June 2005 11:52 AM >To: [email protected] >Subject: Re: [ADVANCED-DOTNET] Keyboard events > >If you do the request-and-wait on a different thread, for example by using >the thread pool, I'd think that the user could type ahead normally. The >main app thread won't be "tied up" if the GUI thread isn't stuck waiting for >the response. > >At 08:53 PM 6/23/2005, Jonathan wrote >>Actually, it is a server-client application. We would like to allow the >user >>to typing ahead during waiting for the server respond. Therefore, we need >to >>capture the user action and take effect later. Originally, it is a command >>based application. Now, we are trying to build a GUI and match the original >>command. >[snip] J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
