IR 5.x Feature Request

[Mark Pierson]

Not sure about the Pipe, some one might use that as well. I'll look in the key map and let you know.

That's not the pipe "|" character (char 124, 0x7C). I intentionally chose an extended (>128) character that's not available directly from the keyboard. Plus, it closely resembles a colon.

Should we assume that if you paste in for existing KM's or anything else we should override the note?

I need to do some more testing, but IR sometimes prompts that a key move is already defined (I say sometimes because it doesn't seem to be consistent). My opinion is that if you're pasting in a new key move, assume the new note (if present) is valid.

Please show me what the Upgrade Protocol that you used looks like. Did it look like the Upgrade Code with the ")' before the notes?

Here it is:

Upgrade Protocol 0 = 01 1A (S3C8) NEC 2DEV Combo
43 8B 42 8B 14 CF 44 08 08 01 18 01 06 01 18 03
39 D2 DC 11 94 08 B6 08 CA E6 10 02 08 08 37 0E
06 E4 05 03 E4 06 04 E4 07 05 E4 07 06 60 06 37
0B 05 E4 03 04 60 04 37 06 05 F6 01 04 7B 09 37
09 0C 37 01 03 46 29 0D 46 29 01 8D 01 36 E4 22
1E E4 23 1F 37 01 EB F6 01 36 E6 28 C1 60 03 E6
12 01 8B E4
End

I think the overall idea for notes is really going to be very helpful in IR.

Me too, or I wouldn't be adding the ability to KM.

[e34m5]

Ahh..looked like a Pipe. Ok no prob we'll use your new character " | ".

Any notes with a new paste will govern. The prompting I'm not sure of, I didn't touch that part of the code.

Tru it with a previous version and see if the probelm was there as wll.

Thanks again.

[Mark Pierson]

Ahh..looked like a Pipe. Ok no prob we'll use your new character " | ".

Just be sure to use ASCII 166 (0xA6), which Microsoft defines as the "broken bar" in the Unicode character set, and everything should be ok.

Let me know when you have another beta ready to be broken!

[e34m5]

Ok..try it now...I think I addressed all the issues you mentioned (remember to change the character separator)

The only thing I did not do is the macro import. I've never done one of those so I have no idea what the byte string might look like.

[Mark Pierson]

Ok..try it now...I think I addressed all the issues you mentioned (remember to change the character separator)

Tried it, and it's broken!

It seems like only the first defined key move is being recognized. It gets inserted, and the notes look ok, but any subsequent key moves are ignored. Here's the code I'm pasting in:

Upgrade Code 0 = 25 C4 (VCR/1476) GI Cable 0476
C4 08 72 FE 7C 61 B0 70 F0 D0 30 50 C8 98 0C 2C
AC 6C EC 88 CC 1C 9C 5C DC 48 A8
KeyMoves
2A F3 25 C4 1C«Day UP» ¦2B F3 25 C4 9C«Day DOWN
» ¦2C F3 25 C4 5C«Page UP»¦2D F3 25 C4 DC«Page
DOWN»
End

The only key move displayed in the Add dialog is 2A F3 25 C4 1C. The same problem occurs with the [Import] of Key Move code.

The only thing I did not do is the macro import. I've never done one of those so I have no idea what the byte string might look like.

I believe the [Import] button on the Key Moves and Macros tabs both use the same routine, so if it works for one, it'll work for the other. But it doesn't really matter since neither KM or RM do macros.

BTW, the notes for Device and Protocol upgrades appear to work properly.

[e34m5]

I copied the special character to one place but not the othe

Try it now.

[Mark Pierson]

I copied the special character to one place but not the othe

Maybe you should use a constant for that?

To start with, the notes are still converting to all uppercase (I forgot to mention that before).

This version is not quite there, but getting closer.

Key moves as part of an upgrade are now being parsed correctly, and they're all there. However, editing, or deleting and re-adding a device with different notes doesn't change the notes to the current ones.

The [Import] of Key Move Code seems to function properly, including updating notes for existing key moves (it also works when using the [Import] button on the Macros tab, so the same routine theory must be correct?).

FYI, the zip file contains 2 different exe's with slightly different names.

[Mark Pierson]

Here's the format I'm using for key move notes created by KM.

« (char 171) = start of note text
» (char 187) = end of note text
¦ (char 166) = field separator

«function_name[: function_description]»¦

For every key move created by KM, the note becomes the defined function name. If the user has also entered a description/note on the Functions sheet, that gets appended to the function name. So, if the function is called TV/Input and the description is Toggle input between ANT and Line, the embedded note becomes:

«TV/Input: Toggle input between ANT and Line»¦

If there's no description, then it is simply:

«TV/Input»¦

This way, all key moves pasted into IR will have at least the function name as the note.

As I said earlier, I've made it a user-selectable option by adding a checkbox on the Setup sheet: [ ] DISABLE Embedded Notes.

[e34m5]

To start with, the notes are still converting to all uppercase (I forgot to mention that before).

IR was allways converting to upercase, you did not notice because there weren't any notes before. I'll fix it.

Key moves as part of an upgrade are now being parsed correctly, and they're all there. However, editing, or deleting and re-adding a device with different notes doesn't change the notes to the current ones.

To make sure I understand you are re-adding the device after revising in KM...correct? So you are doing a new paste for the same upgrade.

[Mark Pierson]

IR was allways converting to upercase, you did not notice because there weren't any notes before. I'll fix it.

You might have missed it, but I noted it here. When I said I forgot to mention it before, I was referring to my initial comments on the first upload you did this morning.

To make sure I understand you are re-adding the device after revising in KM...correct? So you are doing a new paste for the same upgrade.

Correct. Revising in KM to change the notes. If I take the new code back to IR and do either an [Edit] of the exisiting upgrade, or [Delete] it (which doesn't delete the key moves) and then [Add], the existing key move notes are not updated to the new text.

[e34m5]

New one uploaded. However...

To make the case sensitive notes work I need you to make sure that the words Upgrade, Keymoves, End that KM outputs are already in UpperCase. It has to do with how IR was already parsing the info from KM. Should not be a probelm I hope.

As far as re-adding or re-pasting the same upgrade if one already exists IR assumes that it is not the same one since you have already associated that upgrade with a device. This part is deep in the IR code and I really don't want to mess with it. Try to re-add the same one and you'll see that IR then has two of the same in the devices tab.

So the possibilities are to delete the upgrade first or to remove the association in the general tab.

[Mark Pierson]

To make the case sensitive notes work I need you to make sure that the words Upgrade, Keymoves, End that KM outputs are already in UpperCase. It has to do with how IR was already parsing the info from KM. Should not be a probelm I hope.

There has to be a way to get around this. I don't think we want such a radical restriction in IR. What's going to happen when somebody tries to paste in an old block of code that doesn't have those words in uppercase? Not to mention all the other tools that create upgrade and protocol code that would need to be modified. IR should be case-insensitive when it comes to pasting in code.

To help me understand the problem from your point of view, does the conversion to uppercase occur before your notes parsing starts? If so, can that parsing be done before the conversion?

Can you tell me where this happening in the source? I'd like to take a look at the code (not that I'll understand it ).

[e34m5]

The existing code in IR looks for the special words like Upgrade or Keymoves. In order to make the proper comparison it forces the entire text to Uppercase so that the string comparison is valid. Unfortunately the Position function that is being used is case sensitive. I have searched and not found one that is case insensitive.

The conversion to uppercase happens before the new parsing routine I wrote. I am taking the info after the Uppercase.

Let me do some more reasearch and see what I can do.

[e34m5]

Ok solved the Uppercase thing and the pasting on top of an existing Upgrade.

Try it now.

[Mark Pierson]

Gave it just a quick test, and the uppercase problem seems to have been resolved.

I still don't see any change in pasting over an existing upgrade. The original notes are kept intact; new notes are not updated.

I'll test it some more later tonight when I get home.