IR8.01 Beta posted

Mark Pierson · Post by **Mark Pierson** » Wed Jul 15, 2009 3:37 pm

mathdon wrote:I've adopted Mark's suggestion of Short/Long Press and Single/Double Press for the LKP and DKP Macros rather than keeping the meaningless ones with the word "Keys".

Wow!

I feel like I won something.

Maybe I should go buy some lottery tickets...

Surely this can't be controversial. Can it???

I promise I won't complain!

I'm a Brit

That's ok... nobody's perfect!

Post by **The Robman** » Wed Jul 15, 2009 5:22 pm

mathdon wrote:BTW, anyone notice that I'm a Brit but used the US spelling for Color? I don't think my life would still be worth living if I had put in a "Colour" column!

Personally, I would have loved it, but I have to remember to use the Yank spelling for everything myself! (know wot I mean).

mdavej · Post by **mdavej** » Mon Jul 20, 2009 9:36 pm

Graham,

I found a bug. When I first open an IR file without opening a file, some device codes show invalid just as they should. However when I open a file with all valid codes, the same cells that were red before, stay red until I click anywhere on the screen.

Post by **vickyg2003** » Wed Jul 22, 2009 9:08 am

Graham, this file demonstrates the problem that Dave was seeing. I had a heck of a time getting the device codes to turn black.
https://www.hifi-remote.com/forums/dload ... le_id=6965

In addition, when I have two copies of IR open, I'm often getting Access Code violations when trying to save a files. I believe these are an error, on IR's part, although I'm not 100% certain. I'm usually unaware of what I've done if I'm not specifically bug hunting and can't seem to recreate it at will. I'd appreciate it if anyone else who is getting unexpected Access Violations with two IR files open at the same time would see if they know what they did, so we can track this down error, or attribute it to my own user error.

Post by **vickyg2003** » Fri Aug 07, 2009 8:16 pm

Graham, I am often getting list out of bounds errors when I download from remotes with fewer devices. I think this might be what related to problems that I have much later in the process. Do you have any of the smaller remotes, or do you only have the 7780 and its cousin?

Post by **mathdon** » Sat Aug 08, 2009 2:05 am

Vicky, I don't even have a 7780, only a 7781. Alain tests my 7780 extender before release. I do also have my old remote, a URC-8550 Topline 8, which is a 740 chip, but that's not very relevant nowadays. Now I'm getting into protocols, I must look into buying a JP1.3 remote from Rob so I can test S3C8 protocol code.

Could you send me one or more .ir files that exhibit your problem, or can't you get as far as creating them? If you can't get that far, can you use the Enable Raw Download option to make a .ir file of the raw data? Do you know if the problem is a new one in IR 8.00 or one also present in IR 7.15?

I've been quiet in this thread for some time as I've been working on protocols, but I'll get back to looking at these latest IR 8.01 bugs soon. I am hoping that it will be possible, with John Fine's approval, to have an updated version of DecodeIR included in the IR 8.01 release.
_______________
Graham

Post by **vickyg2003** » Sat Aug 08, 2009 5:59 am

I haven't been getting this behavior from IR files, only from downloads. I was getting it consistantly before I posted and now I can't replicate it to save my life. Everytime I changed from the Atlas to the Comcast I was getting an index out of bounds error. Whatever is causing me problems is very intermittant and only happens when I have two instances of IR running. I thought I had my finger on the problem, but it seems that I'll have to keep looking.

Post by **mathdon** » Tue Aug 25, 2009 1:59 pm

mdavej wrote:Lastly, for something you probably haven't ever touched at all, but something I just happened to notice. When you pick File -> Summary, the details don't always line up with the column headers in each section. They appear to be tab delimited, but some rows have more tabs than they should, so everything doesn't quite line up. I know if the data is too wide, it'll get pushed out with extra tabs, but even short data isn't quite right. Maybe it looks for the widest data and adds tabs for the worst case. If that's difficult to improve, please forget I mentioned it. It's definitely not very important.

I've finally got to the bottom of this one and put it right. It took quite some web searching and I think the origin of the problem is sufficiently interesting to be worth recording.

Tabs are set in terms of pixels, fonts are displayed in terms of point sizes, a point being 1/72 of an inch. So to see if text fits between one tab and the next, you need to know how many pixels there are to an inch. But an OS doesn't know about inches, so to it a point is 1/72 of a "logical inch". What is a logical inch? Well, that's the interesting question! A logical inch is a certain number of pixels. How many? Well, for a long time it was fixed by convention at 72 pixels per logical inch, as that was the real figure for the first Apple Mac's, the first computers that had a graphical screen. Conveniently that meant 1 point = 1 pixel. Microsoft adopted and stuck to this for a long time, but as screen resolutions have increased it became unsustainable. Nowadays a figure of 96 or 120 is more commonly used, and you need to query the OS to find the actual figure.

IR.exe appears to date from the time when you could rely on 72 pixels per inch, so it was hard coded. I've now corrected that to use the actual figure from the OS, and all is well.

mdavej wrote:I found a bug. When I first open an IR file without opening a file, some device codes show invalid just as they should. However when I open a file with all valid codes, the same cells that were red before, stay red until I click anywhere on the screen.

Also interesting, though perhaps only to me. This error only occurred with files for remotes that use 1-byte PIDs. My testing is mainly with the URC-7781, which uses 2-byte PIDs (though its similar predecessor, the URC-7780, uses 1-byte PIDs and so shows this problem).

Both errors are now corrected. I'll post an RC3 shortly, probably tomorrow.
______________
Graham

Post by **mathdon** » Wed Aug 26, 2009 6:29 am

IR 8.01 Release Candidate 3 posted

