User forums > General (but related to Code::Blocks)

Could this be a bug ?

<< < (2/2)

ashotisatoshi:

I assumed it would be a scintilla or wxwidgets issue..

I guess it would be simple in enough to set a flag ( i.e in dialog ), so that any keypress
are ignored to the editor
using windows 10,
but problem occurs on all windows

oBFusCATed:

--- Quote from: ashotisatoshi on May 28, 2017, 11:51:47 am ---I guess it would be simple in enough to set a flag ( i.e in dialog ), so that any keypress

--- End quote ---
Focus issues are never simple nor easy to fix. :(

Jenna:
The problem is, that the confirmation dialog closes a short time and before it reopens the keyrepeating kicks in and the editor has the focus for a short time.
The easiest way to avoid this is to use the replace-in-selected-text-feature as mentioned by oBFusCATed.

The real bug is, that the replace dialog counts all added chars as replaced chars.

ashotisatoshi:
@jens,

Exactly what I suspected,  as it is also visually apparent when I hold down
the 'Y' key the dialog opens/closes after each replace ( very quickly of course ) ..
and the OS is redirected the held 'Y' key to the editor when the key repeat
event fires and the dialog is in between closing and reopening ( hiding / showing )

Confirmed:  I always have my keyboard repeat/delay to the shortest possible;
I just decreased the keyboard repeat rate a smidgen and the editor operated correctly...

Possible solution:
I don't know anything about code::blocks/wxwidgets under the hood - but maybe
lose/regain focus in between hiding / showing the dialog. ( i guess this can be done faster than
the keyboard repeat speed )

Anyway - it's not really a bug... - but it a tiny annoyance when working with very large files
and when doing large scale search/replace

oBFusCATed:
The only real fix for this problem is to not hide the dialog and always keeping the focus in it.

Navigation

[0] Message Index

[*] Previous page