Closed JiFish closed 8 years ago
It'll be better if I just use an IntEnum
class to hold the keys. I'll get on that now. You'll be able to index it with CLK[key_name]
and check for membership by try/catching a KeyError
, or checking if key_name in CLK.__members__
For now though, to test if a x
is a valid key check if CLK_ESCAPE <= x <= CLI_Last
, and to perform an action on every key, do
for key in range(CLK_ESCAPE, CLI_Last + 1):
Corsair.SetLedsColors(1, CorsairLedColor(key, 255, 255, 255))
Thanks for replying and apologies in advance for stupid questions.
I'm using python 2.7 are enums available here?
So will this additionally solve the issue of getting a key's number from a user provided string of it's name? i.e. would this work?
'CLK_A' in CLK.__members__:
# do something
print CLK['CLK_A']
etc. I ask because I think it's friendlier to ask the user to put the key name in the config file, rather than it's id.
Enums are available via backport for any python version below 3.4
It would likely be
'A' in CLK.__members__
or
try:
CLK['A']
valid_key = True
except KeyError:
valid_key = False
Great, that's what I was hoping.
I've run into a slight problem.
CLK and CDC contain names that are not valid Python identifiers (e.g. CLK_1
-> CLK.1
, CDC_None
-> CDC.None
. Both raise SyntaxErrors
), you will have to index them in a non-normal way.
For example, for the 1
key, you can index it the following ways:
CLK._1
CLK[1]
CLK['1']
for the device capability None
CDC._None
CDC[None]
CDC['None']
All in all, not really a big deal. Only affects the programmer really, makes it slightly inconvenient.
The good news is that I've implemented easier membership testing. Now you can do
>>> 'A' in CLK
True
instead of the previous methods I showed you.
For the weird ones, you can do
>>> '1' in CLK
True
>>> '_1' in CLK
True
>>> 'None' in CDC
True
>>> '_None' in CDC
True
Unfortunately, you can't use the integer or NoneType values like you can to index.
I'll push an update later.
Oh wow, I just remembered, you can get the key ID from key name with Corsair.GetLedIdForKeyName
, so this issue technically can be closed, but the enum is more convenient. Also, the GetLedIdForKeyName
function returns the key code relative to logical layout (e.g., GetLedIdForKeyName('a')
on an AZERTY keyboard would return CLK.Q
instead of CLK.A
), which is quite useless unless you are trying to make animations or something.
GetLedIdForKeyName implements CorsairGetLedIdForKeyName which only takes a char not a string, so I was unsure how to check non-alphanumeric keys. If it's even possible that way. In fact based on the documentation, you can't even look up numbers and punctuation!
Input arguments: • char keyName - key name. [‘A’..’Z’] (26 values) are valid values.
Ah, that's incredibly dumb.
I assumed it was just for dealing with keyboards with alternate layouts: AZERTY, dvorak etc. Since it didn't seem to do what I wanted, I ignored it. :)
I'm taking a bit longer because I'm trying to abstract away the usage of ctypes structures and pointers and trying to give the developer the data directly, instead of letting them fend for their own. I'll have an update pushed out within 30 minutes.
Done! eb99b588eda4baa7bd4c72285534de7cd683659b
Note: It breaks pretty much everything, you'll have to redo many parts of your program. Sorry!
Nice, thank you.
In the project I am working on, I want the user to be able to choose a key in a configuration file. This has forced me to create a dict so I can reference key names. This is a shame, because it's basically repeating information already in cue_sdk.
This problem could be avoided if cue_sdk already provided the values in a dict. Making it easy to do stuff like:
etc.
Thoughts? I'm not hugely experienced in this area, so maybe there is something I am missing?