Page 37 of 59

Posted: Fri Sep 10, 2010 6:29 am
by The Robman
gfb107 wrote:2 things:

1. You can only delete functions that are not assigned to buttons.
So first you must unassign the functions, then you can delete them

2. At this time you can only delete one row at a time. You may select multiple rows, but only the top deleted row will be deleted.
Could I suggest that you allow deletion of a function regardless, and if it's assigned to a button, just delete the assignment also. I don't see any point in making the user do extra work.

Posted: Mon Sep 13, 2010 6:43 am
by Capn Trips
mathdon wrote:
vickyg2003 wrote:
Capn Trips wrote:That's a first STEP, but not completely there. I still believe in the value of being able to DELETE an upgrade (not merely DEASSIGN it from a Device button) without deleting the associated KeyMoves (and/or Protocol upgrade)
I thought it went without saying that once you have changed the device button assignment to another device and retained the key moves, you can then delete the device upgrade. The key moves are now attached to the new device and so remain unaffected.
I finally focused on this reply and it dawned upon me that there is STILL a misunderstanding here. You are presuming that one will always use a separate Setup Code for one's upgrade that differs from a built-in setup code. This is not always the case. i.e. Video/0059 is a built-in setup code for Pioneer Laserdisc players in most UEIC remotes. Some LD players have additional functions not included in the built-in setup code. (Side A/B, Disc 1, 2, 3, 4, 5, Digital/Analog sound, others). Rather than bludgeoning through manually building a bunch of Keymoves on the Keymoves Tab, I have a RMDU file with Video/0059 which includes all known additional functions. I tailor it to my OCAP or 6131 or whatever remote and add it to the IR file - which generates a bunch of Keymoves on 0059. It also adds special functions to the basic Keymap as well that are not included in the "base" 0059 Setup Code. I want to be able to (1) convert those special functions that are NOT in the built-in 0059 to Keymoves (RM automatically makes them part of the Device Upgrade), and (2) Delete the 0059 Upgrade (because it duplicates the built-in Setup Code, while retaining the Keymoves calling on Video/0059. So I have NOT assigned a different Setup Code to the Device Key.

In Fact, RMIR should be able to tell the user that there is a matching built-in setup code, or SUGGEST a built-in setup code and ask if the user wants to use that setup code, and convert all of the special functions from the upgrade to Keymoves and remove the upgrade, retaining the keymoves. (But that's next-level stuff.)

I roger that this is not beginner functionality, and that stuff like upgrade overflow and (especially with OCAP where almost every button in in the Keymap for most device types) preferring a Keymove over a function being inherent to an upgrade is an exception rather than the rule, but nonetheless, the basic idea of being able to limit AUTOMATIC changes by the software and having CONTROL of one's remote image is at the core here.
Edit: I just noticed the new Keymove functionality whereby one can make a Keymove calling a function from an upgrade! Very cool. I'm not if it completely obviates my concerns stated above, but it certainly makes them less burdensome.

Posted: Mon Sep 13, 2010 8:33 am
by vickyg2003
Actually Captain, you'll find that if you want to do anything out of the box, the correct procedure

Import the device
Assign it to a device key
Dissassociate it from the device key, leaving the keymoves
Edit the Device
Remove all keymoves from the device upgrade
Reassociate the upgrade with the device key.


Then you can do things that you can do in IR. Its just cumbersome as can be.

Posted: Wed Sep 15, 2010 6:16 am
by gfb107

Posted: Wed Nov 03, 2010 7:00 pm
by gfb107
v2.00 Preview 8 is now available

Posted: Mon Nov 29, 2010 9:31 pm
by unclemiltie
Elizabeth's comments in another thread brought me back here. Last I looked, the RDF's in my files are all up to to date with the right AdvanceCode addresses (this is in V2.10 of the extender for all of the Atlas remotes)

Is there anything else I need to adjust?

Posted: Tue Nov 30, 2010 6:57 am
by Capn Trips
Not sure, but the rdf in the current rdf zip distribution does differ slightly from the extender zip rdf. Specifically, RDF.ZIP includes:

[Extender]
OEMSignature=30333033

between the [General] and [Special Protocols] sections.

Also, the RDF.ZIP has a few updated protocols listed:

007E:4 vs. 007E:3
0161:5 vs, 0161 and
016C:2 vs. 016C.

I'm not sure that these differences could cause the problems described in the thread. Either of those two rdf's seems to work fine with my long-standing OCAP Extender HT Remote setup. No scrambled buttons, etc.

Not sure this helps.

Posted: Tue Nov 30, 2010 7:52 am
by vickyg2003
Capn Trips wrote:Not sure, but the rdf in the current rdf zip distribution does differ slightly from the extender zip rdf. Specifically, RDF.ZIP includes:

[Extender]
OEMSignature=30333033
This section is used to remove extenders from certain lists. When the RDF is under the Chris's (The RDF Librarian's) control, this is also used to make sure that the protocols section is updated to match the Master Protocol list. That would gave taken care of these other problems you found. 007E:4 vs. 007E:3, 0161:5 vs, 0161 and 016C:2 vs. 016C.
Capn Trips wrote:I'm not sure that these differences could cause the problems described in the thread. Either of those two rdf's seems to work fine with my long-standing OCAP Extender HT Remote setup. No scrambled buttons, etc.
If you were using 007E, 0161 or 016C this might cause problems with scrambled buttons on these protocols. Typically when the variant is different there are differences in the number of fixed data bytes. I'm not sure what RMIR does on import if this kind of mistake was previously made.

