JP1 Remotes

Support for special protocol builder and notes. You can downloaded here

IR 5.00

Thanks for all the hard work! It looks great!

It would be nice if the zip contained DecodeIR version 2.14 instead of 2.11.

Paul, I gather you found the problem while I was away. I just d/l'ed 5.0 and I can now see the Cancel/OK buttons. (In fact, there's even a little extra space below them.)

Thanks,
Don

Yeah boy. Some fiddling. I take then you are OK with the changes.

Oops. I forgot to update the dll. I just uploaded a new ZIP.

e34m5 wrote:Support for special protocol builder and notes. You can downloaded here

IR 5.00

Nice job Paul

I think this will make a lot of people very happy and make life much easier in general. Especially for me

It not only helps build new macros and keymoves it will help significanltly when decoding is needed to help yourself or others.

Tx

Yeah boy. Some fiddling. I take then you are OK with the changes.

Yes.

But, if you want to do some more fiddling, as I noted last night, there is now extra space below the OK/Cancel buttons - about the same amount of space that was previously between the key-field windows and the hex-display field and that seems to have disappeared. (The top of the hex-display field now butts directly up against the bottom of the key-field windows - on my display at least.)

Incidentally, what I'd really like to see now is a consolidated SPB/Keymove window. While it was an obvious development approach, I no longer see any need to make SPB a two-step process. Just as you don't display the SPB button when it's not required, it would be nice to have the full SPB functions available immediately upon clicking a SPB keymove under the main Keymove tab. Now that the resizing problems are out of the way, there's plenty of screen real estate available.

Just a thought,
Don

DGG wrote:

Yeah boy. Some fiddling. I take then you are OK with the changes.

Yes.

But, if you want to do some more fiddling, as I noted last night, there is now extra space below the OK/Cancel buttons - about the same amount of space that was previously between the key-field windows and the hex-display field and that seems to have disappeared. (The top of the hex-display field now butts directly up against the bottom of the key-field windows - on my display at least.)

Incidentally, what I'd really like to see now is a consolidated SPB/Keymove window. While it was an obvious development approach, I no longer see any need to make SPB a two-step process. Just as you don't display the SPB button when it's not required, it would be nice to have the full SPB functions available immediately upon clicking a SPB keymove under the main Keymove tab. Now that the resizing problems are out of the way, there's plenty of screen real estate available.

Just a thought,
Don

The space is the only way I could make this work and keep the relative positions.

The reason I made SPB a 2 step process is because not all Keymoves are SPB's.

I've encountered one minor annoyance.

Start a new file from scratch (either using File, New or just downloading the current remote contents) and select Save to name and save it. Make a few modifications and resave it. Now, try and close IR, open another file, or do a File, New, and IR still thinks the file contents have changed and prompts for it to be saved.

I haven't encountered this behavior when opening an existing file; only with new ones.

Hmm...I did not encounter that..I'll fix it.

Thanks.

Since the new IR file format is not compatable with any of the current tools (i.e. ExtInstall - first report here). I think it would be wise to at least include a special readme noting the changes and the workarounds required (not everyone will read the warning post buried in the beta thread).

Fixed saving issue. Added detailed explanation in "release notes" in reference to new file format.

New ZIP available.

I finally got around to trying IR version 5. I haven't done too much yet, but found one thing I think is a flaw.

The process of renaming the old .txt file and writing the new format one seems to happen when the file is opened rather than the first time it is saved. That is disturbing and often will be inconvenient (or worse) and just isn't the way people expect such changes to occur.

Opening the file should be a read-only operation. It should do the rename etc the first time you save a file that had been in old format.

johnsfine wrote: Opening the file should be a read-only operation. It should do the rename etc the first time you save a file that had been in old format.

Agreed. The new behavior is very annoying as I keep a read-only attribute on my files. The rename process still occurs in Win2k but under Win98SE it gives some stupid I/O error.

Paul,
I have a suggestion for 5.00 if I may. If someone is saving an IR file and they haven't added any notes or anything else that is only supported by the new version of IR, could you save the file in the old format.

This should enable people to just use the new IR even if they are also using some other utilities that have not yet been updated to handle the new format.

Without this change, some people may find that they need to keep 4.02 and 5.00 available.