RC5: keystrokes from dialogs leak into buffers

[astromme]

When I have the buffers dialog open (list-buffers) if I hold down Alt+D to close a bunch of buffers the Alt+D will "leak" into the buffer that normally has focus, deleting lines (Alt+D is mapped to delete-line).

This happens with other commands too.. after opening various dialogs, I'll have various letters show up in random places in buffers that had focus, and those files show the asterisk near the filename noting a change.  If I undo, they clean up fine, but these keystrokes should NOT have gotten there.

This is a common occurrence on Ubuntu - I don't recall having seen it in Windows.

[jporkkahtc]

I've had this happen on windows too.

[JeffB]

I see this frequently too. Something like "ctrl-f" to bring up the Find/Replace disalog and I immediately start typing, but the first few characters go into the edit buffer instead of the Find/Replace dialog.

[lambertia]

That explains the weird compilation errors I get sometimes!

[Graeme]

When I have the buffers dialog open (list-buffers) if I hold down Alt+D to close a bunch of buffers the Alt+D will "leak" into the buffer that normally has focus, deleting lines (Alt+D is mapped to delete-line).

This happens with other commands too.. after opening various dialogs, I'll have various letters show up in random places in buffers that had focus, and those files show the asterisk near the filename noting a change.  If I undo, they clean up fine, but these keystrokes should NOT have gotten there.

This is a common occurrence on Ubuntu - I don't recall having seen it in Windows.

I don't think holding down keys is a great idea.  In the list-buffers dialog you can use multi-select then press delete to close all the selected buffers.

[Graeme]

I see this frequently too. Something like "ctrl-f" to bring up the Find/Replace disalog and I immediately start typing, but the first few characters go into the edit buffer instead of the Find/Replace dialog.

That's a different situation.  You need to allow the dialog time to open, or keep it open.  It's likely possible to write a macro that buffers keypresses until the dialog is open, or maybe use the / command on the slick command line, or incremental search.

[hs2]

You need to allow the dialog time to open, or keep it open.

I think in general this should be handled gracefully by applications 'to do exactly, what the user wants it to do'.
Just my 2ct, HS2

[Graeme]

You need to allow the dialog time to open, or keep it open.

I think in general this should be handled gracefully by applications 'to do exactly, what the user want's it to do'.
Just my 2ct, HS2

Sure, it was reported here too
http://community.slickedit.com/index.php/topic,10511.msg44319.html#msg44319
so maybe it's being considered.  On my PC, the dialog comes up faster than I can type.

[astromme]

I see this frequently too. Something like "ctrl-f" to bring up the Find/Replace disalog and I immediately start typing, but the first few characters go into the edit buffer instead of the Find/Replace dialog.

That's a different situation.  You need to allow the dialog time to open, or keep it open.  It's likely possible to write a macro that buffers keypresses until the dialog is open, or maybe use the / command on the slick command line, or incremental search.

I'm not sold it's a different situation.  If I look at the buffers dialog, when I close a file the window outline appears to be redrawn - does this close and reopen the window?

Anyway, I agree with hs2 - this just needs to work.  Having keystrokes not go to the dialog that I just requested because I didn't wait long enough is not reasonable.