JP1 Remotes

e34m5 wrote:No prob..I'll put a messsage on not save until you choose. Keep in mind that you will receive two messages then.

One for the buffer as you see today and another for the notes.
...
Not so easy my friend. In IR there isn't a flag per se. What happens when a file is opened the entire remote file is loaded into an array called Loaded.

During the time you work in IR another array called Buffer stores the all the new values.

When exiting (saving) the contents of the two are compared and if different you see the "Buffer has changed" note.

So because one could change notes w/o changing the IR file I think we need two separate checks.

I don't see any need for 2 messages, and I would find this very annoying (IR puts out too many messages as it is).

The way I see it, it shouldn't be that hard to fix this in a sensible way. When an IR file is opened and the "loaded" array is loaded, you should also load an array called "notes-old". Then as the notes are added/changed, you should load the new version into an array called "notes-new".

Then when exiting and the "loaded" vs. "buffer" comparison is made, you should also do a "notes-old" vs. "notes-new" comparison. If either test fails (ie, the "loaded" or "notes-old" tests) you would put out 1 message asking the user if they want to save their changes.

If they answer "yes", you should then see which file was changed and perform the updates.

Regarding the notes file, if the new file is empty I think you should delete the notes file rather than replacing it with an empty file.

Somethings just occurred to me that may or may not be a problem with this. Let's say I create a file called robs-remote.txt and I add a bunch of comments (and save it). I then load this file into my remote and do further changes using the remote itself and then re-download. At this point IR doesn't have a file name in play. Next, I save the downloaded memory image over my old robs-remote.txt file. In this circumstance, I think I would like all my old comments to remain active, even though there wouldn't have been any comments associated with the downloaded image per se.

Ok...I think i've captured the whole save thing..try it now.

I've run some tests with this newest version and things seem to be working well. I did the following:

1) Opened a saved IR file and changed only a keymove. It prompted me to save when I exited, as expected.

2) Opened a saved IR file and changed only a note. It prompted me to save when I exited, as expected.

3) Opened a saved IR file (which had a single note) and deleted the note. It prompted me to save when I exited, and it deleted the note file associated with the IR file.

4) Opened a saved IR file, added a note and performed a save as. It correctly associated the note with the new file rather than the old, as expected.

Those are about the only things I could think of to try to break it. Everything seems to work as I would expect. Good work Paul.

Matt

The Robman wrote:Somethings just occurred to me that may or may not be a problem with this. Let's say I create a file called robs-remote.txt and I add a bunch of comments (and save it). I then load this file into my remote and do further changes using the remote itself and then re-download. At this point IR doesn't have a file name in play. Next, I save the downloaded memory image over my old robs-remote.txt file. In this circumstance, I think I would like all my old comments to remain active, even though there wouldn't have been any comments associated with the downloaded image per se.

I think the way Paul implemented this with a matching file rather than including it in the IR image addresses this. If you upload an image then download an image and save it with the same name it will pick up the matching notes file automatically. If you create a new file but want to use the notes from another IR file all that needs to be done is to make a copy of the file or rename it to match the new IR file. Ofcourse this only works if it is the same remote and would not com-pletely work if it was say and 2116 and an 8811 since only some button names would match.

I actually did that already since I keep two files for each remote. for ex. One called "RS-2116 Current.txt" and the other called "RS-2116 Test.txt". I just made a copy of the Current file and renamed it to Test and bingo, there they were.

Maybe this is one reason why the notes files should be kept separate rather than merged into the IR image.

The only problem that I really have with the separate file is remembering to include the notes file if I post it or send it to someone and they want or need the notes.

Nils found a tiny glitch with the save file stuff. I'm holding off on a new build in case there is more.

BTW, tx Matt

Found one minor problem as I was working with my remote config in the new beta of IR. I added a note to one of my macros, and then decided later that the macro was self explanatory and deleted the note. When I clicked OK in the Macro dialog, I got a "List index out of bounds (1)" error. However, if I click OK a second time the dialog closes without any errors. Sounds like a pretty minor thing to me, but a problem nonetheless.

Regards,
Matt

Hey Matt...in doing what I think you are I did not get any messages. If you could enumerate exactly what steps you took i'll attempt to replicate.

Don't know why I keep trying, but....

Enter a note (I used "123") for each of 20 sequential macros/keymoves. No saves in between; just keep entering notes. After 10 or 12, you should notice a response slow-down. At 15, it takes several seconds to process the note. Now, Save the file. That process, (on my computer, at least) takes 30 seconds. Each additional note before save doubles the response time and more than doubles the save time. (Note also my posts of last week about extraneous spaces which, of course, are no longer evident since IRBeta now strips them out before saving.)

With the Windows Task Manager/Performance in view, you can see the computer go to 100% usage for extended periods.

It may be another "XP thing" but, in any case, I won't raise this issue again.

Don

Don:

I had never tried that before..you are correct. I'll look into it.

Do not be discouraged, you are a valuable member of this beta group.

If any one should be discouraged it's me. After all every time I think I have it something else comes up.

I know sooner or late we'll get there.

e34m5 wrote:Hey Matt...in doing what I think you are I did not get any messages. If you could enumerate exactly what steps you took i'll attempt to replicate.

Trying to reproduce it myself, I find that not all macros do this... I find this quite odd, because I should think that if something was wrong with the macro (therefore causing an error), it would give me that error regardless of the status of the note.

I have posted the IR text file which exhibits this problem in the Diagnosis area of Yahoo. The exact steps I take to reproduce this is to add a note to one of the first two macros (Phantom1 or Phantom2) and OK out of the Macro dialog. Then go back into the Macro dialog and delete the note. Upon clicking OK after I delete the note, I get the "List index is out of bounds" error. Please let me know if I can help troubleshoot any more.

Matt

An observation on the use of notes that you may wish to consider in an future production release.

Perhaps it's the nature of my notes, but I would often find them more useful if they were available in the SPB dialog where they could then be created/reviewed in association with the "decoded" keymove.

Don

Don, are you looking to have them in both places? (Regular keymoves and SPB)

I have no problem with that I just want to make sure Paul does not just move them to the SPB which would make them unavailable to regular keymoves.

If someone finds them useful where they are now, I'd suggest just adding them to the SPB dialog. In fact, for consistency, they probably should be on the Keymove page as well.

Whatever's easiest.
Don

It would seem logical to have them in both places since I have notes on regular (to remind me what the button does) and SPB keymoves (to remind me what the SPB does). Paul's biggest challenge would be which one wins if someone changed it in both places. I guess for simplicity sake we should leave them where they are for now and let Paul think about it for the future. IMHO

I'm "cool with that". That's why I used the term "future production release" above.

As for changing in both places, if the change was made in the SPB dialog, the note in the Keymove dialog should be updated immediately upon the SPB being closed. So, there should never be two accessible versions of the note.

Don