ID:158509
![]() Aug 13 2009, 7:38 pm
|
|
Is there any way to detect when a key, ANY key, has been pressed, and then report that somewhere in the game without having to override every key in the interface macros manually?
|
You could try using javascript like that old key handler library did, but I'm not sure of the exact method. I believe it required keeping constant focus on an invisible browser window.
|
Falacy wrote:
You could use a code loop to auto-create a macro for each key. How would you go about doing that? |
mob/verb/KeyPressed(var/Key as null|text) That'll get all the basic letters a-z. |
Falacy wrote:
> mob/verb/KeyPressed(var/Key as null|text) That'll get all the basic letters a-z. Not exactly control over the entire keyboard, especially Shift+Tab kind of stuff... Makes it kind of hard to route every key press through a certain datum. |
Foomer wrote:
Not exactly control over the entire keyboard, especially Shift+Tab kind of stuff... Special keys will have to be added (like tab) but you can setup the shift/ctrl/up thing by setting the name to something like SHIFT+[Key] |
That makes for 864 possible combination when you include the alphanumeric keys along with everything in that extra macros page (Tab, numpad, etc), with eight possible combinations of Alt, Ctrl and Shift each.
So it looks like I'd have to specify a macro interface to modify, add all possible macros at the start of the game, and along with that, create proc definitions for all 864 possible procs, since we're using Call()() here as having a switch() would be atrocious. BTW, anyone know how to tell winset() to create new macros using associative params? Eg: var/list/macros = list() |
Garthor wrote:
You can just call one verb and use the key as an argument. I'm attempting to use this in a library and it would be much more appealing to have people call datum.ShiftA() and a few other procs than to have them make their own proc with a switch statement which must account for every key stroke that they want to use. |
switch(X) or proc I'm not seeing any gains in ease of use or sanity, here. They seem to be BASICALLY the same, only the first one is more flexible. |
This is a moot point. Go back and answer the question in [link] if you want to be helpful. :P
|
Something easier could be using hascall() and call()(), which would allow you to define the procs and not have to worry about making them all, so long as you decide definitely on a naming convention for the procs.
|
Not that I know of. Depending on what you mean by manually... You could use a code loop to auto-create a macro for each key.