odd error
Alex Hall
In the same program I wrote about yesterday, I have a dictionary of
keystrokes which are captured. I just tried adding a new one, bringing
the total to 11. Here are entries 10 and 11; 10 has been working fine
for months.
10 : (57, win32con.MOD_CONTROL),
11 : (99, win32con.MOD_CONTROL | win32con.MOD_SHIFT)
Now, though, when I press ctrl-shift-c (keystroke 11), nothing
happens. Pressing any other keystroke after that will crash the
program with some sort of Python internal com server exception that I
have never seen before. When set to a keystroke I already use, such as
#10, the function called by #11 works just fine. Does anyone see a
problem with the above syntax? The trouble almost definitely has to be
there; again, using an already-working keystroke instead of making a
new one works perfectly, it is just when I add this new one that
things break.
--
Have a great day,
Alex (msg sent from GMail website)
meh...@gmail.com; http://www.facebook.com/mehgcap
Ulrich Eckhardt
> Now, though, when I press ctrl-shift-c (keystroke 11), nothing
> happens.
Control-C sends a special signal to the console, like Control-Break.
> Pressing any other keystroke after that will crash the program
> with some sort of Python internal com server exception that I
> have never seen before.
Neither do I, in particular since you don't share that rare gem with us. ;)
Uli
--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
Alex Hall
hotkeys and all others work fine. You made me discover something,
though: the error only happens if ctrl-shift-c is pressed when in the
shell from where the program was run; when pressed anywhere else, the
keystroke does nothing at all. Is there something I am missing about
these keystroke dictionaries? It seems like they do not work unless
the keycodes are in numerical order and are not separated by more than
one number. Currently, my dictionary consists of the numbers 1-0 on
the top of the keyboard, but adding any other keycode, like the 99 in
my original message, will cause that keystroke to do absolutely
nothing. Thanks to your response, I suspect the problem is something
to do with the keypress being captured by the shell. Still, not being
able to use anything except numbers is very annoying!! Why would this
be happening?
> --
> http://mail.python.org/mailman/listinfo/python-list
Tim Golden
> Hi all,
> In the same program I wrote about yesterday, I have a dictionary of
> keystrokes which are captured. I just tried adding a new one, bringing
> the total to 11. Here are entries 10 and 11; 10 has been working fine
> for months.
>
> 10 : (57, win32con.MOD_CONTROL),
> 11 : (99, win32con.MOD_CONTROL | win32con.MOD_SHIFT)
>
Ctrl-C (with or without any other modifier) has a special meaning
which overrides any hotkeys. You may be able to do something by
adding a break handler through SetConsoleCtrlHandler (exposed in
win32api). But it would obviously be a special case outside your
normal control flow.
TJG
Tim Golden
... or you could use SetConsoleMode to disable input processing. But
that would only work (I think) in one console, not at a global level.
TJG
Alex Hall
have disappeared. However, now the function that should be called is
not. As I said in a previous message, I have always had trouble with
this sort of keystroke dictionary. It seems like, if a keycode is out
of order or not one more than the number before it, the function to
which it is tied will not get called. I am using the message looping
mode from Tim Golden's website, and it works beautifully until I try
to put an out-of-sequence keycode into the keystrokes dictionary. The
dictionary contains numbers 0-9 (48-57) and all is well, but when I
put in this 107 code then the function tied to 107 is not called, yet
the ones tied to 48-57 still work normally. Why would the sequence
matter, or does it not and I am doing something else wrong? Here is a
sample of my dictionary:
keys.append({
1 : (48, win32con.MOD_CONTROL),
2 : (49, win32con.MOD_CONTROL),
3 : (50, win32con.MOD_CONTROL),
4 : (51, win32con.MOD_CONTROL),
5 : (52, win32con.MOD_CONTROL),
6 : (53, win32con.MOD_CONTROL),
7 : (54, win32con.MOD_CONTROL),
8 : (55, win32con.MOD_CONTROL),
9 : (56, win32con.MOD_CONTROL),
10 : (57, win32con.MOD_CONTROL),
11 : (107, win32con.MOD_CONTROL | win32con.MOD_SHIFT) #never calls
its #function, and note that it is not in the sequence of the other
ten
})
and here is a list of functions tied to it:
funcs.append({
1 : exitProgram,
2 : arm.sayLoad1,
3 : arm.sayLoad2,
4 : arm.sayLoad3,
5 : arm.sayLoad4,
6 : arm.sayProcAvg,
7 : arm.sayUsedRam,
8 : arm.sayDisk1Info,
9 : arm.sayDisk2Info,
10 : nextMode,
11: clipboard.toClipboard
})
If I were to tie clipboard.toClipboard to any of keys 1-10 (0-9, or
48-57) then it would work fine; it is when the 107 shows up that the
function is not called, and this is a huge limitation for the rest of
the program since I am stuck with just the ten numbers available on
the keyboard. Any suggestions would be great!
On 3/9/10, Tim Golden <ma...@timgolden.me.uk> wrote:
> On 09/03/2010 13:55, Alex Hall wrote:
>> Hi all,
>> In the same program I wrote about yesterday, I have a dictionary of
>> keystrokes which are captured. I just tried adding a new one, bringing
>> the total to 11. Here are entries 10 and 11; 10 has been working fine
>> for months.
>>
>> 10 : (57, win32con.MOD_CONTROL),
>> 11 : (99, win32con.MOD_CONTROL | win32con.MOD_SHIFT)
>>
>> Now, though, when I press ctrl-shift-c (keystroke 11)
>
> Ctrl-C (with or without any other modifier) has a special meaning
> which overrides any hotkeys. You may be able to do something by
> adding a break handler through SetConsoleCtrlHandler (exposed in
> win32api). But it would obviously be a special case outside your
> normal control flow.
>
> TJG
alex23
> Why would the sequence
> matter, or does it not and I am doing something else wrong? Here is a
> sample of my dictionary:
Showing us the code that handles the dictionary lookup + function
calling would probably help us a lot more here.
Steven D'Aprano
> Okay, I changed the keycode from 99 (c) to 107 (k), and the errors have
> disappeared. However, now the function that should be called is not. As
> I said in a previous message, I have always had trouble with this sort
> of keystroke dictionary. It seems like, if a keycode is out of order or
> not one more than the number before it, the function to which it is tied
> will not get called.
Dictionaries aren't ordered, that can't be the problem.
> keys.append({
> 1 : (48, win32con.MOD_CONTROL),
> 2 : (49, win32con.MOD_CONTROL), [...]
Dicts don't have an append message. Why are you building a list and
adding a dictionary to it?
The question is, how many such dicts are in the list, and which one are
you searching for the function? Is it possible that the problem is that
you have multiple dicts in the keys list, and then perform your look-ups
on the wrong one?
Likewise for your list of functions:
> funcs.append({
> 1 : exitProgram,
> 2 : arm.sayLoad1, [...]
Perhaps all you need is a single dict, mapping characters to functions:
funcs = { # Just a dict
# keycode: function
'q': exitProgram,
'a': arm.sayLoad1
# etc.
}
Then whenever you get a keyboard event, convert it to the character:
keycode = 113
c = chr(keycode)
funcs(c)()
--
Steven
Tim Golden
> Perhaps all you need is a single dict, mapping characters to functions:
>
> funcs = { # Just a dict
> # keycode: function
> 'q': exitProgram,
> 'a': arm.sayLoad1
> # etc.
> }
>
>
> Then whenever you get a keyboard event, convert it to the character:
>
> keycode = 113
> c = chr(keycode)
> funcs(c)()
FWIW (altho' it's not clear from the OP's code) he's basically
doing this:
http://timgolden.me.uk/python/win32_how_do_i/catch_system_wide_hotkeys.html
which uses the dictionary keys as an id in the call to RegisterHotKey.
Obviously, that doesn't explain why he's building lists of dictionaries.
TJG
Alex Hall
here, but I have it working. I apparently have to use the ascii for
capital letters if I am capturing the shift modifier, not the
lowercase ascii. Using 67 instead of 99 works as expected.
I use append because the program has three different modes.
Eventually, each mode may have its own keystrokes. When the user
switches modes, the previous mode's keystrokes are unregistered and
the new keystrokes, keys[currentModeNumber], are registered. The same
with the functions; when a function is called from the dictionary, it
is called using funcs[currentModeNumber]. Again, this lets me put all
my functions into one big list, where each member of the list is a
dictionary. I probably have the terminology wrong, but hopefully that
makes sense. Sorry for not explaining that earlier, but I was just
looking for problems in the key codes. Thanks for your help!
On 3/10/10, Tim Golden <ma...@timgolden.me.uk> wrote:
> On 10/03/2010 09:16, Steven D'Aprano wrote:
>> Perhaps all you need is a single dict, mapping characters to functions:
>>
>> funcs = { # Just a dict
>> # keycode: function
>> 'q': exitProgram,
>> 'a': arm.sayLoad1
>> # etc.
>> }
>>
>>
>> Then whenever you get a keyboard event, convert it to the character:
>>
>> keycode = 113
>> c = chr(keycode)
>> funcs(c)()
>
> FWIW (altho' it's not clear from the OP's code) he's basically
> doing this:
>
> http://timgolden.me.uk/python/win32_how_do_i/catch_system_wide_hotkeys.html
>
> which uses the dictionary keys as an id in the call to RegisterHotKey.
>
> Obviously, that doesn't explain why he's building lists of dictionaries.
>
>
Tim Golden
> I am honestly a bit lost as to why keys.append() is not a good choice
> here, but I have it working.
That's ok; it's just not clear from the context why you have a list
of dicts but your comment about different modes explains that.
> I apparently have to use the ascii for
> capital letters if I am capturing the shift modifier, not the
> lowercase ascii. Using 67 instead of 99 works as expected.
That's probably because the os is "preprocessing" the keystroke so
that shift-a returns "A" and not "a". You might find that you don't
even *need* the shift modifier in those circs.
If I get the time this pm, I'll try to put together some example
code which runs to more than 10 items in a dict just in case there
is some bizarre cornercase which is causing a problem but I honestly
doubt it.
TJG