From: Alex K. on 10 May 2010 09:28 Johnny, thank you for your response. That solution was the first that came to my mind. But it didn't work because: On the form, there are a lot of other controls: textboxes, combo lists, buttons, etc. When I disable SAVE button, input focus jumps to other control, which can be different depending on some conditions - somtimes, it can be another button which in turn receives keyboard events ... Things become even worse and messier "Johnny Jörgensen" wrote: > Why not just do: > > private void buttonSave_Click(object sender, System.EventArgs e) { > buttonSave.Enabled = false; > DoSomething(); > SaveObject(); > MessageBox("Object saved"); > buttonSave.Enabled = true; > } > > ??? > > /Johnny J. > > > > -----Ursprungligt meddelande----- > Från: Alex K. [mailto:AlexK(a)discussions.microsoft.com] > Anslaget den: den 7 maj 2010 22:14 > Anslaget i: microsoft.public.dotnet.languages.csharp > Konversation: how to clear keyboard buffer? > Ämne: how to clear keyboard buffer? > > Hi all > On my form I have buttonSAVE button. The buttonSave_Click procedure looks > like this: > > private void buttonSave_Click(object sender, System.EventArgs e) > { > DoSomething(); > SaveObject(); > MessageBox("Object saved"); > } > > When users use mouse to click the button, everything is fine. But there is > a > problem when they use space bar on keyboard: > if you move focus (using TAB key) to SAVE button and then press space bar > two times very quickly, the save procedure successfully executes without > showing confirmation MessageBox. I guess, MessageBox does not appear on > the > screen because second stroke of space bar closes it before it is drawn. > As a result, user does not confirmation that object is saved. Even worse, > if > you press space bar 4 times, the object will be saved 2 times without > confirmation! > > I'd like to make sure user always gets the confirmation, i.e. MessageBox > always shows and waits until user closes it explicitly, ignoring all > pending > key strokes that might be in the buffer at the moment when SaveObject() > procedure ends. > > I tried to call Application.DoEvents() right before MessageBox.Show, but > that resolved only part of the problem: if I hit space bar twice, I will > get > eventually two MessageBoxes, but object is already saved twice when I see > the > first message box! All this is extremely confusing. I'd like to avoid > second > saving until user sees and aknowledges first confirmation. I think, if I > could clear the keyboard buffer before showing MessageBox (as I used to do > in > MS DOS), that would resolve the problem. > > Is there not-very-tricky way to do this? > Thank you > > . >
From: Alex K. on 10 May 2010 09:53 Peter, thank you for your response. I tried your solution. Unfortunately, it did not work. Yes, I can control the duration of my own modal dialog. Even better, I can use only MouseClick event of OK button, forcing user to always use mouse to aknowledge the confirmation, but ... If I press space bar 4 times very quickly, by the time my _first_ dialog appears on the screen, object is already saved _twice_, as I can see in database, and in console.debug lines. It looks like modal dialog stops the execution only after it is drawn on the screen, while keyboard events are placed in a queue that is separate from GUI and is moving faster. Probably, I will ask users always use mouse when clicking on SAVE button, and if they agree (hopefully) I'll ignore Click event and move all the SAVE code to MouseClick event. Thank you "Peter Duniho" wrote: > Alex K. wrote: > > [...] > > I'd like to make sure user always gets the confirmation, i.e. MessageBox > > always shows and waits until user closes it explicitly, ignoring all pending > > key strokes that might be in the buffer at the moment when SaveObject() > > procedure ends. > > The user _does_ always get the confirmation. They just happen to > dismiss it before it's been around long enough for them to see it. > > As for clearing the keyboard buffer, no….NET doesn't have anything for > that. But even if it did, it wouldn't help. There will _always_ be a > point in time during which the user can enter input that would dismiss > the MessageBox before the user's had a chance to see it. > > A better solution would be for you to implement your own modal dialog > for the purpose. It's fairly trivial to design a regular Form sub-class > that will show the information the way you want. > > Once you've done that, you can include a timer in the Form, override the > OnFormClosing() method, and if the timer hasn't expired yet, cancel the > close. That will ensure that any input to close the Form sub-class > before whatever minimum time you choose has passed will be ignored. > > Pete > . >
From: Peter Duniho on 10 May 2010 11:50 Alex K. wrote: > Peter, > > thank you for your response. I tried your solution. Unfortunately, it did > not work The suggestion I offered will work to correct the problem you originally described. > Yes, I can control the duration of my own modal dialog. Even > better, I can use only MouseClick event of OK button, forcing user to always > use mouse to aknowledge the confirmation, but ... If I press space bar 4 > times very quickly, by the time my _first_ dialog appears on the screen, > object is already saved _twice_, as I can see in database, and in > console.debug lines. That's a completely different issue, which you would have to solve a completely different way. Such as, not allowing new input to save an object until you're done processing a previous input to save an object. I agree with Harlan's point that you seem to be trying to protect stupid users from themselves, which is a futile goal in most cases. But the fact is that in this particular case, there are solutions available to you that don't involve clearing the input buffer. > [...] > Probably, I will ask users always use mouse when clicking on SAVE button, > and if they agree (hopefully) I'll ignore Click event and move all the SAVE > code to MouseClick event. If you are trying to help the user, making your program less convenient to use is probably not the right approach. Pete
First
|
Prev
|
Pages: 1 2 Prev: help me! Next: Delegate Called via System.Reflection.Emit Returning Wrong Value |