specter333,
Thank you so much for supplying these functions. I've long planned to try and do this myself but never got around to it. Your library allowed me to get my USBUIRT out of the closet and finally put it to good use.
I noticed a few bugs in the USBUIRT_AirCode procedure though:
* The second parameter is Data instead of UserData, which is how it's referred to everywhere else, including the rtncode expression.
* The initial call to VarSetCapacity should have a size of 12 instead of 2048.
* The BatchLines and WinDelay values aren't restored because they are preceded by a return statement. (Actually this error exists in several of the USBUIRT.ahk functions)
* The callback is documented to not have a return value so I removed the rtncode expression and return statement entirely.
Here are the corrections:
Code:
USBUIRT_AirCode(IrEventStr,Userdata){
currentbatch = %A_BatchLines%
curentwind = %A_WinDelay%
SetBatchLines -1
SetWinDelay -1
VarSetCapacity(IrCode, 12)
DllCall("lstrcpy", Str, IrCode, UInt, irEventStr) ; Copy the string into the script's variable.
VarSetCapacity(IrCode, -1) ; Update the variable's internally-stored length to reflect its new contents.
SetBatchLines %currentbatch%
SetWinDelay %curentwind%
If IsLabel(IRcode)
GoSub, %IRcode%
;retcode := NumGet(IRcode,0) "-" Userdata
;Return retcode
}
Also, I've restored the BatchLines and WinDelay values before the branch to the user-supplied label. This should prevent the -1 values from causing trouble in the user code.
By the way, have you found that the SetBatchLines and SetWinDelay = -1 commands are absolutely necessary, and if so, wouldn't a Critical or Threads NoTimers accomplish the same without the need to save and restore the default script values? Just curious - I'm not really experienced with any of these commands and wondering out loud.
Finally, I encountered a few things that I haven't seen anyone else mention and I'm curious if this is just unique to my setup or if you or others have had this occur too. I'm using a Harmony remote, setup to send MCE remote codes.
First, I found a number of buttons returns two codes, alternating between button presses. For instance, pressing "Play" will result in one of the two codes 412E97F050F1 and 412E96F040F1, alternating with each new press of the button.
Second, I found a single button press can result in multiple calls to the callback routine so I get undesirable behavior. One "Up" button press might result in 3 calls to the up routine, and thus undesirable behavior. Even though "UP" generates two alternating codes, a single button press always generates multiple calls with only one of the codes. The next button press generates multiple calls with the alternate code. To deal with this I've added a repeat delay to my code - equivalent to how one configures keyboard repeating in Windows - and this solves the problem.
Finally, I have one button, the "Previous Channel" button, that generates multiple calls to USBUIRT_AirCode with different IRCodes with a single press. A single press results in 3 calls to the callback routine with 3 different codes in sequence: 4780000000A5, 4780000000EF, 4780000000AD. The solution for this problem is just to only recognize the last code as a button press and ignore the first 2.
In anyone's interested I'll post my code for configuring repeat button presses, and I've also modified USBUIRT_ReceiveIR() to accept an optional callback procedure that gets called with every button press after USBUIRT_AirCode has processed it. This allows the dll calls in the library to remain encapsulated, and gives the user the option of a single procedure that handles their button presses or a label/subroutine for specific buttons.
Anyway, thanks again for making this library available.
Login
Register
FAQ
Search
Use the IR button code from any remote as labels in your scripts.