I have now posted IR 8.01 Release Candidate 3. As I described in my previous post, it corrects the issues of misalignment of the File/Summary display and of valid setup codes sometimes showing as invalid when a .ir file is first opened. I have also added Number Tables up to 463, a confirmation message when Clean Upper Memory is invoked that warns against using it when an extender is present, and have made the width of panels on the Learned Signals page follow changes of width of the overall IR window.

After sorting the Summary alignment problem, I changed the positions of a few of the tab stops to widen some of the columns, as this gave a better display with the files I tried it on. If anyone feels other columns should also be widened, now is the time to say so!
_________________
Graham

mdavej · Post by **mdavej** » Thu Aug 27, 2009 4:07 pm

Thanks, Graham. So far so good.

The invalid codes issue appears to be fixed.

The summary is working much better. If any data is too wide, it still pushes other columns out so they don't line up. But I can't think of any way to improve it. You could make some columns wider, but no guarantees whatever you pick will always be big enough. I'd say keep what you've got.

Post by **mathdon** » Fri Aug 28, 2009 2:09 am

Thanks, mdavej, for the comments. There is a mechanism in the Summary setup to handle wide data, but it isn't perfect. First, check that on the Advanced menu, you have "Wrap Summary Lines" selected. It's only through investigating the code that I have discovered what this does. It wraps overlong items in individual columns, rather than whole lines (as its name seems to imply), and is set up only on columns where there is an expectation that the items may well be too long for the column width. But the wrap point for a column is specified in "characters" rather than inches or pixels. As Summary uses a proportional font, and the OS nowadays also has a choice of large or small fonts, there will never be a guarantee that the set number of characters will fit within the column width (set in "logical inches").

But if you do have "Wrap Summary Lines" turned on and have particular columns where you think there is an issue, I can have a go at a bit more tweaking.

Graham

mdavej · Post by **mdavej** » Sat Aug 29, 2009 6:56 pm

Wrap fixed everything but the device section and one line in special protocols in the file I tested.

Thanks

Post by **mathdon** » Sun Aug 30, 2009 11:47 am

IR 8.01 RC4 with DecodeIR 2.37 Beta posted

I have posted IR 8.01 Release Candidate 4. This contains two minor changes to RC3. One is that I have further tweaked the setup of the Files/Summary output in the light of mdavej's helpful test file. The other is the main reason for the posting.

I have added to DecodeIR, in a way that should cause no compatibility problems, the ability to be passed the bursts that IR.exe lists in its Raw Timing Data as "Extra bursts". I have also added to IR.exe the ability to pass these bursts. This is part of a facility I have put into DecodeIR to look ahead and check for repeat frames, either identical repeats or those with distinctive start or end frames as required by a protocol. If repeats are found, only one return is made, in which the "Misc" field begins with "n frames" where n is the number of repeats found. If distinctive start or end frames should be present but are missing, it will also say "no start frame" or "no end frame". At present this check on start/end frames only operates for the newly added Amino, CanalSat and OrtekMCE protocols.

If n=1 or if the data provided to DecodeIR includes "Repeat bursts", so that n is indeterminate, the report of n is suppressed. This will usually be the case with IR.exe, but when used with IRScope it considerably simplifies the display by reporting only once for each button pressed, giving the number of frames sent.

I have included DecodeIR v2.37 Beta in a separate folder in this distribution, together with updated ReadMe and ChangeLog files. The version of DecodeIR in the main folder of the distribution is still v2.36, so if you just copy the files into your IR folder as they stand, it will use v2.36. I have done this so that you need to take positive steps to use the new Beta version.

This distribution also includes a file ProtocolsX.ini. This contains the additions needed to protocols.ini to enable RM to create device upgrades for the protocols newly added to DecodeIR. I have needed 4 non-UEI PIDs and have used 01EC to 01EF, for want of anything better.

I am making this Beta version of DecodeIR generally available as (a) it is needed to test the latest changes to IR.exe properly, and (b) to seek general views on the "look ahead" facility I have described above. As far as I am concerned, this completes the development of IR 8.01 and DecodeIR 2.37. Any further changes to IR 8.01 will only be to correct bugs, and those to DecodeIR 2.37 will be in response to comments and to John Fine's analysis.

A good illustration of the results of the "look ahead" are given by the learned files in this download.

I look forward to receiving comments.
___________________
Graham

mdavej · Post by **mdavej** » Sun Aug 30, 2009 9:14 pm

Summary looks great. The other stuff is over my head.

Thanks.

Post by **ElizabethD** » Sat Sep 05, 2009 9:19 pm

I think I am using 8.0.1 RC3 (and now see RC4 is out)
IR About says 8.01
ir.exe says 8.0.1.9

Coloring is great.
Multiselecting to move/delete is great.
Sorts and undo are great.
Summary looks nice as well.
Interface (usb for jp1.3 or parallel) no issues.
Everything that I understand and use is great.

But I just got bitten by an old problem which I once reported here but nothing happened, I guess.

It's an OLD problem of notes in protocols. Old, because it was in v7 and likely in v6 as well. [Edit: I just found a not very clear description, it was about 6.15:
https://www.hifi-remote.com/forums/viewt ... ocol+notes ]

If you do heavy editing removing and adding devices and/or protocols, the notes that go with the protocol get disjointed, so they're wrong.

Today's example
Original file had these protocols at the end of list:
0134-jvc with repeats
01f1-macro repeats
00CD-Rob's panasonic with vol repeats

I deleted 0134 (needed to change/confirm/whatever)
I added it back. It didn't go to the end, but that's ok, I don't care.

But now the notes are shifted and say:
0134-macro repeats
01f1-Rob's panasonic with vol repeats
00CD-jvc with repeats

ooops