After awhile using Python 2.3 IDLE in Windows, the 
control keys such as Ctrl+C (copy) and Ctrl+V (paste) 
stop having any effect.  Menu pulldowns continue to 
work.

I have yet to notice what circumstances might trigger 
this behavior.

Logged In: YES 
user_id=149084

I haven't observed this behavior, nor heard of it before.
What version of Windows are you using? 

The keybindings are established in Tk just after IDLE
starts and are subsequently intercepted and handled
by the Tk library.

Do all the Ctrl bindings fail? Even Tk defaults like Ctrl-E,
which goes to end of line?

What about Alt bindings?

Do the Ctrl keys work in other applications after they 
stop working in IDLE?

Logged In: YES 
user_id=191709

I'm using WinXP Pro.

Given this has not previously been reported, I will do my best 
to gather data on your questions as I continue to use IDLE.  
Ideally, I will be able to duplicate it at will.  We shall see.

Logged In: YES 
user_id=80475

FWIW, I've had this happen also.  Unfortunately, I usually
have so much going on that I haven't been able to relate it
to a specific cause.

Logged In: YES 
user_id=149084

By any chance did NumLk get switched on?
I've heard that can cause problems.

Logged In: YES 
user_id=80475

Hey, hey!  That was a good hint.
It is the CAPS LOCK key that is that culprit.
That is a bit weird because other windows applications
like Excel and Word are not similarly affected by CAPS LOCK.

Logged In: YES 
user_id=149084

Hrm? The way Tk is supposed to work, if there is no binding
for a key + Shift, the Shift is ignored.  Or was there a Shift
binding in your case?   

Note that the Shift bindings had an error for which I recently
checked in a fix.  Latter due to be backported to 2.3.4.

Don't know it this helps Kirby Urner.

Logged In: YES 
user_id=149084

Although the Tk man pages state that extra modifiers are ignored
if not in the binding, that's not true for Shift (or Caps Lock).  I don't
see a good way to program around this, there are many bindings
native to tcl/tk like Ctrl-e which also don't work in conjunction with 
Shift.  I'm going to say that that's the way it is, and it's a *feature*
since you can assign different bindings for upper case letters.

You can always use the Options menu to add the shifted bindings,
since it's possible to have more than one keycode bound to a 
given event.

Playing with the following tcl/tk program is instructive:

wm title . BindTest

frame .top
pack .top -fill x

button .top.ctrly -text Control-y -command printcy
pack .top.ctrly -fill x

button .top.ctrlshift2 -text Control-Shift-@ -command printcs2
pack .top.ctrlshift2 -fill x

button .top.ctrlshift5 -text Control-Shift-% -command printcs5
pack .top.ctrlshift5 -fill x

proc printcy {} {
    puts Control-y
}

proc printcs2 {} {
    puts Control-Shift-at
}

proc printcs5 {} {
    puts Control-Shift-percent
}

bind .top <Control-y> printcy

bind .top <Control-Shift-at> printcs2

#bind .top <Control-Shift-percent> printcs5

# The Shift is not needed (but does no harm):
#bind .top <Control-percent> printcs5

# But the 'percent' is required, the lc key cap doesn't work:
bind .top <Control-Shift-5> printcs5

# space keysym is not the same for upper and lower case:
bind .top <Shift-space> {puts Shift-space}
bind .top <space> {puts space}

# Print the key being pressed:
bind .top <KeyPress> {puts **%K}

focus .tophydra /home/kbk/proj/tcl$ 

Logged In: YES 
user_id=80475

At least for Windows, this is *not* a feature.  The Windows
standard required these keys to be case insensitive (look at
MS-Word for a practical example).

Fixed by loading alternate upper-cased keys to config-keys.def.
See Lib/idlelib/config-keys.def 1.21.

Logged In: YES 
user_id=149084

OK, thanks for all that boring typing :-)

There is still an issue with Ctrl-A, Ctrl-E, Ctrl-K etc., the 
emacs bindings native to tcl.  I guess it will be a FAQ?

Logged In: YES 
user_id=80475

At least we covered the Windows standard keys.

A FAQ entry seems appropriate for everything else where case
sensitivity may be important.