Weird RMIR behaviour - 2 Roku upgrades

[Barf]

1. I uploaded this file. It contains two device upgrades, both using the NEC1 (005A) protocol. The DVD has device number 73. The "Cable" has device 108 and subdevice 104. Opening the DVD from the "General" tab is ok. Opening it from the "Devices" tab, and the device is suddenly 108, and there is a subdevice of 104 (the values from the other device upgrade): So the bug exists. Q.E.D.

2. I have tried Leonardo's patch, and it does not work at all, for example it "hangs" (sort of) when selecting the Devices tab.

3. I spent some time with the code. As I see it, the fundamental problem is that the actual device parameters is present in the Protocol class, where it does not conceptually belong; it belongs to the DeviceUpgrade class. It appears to be deeply used in the code, so it may be pretty involved to fix. (Protocol.getDeviceParmValues() has 14 usages...). Graham, are you there?

[lbschenkel]

2. I have tried Leonardo's patch, and it does not work at all, for example it "hangs" (sort of) when selecting the Devices tab.

Not sure what went wrong with your system. I'm quite sure the fix works, even if it doesn't it simply cannot make the UI hang, plus the very same code has been incorporated into the latest RMIR release.

[Barf]

I apologize for not giving a more precise bug description. However, consider the bug here. It appears to have your fix involved.

Setting a breakpoint in DeviceUpgrade( DeviceUpgrade base, DeviceButton newRestriction ) show that on line 152 parmValues gets a vector of length 0; previously it was a length 5 value.

If the refresh code in a table throws an exception, it can be called repeatedly, creating an apparent "hang".