IR.exe v8.00 Beta now posted

[mathdon]

Barf, it's not true that the codes are mod 2048, it's that the software I used converted hex to decimal mod 2048 (it pre-dated remotes that support larger setup codes). So your correction is necessary. HOM 0152 is invalid, HOM 0152+2048 is valid, I've tried them. I haven't added these new values to the URC-7780 RDF as it doesn't support codes > 2047.

I have no strong feelings either way about your suggestions re SetupValidation, though if the remote hangs on invalid codes I really don't want to give the user the option to upload them. What do others think?
_______________

Graham

[Barf]

... though if the remote hangs on invalid codes I really don't want to give the user the option to upload them.

Software contains bugs, we have just discussed one case where the software erroneously flags a setup as faulty. Sometimes the user has reason to do something a software considers silly. For this reason, a software should never act stubborn. IMHO.

[mathdon]

Sometimes the user has reason to do something a software considers silly. For this reason, a software should never act stubborn. IMHO.

I don't want to make it impossible to upload invalid codes, I only want to make it need an experienced user, such as one who could change the RDF SetupValidation entry if required. I want to prevent the inexperienced user, who doesn't know why this prohibition is present, from bypassing it easily, crashing the remote and blaming the JP1 forum for turning the remote into a brick.

I hope we can reach agreement on this as your comments have been very helpful to me. There is already an RDF entry called "UpgradeBug". How about replacing SetupValidation with an entry "InvalidCodeBug" which is (like UpgradeBug) omitted or zero for normal remotes but set to a nonzero value when the remote crashes in some way on invalid codes. This name implies something nasty without being too specific. When nonzero, IR would prevent upload of invalid codes - exactly as SetupValidation=Enforce does now. When zero, if [SetupCodes] section present then IR would behave as value Warn does now.

You also wrote

Introduce an IR-configuration option to suppress warnings for invalid setupcodes (or leave it out; the warnings are not intrusive).

I agree there is no merit in turning off the red "invalid" marking and banner when there is a setup codes section, but there is already an option "Suppress Messages" on the Advanced menu. I would suggest that when this is selected then the warning or enforcement messages on upload are turned off (and upload permitted even if bug present). If the user turns off messages and ignores the banner "Warning: Setup codes in red are invalid" then that is their responsibility.

I only want to change this once, so views please. Rob, it's your forum. I would like your approval before doing anything further on this.
__________________

Graham

[The Robman]

Sometimes the user has reason to do something a software considers silly. For this reason, a software should never act stubborn. IMHO.

I don't want to make it impossible to upload invalid codes, I only want to make it need an experienced user

I think I have the answer. There's already an Advanced menu option in IR where users can declare themselves to be "advanced" in some way, so maybe we could add an option like "Enforce Setup Code Rules" which defaults to ON, then if the user turns it off, all the "Enforce" rules become warnings instead. If the RDF option is set to "Warn", then the "Suppress Messages" option could also come into play where, if it's selected, the warning messages are not displayed.

However, for the remotes where the RDF option is set to Enforce, I don't want the Suppress Messages option to come into play, even for experts who un-select "Enforce Setup Code Rules". I don't see any valid reason, apart from debugging and testing, where an expert would want to load a bad setup code, so I think they can live with the warning. (If anyone disagrees with this, speak up).

[mathdon]

Rob, I think Barf is trying to make a logical distinction between the property of the remote (does or doesn't crash with invalid codes) which is properly an item for the RDF, and the behaviour of IR (does/doesn't warn or prevent invalid uploads) which he sees as properly a configuration item for IR. I don't think your suggestion meets that criterion. But it's a fine distinction, especially since the RDF has other entries that concern the operation of IR and RM, so my view is either leave things as they are or change it in a way that makes the distinction Barf is looking for.
______________

Graham

[Barf]

... so maybe we could add an option like "Enforce Setup Code Rules" which defaults to ON, then if the user turns it off, all the "Enforce" rules become warnings instead.

Then another IR-configuration option determines whether downloads should be refused if invalid setup codes are encountered, and the remote has HangsOnInvalidSetupcodes==true.

...i.e. almost identical. I do not think we really disagree. It is not a major issue either.

