Could this be a bug ?

[ashotisatoshi]

Situation:

I'm doing a 'Replace' of my code for example
Search for 'foo' replace with 'bar'
and hit alt_r
As code::blocks finds each 'foo' I either hit 'Y' or 'N';

Problem:
If I hold down the 'Y' for a particular section of code which I know
all needs to be replaced, sometimes code::blocks (editor) treats the
'Y' as not a 'YES' but as me typing in the letter y into the code,
thus having the letter 'Y' mixed into my code..

[oBFusCATed]

Are you sure the keyboard focus is on the dialog (yes, no, all, cancel) and not on the editor?

[ashotisatoshi]

I guess that's the problem,

If I dont hold down the 'Y' key, rather tap it quickly it will replace correctly,
only when I hold it down the editor incorrectly directs the key press.

[oBFusCATed]

You can select some code before pressing ctrl-r, then click the all button - the replace will happen only in the selected block of code.

[BlueHazzard]

I guess that's the problem,

If I dont hold down the 'Y' key, rather tap it quickly it will replace correctly,
only when I hold it down the editor incorrectly directs the key press.

this is probably a wxWidgets / operating system issue. The replace dialog looses focus to the newly opened editor and so your y gets interpreted as a key pres.
The question here is, how do you control on what part you replace the text if you keep the key pressed. Isn't it jumping around so fast you can't detect if it is the correct place to replace the code? Wouldn't it be better, you follow the way as obfuscated mentioned and mark the code what is to be replaced and select replace all. So you have more control over the process.

What operating system are you using?

[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]

I guess it would be simple in enough to set a flag ( i.e in dialog ), so that any keypress

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.