Posted: Tue Dec 14, 2010 12:30 pm
by mathdon
I have started to develop RMIR v2.01 and have posted a .jar file of RMIR 2.01 alpha. I take it that alpha testing comes before beta testing :?: , so this is intended to indicate that it is very much a product under development and you use it at your own risk. That said, I hope that users of RMIR will try it and will report any bugs or other comments here.

It contains two major new features and a few bug fixes. The new features are

a) allowing upgrades to overflow from the upgrade area to the learned signal and key moves areas, and

b) highlighting of raw data.

Both are very similar to the corresponding features in IR.exe, but here are a few additional comments:

When upgrades overflow into one or both of the other areas, the progress bars in those areas become yellow instead of the normal aquamarine. When there is insufficient space in any area for the data that has been set, the free space figure becomes negative. In this state you are prevented from uploading it to a remote, or from saving it as a .ir file, as the remote image is not a valid one. You can, however, save it as a .rmir file without loss of any data. You can also continue to add more data, making the free space figure even more negative. It will always save as a .rmir file that can be re-loaded to return this over-full state intact. At some point you will need to delete some data to correct the over-full state so as to be able to use it in a remote, but that can be any of the data, it does not have to be the ones that caused the remote to become full.

In this alpha version, highlighting is permanently on. Later on, I intend to make it an option, defaulting to off, as is the case in IR.exe. The highlight color can be set against any item in two ways, either by double-clicking the Color column or by selecting any cell in the row and pressing the "Set highlight color" button on the toolbar. The first way only allows you to set the color on one item at a time, but the toolbar button enables you to set the same color on multiple items by selecting a block of cells covering several rows. Multi-select in RMIR only allows you to select a single rectangular block of cells, so the items to be colored must be in consecutive rows, but they can be consecutive rows in a sorted grid, not just in the normal unsorted state, so you can select all the items containing a particular value by sorting the grid on that value and then selecting the items, which will now be on consecutive rows.

Sorting of rows in RMIR is not new, but it is also not obvious. In most tables you can sort by any column by clicking the column header. This cycles between three states: the unsorted state, sorted in increasing order, and sorted in decreasing order. A fourth click returns to the unsorted state. In contrast to IR.exe, sorting has no effect on the order of storage in the remote. That is determined by the numerical order of the rows. The number column to the left of each grid takes part in the sorting, so you can see the storage order even in a sorted state.