@mathdon: I checked a bit on my 7780 and 7781: the 7780 does not accept a code like 152, so your rdf seems correct (only mentioning 0167). However, also the 7781 rejects 0152, so it appears that the correct list is 0167, 2200-2215. (This answers your PM.)

I don't see any valid reason, apart from debugging and testing, where an expert would want to load a bad setup code

See previous paragraph. It is not "bad code", it is something that the software, possibly erroneously, considers bad.

[The Robman]

Rob, I think Barf is trying to make a logical distinction between the property of the remote (does or doesn't crash with invalid codes) which is properly an item for the RDF, and the behaviour of IR (does/doesn't warn or prevent invalid uploads) which he sees as properly a configuration item for IR. I don't think your suggestion meets that criterion.

The RDFs define what the remote will, and won't, let you do and IR is there to enforce the rules defined in the RDFs, unless the user explicitly says they want to override the rules. So why doesn't it meet that criterion?

I don't see any valid reason, apart from debugging and testing, where an expert would want to load a bad setup code

See previous paragraph. It is not "bad code", it is something that the software, possibly erroneously, considers bad.

From the POV of the software, it is indeed a bad code. If you believe that the software is erroneously flagging the setup code as bad, I believe you should have the ability to declare yourself an expert and proceed to load the bad code, but of course, if you do this via a WAV file and you lack the ability to undo the damage that you have done, it's on you for erroneously declaring yourself an expert. So I think we're on the same page.

[mathdon]

I do not think we really disagree. It is not a major issue either.

We seem to be debating a minor issue endlessly. There only seem to be three of us who feel strongly enough to contribute, me Barf and Rob. I would like to suggest that we agree on the following course of action. It involves the minimum of disruption to either me (with IR) or what others are currently doing (with modifying RDFs to include setup validation). For me I think it is a sufficiently small change that it doesn't require another Beta version. My proposal is:

The RDF and the Advanced options remain as at present. When Suppress Messages (IR Advanced menu) is Off, there is no change from present behaviour. When Suppress Messages is On, there is a change to the behaviour on attempting to upload a setup (or create a WAV file). The behaviour for Enforce becomes that for Warn, and that for Warn becomes that for Off.

With Suppress messages On, this means that Enforce and Warn still give red codes and a red Warning banner when invalid, but that for Warn there is no message shown on upload, and for Enforce there is a warning (but no prevention) shown on upload.

Could I have a simple Yes or No to this from Rob and Barf (but others feel free to comment if you disagree). As I said before, I really really want to do this only once. It is too minor to be worth any more hassle.
__________________

Graham

[Capn Trips]

You have a yes from me.

[The Robman]

Yes from me, that is exactly what I was proposing.

[mr_d_p_gumby]

Yes from me too.

[Barf]

I am not 100% happy with the suggestion; in particular that the option "Suppress messages" gets a complicated semantics, that is not conveyed by its name. But it has the definite advantage of being easy to implement, so "yes" from me.

[mathdon]

OK, thanks to everyone for their Yes votes. I've done it. I also noticed Rob's request on the IR 8.01 Wish List thread:

Here's another one that I'd *LOVE* to have taken care of. If I've selected Suppress Messages from the Advanced menu, I don't want to see the "The data has changed. Do you want to save the changes?" message.

It seems to me a bug that that message isn't suppressed, so I've sorted that out too. I've also updated the number tables from 446 to 447, to bring that up to date.

Does anyone want a Beta 10 posted with these things in, or can we wait for a general release, which I hope we are converging on rapidly now. I would intend to include the new version 0.13 of jp12serial.dll with the IR 8.00 general release unless I hear that it is not yet stable enough.
_________________

Graham

[Capn Trips]

... or can we wait for a general release, which I hope we are converging on rapidly now. I would intend to include the new version 0.13 of jp12serial.dll with the IR 8.00 general release unless I hear that it is not yet stable enough.
_________________

Graham

Go for it! (but keep the "wait" short )

[mdavej]

If I R-click in the notes section of the general tab in beta 9, I see 2 new menu options I didn't notice before: Open IME and Reconversion. Are those supposed to be there, and if so, what do they do?