scouchman
Joined: 28 Apr 2004
Posts: 45
|
 Posted: Mon Mar 20, 2006 10:39 pm Post subject: NumLock Detector |
 |
|
Finally I have a generic enough bit of code I can share!
| Code: | #InstallKeybdHook
#Persistent
SetTimer, NetMeetingNumLock, 1000
return
NetMeetingNumLock:
IfNotEqual, Skipcheck, 1
{
IfWinExist, NetMeeting -
{
NLstate := GetKeyState("Numlock", "T")
Skipcheck = 1
SetNumLockState, AlwaysOff
}
}
IFEqual, Skipcheck, 1
{
IfWinNotExist, NetMeeting -
{
IfEqual, NLstate, 1
SetNumLockState, On
Else
SetNumLockState,
Skipcheck = 0
}
}
Return |
Okay, so where I work, we use NetMeeting all the time to connect to client laptops remotely. The IBM T43 for some reason detects the Numlock state through the netmeeting and turns it on on the T43. And when the netmeeting is disconnected, it leaves it on on the T43. This script will force Numlock to stay off only when Netmeeting is running, and it will return the Numlock state after Netmeeting is gone.
(For more general use, I know there are some games that for no good reason turn off Numlock, and this could be modified for that, or hopefully other uses)
So two questions:
1. is there any way to optimize this further?
2. A weird situation occurs with other laptops having this on their systems. If whoever is running this, has their own laptop Numlock on (personally, I don't know anyone who does), so "uio" would type "456", then this script appears to work fine except:
on a HP/Compaq 6000, it says that numlock is back on, but it isn't. You'd have to manually hit numlock twice (off, then back on) to turn it back on.
On a Toshiba M2, when the Numlock turns off, it actually sets the "uio" to left arrow, null, right arrow. Turns back on okay, though.
Any of the scenarios I've run, it works fine with an external keyboard connected, so I'm not really concerned, but any clue why these laptops do the weird things?
_________________
Scott F Couchman |
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