Highlighting is implemented in all tables. With one exception, selecting a highlight color for an item causes the corresponding bytes in the raw data grid to be highlighted with that color. The exception is the Settings table on the General panel, since settings are set bit by bit rather than byte by byte. The bytes in the raw data grid corresponding to settings get colored in eight bands, corresponding to the bits of the byte with the band for bit 0 being on the right. As it can be difficult to tell which bands have been colored, if you hover the mouse pointer over a cell with colored bands then it will display numerically which bits are colored. When several settings correspond to different bits of the same byte, a byte can gain bands in distinct colors.

Please post comments and suggestions in this thread.

Posted: Tue Dec 14, 2010 3:49 pm
by vickyg2003
I can't wait to try it. I've just taken a step backwards in time, since I'm using my husbands laptop and the tools are really old versions. It is amazing how much better the tools have gotten in the past year.

Posted: Tue Dec 14, 2010 5:07 pm
by The Robman
vickyg2003 wrote:I can't wait to try it. I've just taken a step backwards in time, since I'm using my husbands laptop and the tools are really old versions. It is amazing how much better the tools have gotten in the past year.
Why did you let your husband have a copy of the JP1 tools at all, he's not authorized to use them!!! :)

Posted: Tue Dec 14, 2010 5:56 pm
by vickyg2003
The Robman wrote:
vickyg2003 wrote:I can't wait to try it. I've just taken a step backwards in time, since I'm using my husbands laptop and the tools are really old versions. It is amazing how much better the tools have gotten in the past year.
Why did you let your husband have a copy of the JP1 tools at all, he's not authorized to use them!!! :)
Well I don't let him USE them, :lol:. As you know he's not a jp1 fan. I'm just lucky he lets me load them on at all.

Posted: Tue Dec 14, 2010 9:57 pm
by vickyg2003
Highlighting is cool. I wish we'd had this earlier in the debugging process! I've only recently started using highlighting in IR, but found it to be quite helpful. I like the RMIR highlighting colors better than the ones available in IR.

I haven't quite figured out why you'd want to have multiple line selection for highlighting though.

Posted: Wed Dec 15, 2010 6:12 am
by mathdon
vickyg2003 wrote:Highlighting is cool. I wish we'd had this earlier in the debugging process! I've only recently started using highlighting in IR, but found it to be quite helpful. I like the RMIR highlighting colors better than the ones available in IR.

I haven't quite figured out why you'd want to have multiple line selection for highlighting though.
I wanted to get the basic functionality stable before adding new non-trivial stuff like highlighting. I missed it too in my development work, which is why it was a high priority for v2.01.

The color panel is a standard item in both Delphi (for IR.exe) and Java (for RMIR), so the difference between IR.exe and RMIR is due to the programming language, not to me. Both, however, allow the selection of ANY color, though with a little more effort than just selecting one from the main display. In IR.exe you click the "Define Custom Colors" button. In RMIR you select the "HSB" panel. Both then allow a choice from a continuum of colors, though the two do it somewhat different ways.

One use of setting a highlight on a multiple selection is to delete a range of highlights that have already been set, by selecting WHITE. If the existing colors in the selected rows are not all the same, then when you press the toolbar button the color selector opens with White already selected; if only one row is selected or all have the same color, it opens with that color selected.

Posted: Wed Dec 15, 2010 7:09 am
by vickyg2003
mathdon wrote:One use of setting a highlight on a multiple selection is to delete a range of highlights that have already been set, by selecting WHITE. If the existing colors in the selected rows are not all the same, then when you press the toolbar button the color selector opens with White already selected; if only one row is selected or all have the same color, it opens with that color selected.
That makes sense. I hope you don't mind the "dumb" questions since I really couldn't think of that on my own. :lol: I hope to get to an area of strong wifi so I can get enough of a wifi signal to download IR 8.03 and the new RDF's and images.

As I said above, I've gone back in time,and it really makes me appreciate all the work that's been done on the tools!