RMIR: Prototype IR function in RM

[mathdon]

@HWTest

Please try loading your file in RMIR v2.03 Alpha 27b. It's the same link as for Alpha 27 but a revised file. It loads OK for me in Alpha 27b so I think you found the same bug as Liz did in her earlier post.

[HWTest]

Unfortunately I get still the same error in RMIR v2.03 Alpha 27b also the raw download save behaves the same.

[mathdon]

Unfortunately I get still the same error in RMIR v2.03 Alpha 27b also the raw download save behaves the same.

I have compared the error log you posted originally with the data in your .ir file. It seems that you are using a parallel interface. Is this correct, as that is unusual nowadays? I don't know what the parallel interface is reading, but it does not appear to be your remote. The error log reports the first 10 bytes of the data in the remote. Not only is this totally different from the first 10 bytes of the data in your .ir file, but it also does not look like data from any remote. This would explain also why you are unable to save a raw download.

This suggests that there is something wrong with your RMIR installation, but I have no idea what is wrong. I think you will find that if you load the .ir file from IR 8.04 into RMIR 2.03 Alpha 27b, it will read correctly.

I hope some other expert looking at this thread can help you. I have no further ideas.

[mathdon]

Liz, please try RMIR v2.03 Alpha 27c.

Your latest bug is a repeat of the previous one concerning External Functions. Both bugs concerned the parsing of hex values in a KM .txt file. The previous one handled hex values marked with a final "h", the new one with values marked with an initial "$". I presume KM used different markers in different versions. I should have spotted the "$" marker when I dealt with the "h" one, but unfortunately I didn't think of it. I don't think there should be further issues with External Functions from KM, so don't go out of your way to test for them.

1a. what is the meaning of grey-shaded keymoves just after loading .ir?

These are keymoves in a device upgrade (a function assigned to a button marked with an asterisk on the Buttons tab). They are edited in the Device Upgrade Editor and are read-only in the Key Moves tab.

1b. what is the meaning of bold hex in Raw data just after loading .ir?

These are values changed from the imported values, usually as a result of RMIR re-ordering data from that used by IR.exe. IR.exe shows what it has downloaded, or loaded from a file, without change. RMIR analyses the data and reconstructs it for display/upload, which may result in a different ordering. This is a difference of philosophy between IR.exe and RMIR, but it is due to this difference that RMIR can be adapted to remotes with totally different data structures, such as JP2 and XSights, which IR.exe cannot.

1c. some keymoves, such as DSM, got moved to Special, and some Special got moved to keymoves. I think it's all ok, just different.

Special Functions are coded as keymoves, so this is not surprising, but if you want to post an example for me to check out, please do so.

2. When I clicked on a device and chose Edit (just to look), then wanted to minimize the Device editor window (too look at the main, RMIR, window), both that and RMIR minimized. Yikes, most inconvenient.

That is not under my control. That is what Java does with subsidiary windows.

3. I wanted to see what the import raw button does when click on a device.

I don't have any idea what this does, either .

4. BIG WISH - Graham, look in IR on the Devices tab. The Device info on the right shows hex stuff for buttons. I really, really, really miss it in RMIR, always did. I would like to see equivalent window/tab in RMIR.

This is part of the different philosophies of IR and RMIR. IR does not have a concept of function. I will think about what can be done, but make no promises.

I tried doing something in RM and abandoned it. Close without saving. Subsequent attempt to run RM continues to have the previous trash.

I have no idea how this can have happened. If you can make it reproducible, I will look into it.

[HWTest]

mathdon: You are correct, I'm using a parallel interface.

[ElizabethD]

Unfortunately I get still the same error in RMIR v2.03 Alpha 27b also the raw download save behaves the same.

I have compared the error log you posted originally with the data in your .ir file. It seems that you are using a parallel interface. Is this correct, as that is unusual nowadays?

Just FYI: Parallel in use here as well. Not always, but I just tried it again.
I did standard and raw downloads from 6131 in IR and RMIR. All hex values in the 4 files are identical.

[ElizabethD]

Liz, please try RMIR v2.03 Alpha 27c.

Your latest bug is a repeat of the previous one concerning External Functions. Both bugs concerned the parsing of hex values in a KM .txt file. The previous one handled hex values marked with a final "h", the new one with values marked with an initial "$". I presume KM used different markers in different versions. I should have spotted the "$" marker when I dealt with the "h" one, but unfortunately I didn't think of it. I don't think there should be further issues with External Functions from KM, so don't go out of your way to test for them.

I didn't think of it either. BTW - do you have KM? or just read as text?
You'll love this one: I just unearthed early version in Acronis image. The file is from Aug 2006. And it uses values such as $CA, and h72 in the Functions column, which KM happily translated to CAh and 72h in the OBC column

Readme in v8.31 of 2005, v9.21 and v9.22 of 12/12/2009

NOTE: A single-byte hex command MUST be prefixed or suffixed with
"h" (i.e. "h34" or "34h"). Multiple-byte hex commands MUST be
entered with a space between each byte ("00 34", "FF 00", or "AA
BB CC DD" are all valid entries).

Not a word about "$" nor that lower case hex letters are also allowed, in case that matters.

I didn't download v2.03 Alpha 27c yet.

[mathdon]

BTW - do you have KM? or just read as text?

No, I don't have KM. I just look at the text, in conjunction with the Java code in RMIR (that Greg wrote) to interpret it. There is nothing wrong with Greg's code, it is that it calls hex parsing routines that I have had to modify to handle other situations, and wasn't aware of some of the subtleties that it had to cope with in the original situations.

[ElizabethD]

1a. what is the meaning of grey-shaded keymoves just after loading .ir?

These are keymoves in a device upgrade (a function assigned to a button marked with an asterisk on the Buttons tab). They are edited in the Device Upgrade Editor and are read-only in the Key Moves tab.

1b. what is the meaning of bold hex in Raw data just after loading .ir?

These are values changed from the imported values, usually as a result of RMIR re-ordering data from that used by IR.exe. IR.exe shows what it has downloaded, or loaded from a file, without change. RMIR analyses the data and reconstructs it for display/upload, which may result in a different ordering. This is a difference of philosophy between IR.exe and RMIR, but it is due to this difference that RMIR can be adapted to remotes with totally different data structures, such as JP2 and XSights, which IR.exe cannot.

Understood. Thanks.

2. When I clicked on a device and chose Edit (just to look), then wanted to minimize the Device editor window (too look at the main, RMIR, window), both that and RMIR minimized. Yikes, most inconvenient.

That is not under my control. That is what Java does with subsidiary windows.

Then java stinks. What were they thinking of!

4. BIG WISH - Graham, look in IR on the Devices tab. The Device info on the right shows hex stuff for buttons. I really, really, really miss it in RMIR, always did. I would like to see equivalent window/tab in RMIR.

This is part of the different philosophies of IR and RMIR. IR does not have a concept of function. I will think about what can be done, but make no promises.

Oh boy. As if you had nothing else to do, what with all those new remotes and protocols. But I really do wish for that.

I tried doing something in RM and abandoned it. Close without saving. Subsequent attempt to run RM continues to have the previous trash.

I have no idea how this can have happened. If you can make it reproducible, I will look into it.

Ok, if it hits again. Most likely I messed up.

1c. some keymoves, such as DSM, got moved to Special, and some Special got moved to keymoves. I think it's all ok, just different.

Special Functions are coded as keymoves, so this is not surprising, but if you want to post an example for me to check out, please do so.

Actually I was just reporting what I saw. I'm actually less puzzled by the SP becoming keymoves, than the DSMs becoming Special Functions.
Most likely it's all fine. I didn't yet get to uploading from RMIR, nor building RMIR, since I'm still in the discovery of old files mode for the remotes that work here.
Two screenshots for you
http://www.hifi-remote.com/forums/dload ... e_id=13055

[Barf]

2. When I clicked on a device and chose Edit (just to look), then wanted to minimize the Device editor window (too look at the main, RMIR, window), both that and RMIR minimized. Yikes, most inconvenient.

That is not under my control. That is what Java does with subsidiary windows.

Nope. That behavior is explicitly programmed in. DeviceUpgradeEditor.java, lines 83--98

Code: Select all

    addWindowStateListener( new WindowAdapter()
    {
      @Override
      public void windowStateChanged( WindowEvent e )
      {
        if ( e.getNewState() == JFrame.ICONIFIED )
        {
          if ( DeviceUpgradeEditor.this.owner.getState() != Frame.ICONIFIED )
          {
            DeviceUpgradeEditor.this.owner.setState( Frame.ICONIFIED );
//            setExtendedState( NORMAL );
            toFront();
          }
        }
      }
    } );

Remove those lines, and the pesky behavior that Liz consider "stinks" is gone.

You may like to remove the focusWindowAdapter on lines 50--57 too.

[mathdon]

Nope. That behavior is explicitly programmed in. DeviceUpgradeEditor.java, lines 83--98

Oops! It appears that I did this in April 2014. I have no recollection of doing so, or why I did it. There must have been some reason. I'll try to think what it might have been, and if there is some other way of meeting it.

Edit: I can see no good reason for my change in April 2014. However, before that change the commented-out line was active and the line above was absent. The effect of this was that it was not possible to minimize the Device Editor window. If you tried, it would immediately pop up to normal size again. Perhaps I was trying to rectify this and made a mess of it. I will sort it out.

I'm actually less puzzled by the SP becoming keymoves, than the DSMs becoming Special Functions.

DSMs are Special Functions, so this is what I expect. It's special functions becoming key moves that puzzles me.

Edit 2:

You may like to remove the focusWindowAdapter on lines 50--57 too.

A test shows that removing this adapter allows the main window to take the focus while the Device Editor window is open. This should not be allowed, as editing the main window before changes made in the editor have been committed or cancelled can lead to inconsistencies. I note, however, that the JavaDoc for toFront() says

If this Window is visible, brings this Window to the front and may make it the focused Window.

The "may" suggests that on some platforms this would not have the desired effect. Do I need to put an explicit instruction to make the editor keep the focus?

[Barf]

Some time ago, the device edtor window, when fired up from rmir, was a modal windows (grabbing focus, and disabling all access to the parent window until it is closed.) Modal windows are most often not a good idea, in particular from the point of the user, although it may make the control flow easier to understand. I just discovered (and was positively surprised!) that the device editor is no longer modal, for example, there can be more than one. Of course that requires that someone has checked that no misbehavior can occur. Probably the old code stems from the modal-window time, when it, possibly, made sense.

A test shows that removing this adapter allows the main window to take the focus while the Device Editor window is open. This should not be allowed, as editing the main window before changes made in the editor have been committed or cancelled can lead to inconsistencies.

If that is what you want (i.e. the modal behavior), then toFront() does not do it. "Front" and "focus" are two different pair of shoes.

[mathdon]

Barf, I do need the Device Editor window to be modal. There may be reasons to dislike modal windows, but the interaction between it (essentially RM) and the main RMIR app are already very complicated. The complications, incidentally, are in cancelling the edit rather than committing it. The idea of having to handle changes made in the main RMIR app while the Device Editor window is open positively horrifies me. I am not willing even to contemplate it.

I will make sure the Device Editor window is modal. It still is in Windows, as far as I can tell, so I assume you were testing in Linux. Is that right?

[Barf]

Barf, I do need the Device Editor window to be modal. There may be reasons to dislike modal windows, but the interaction between it (essentially RM) and the main RMIR app are already very complicated. The complications, incidentally, are in cancelling the edit rather than committing it. The idea of having to handle changes made in the main RMIR app while the Device Editor window is open positively horrifies me. I am not willing even to contemplate it.

Fair enough. Means that RMIR needs to be fixed.

I will make sure the Device Editor window is modal. It still is in Windows, as far as I can tell, so I assume you were testing in Linux. Is that right?

Yes, I am using Linux (as development platform), but i also have Windows computers, as well as a Mac . However, Windows behaves identically (I even tested!), allowing the rmir window to accept input, even if there is a device editor. (Just reposition it.) Even several device editors can be fired up. As I said, "focus" and "front" are two different pair of shoes, also on Windows .

[Barf]

There appears to be no really clean way to make a child JFrame (like the DeviceUpgradeEditor) modal. Thsi patch will do the main functionallity though. It just disables the rmir panel when the device upgrade starts, and reenables it when the D.E. closes.

Code: Select all

--- com/hifiremote/jp1/DeviceUpgradeEditor.java (revision 1299)
+++ com/hifiremote/jp1/DeviceUpgradeEditor.java (working copy)
@@ -105,6 +105,7 @@
       {
         cancelButton.doClick();
         DeviceUpgradeEditor.this.owner.removeWindowFocusListener( focusWindowAdapter );
+        DeviceUpgradeEditor.this.owner.setEnabled(true);
       }
     } );
     editorPanel = new DeviceEditorPanel( this, deviceUpgrade, remotes );
@@ -165,6 +166,7 @@
 //        btn.setName( softButtonNames.get( btn ) );
 //      }
 //    }
+    owner.setEnabled(false);
     setVisible( true );
   }
 
@@ -253,6 +255,7 @@
         
         setVisible( false );
         dispose();
+        owner.setEnabled(true);
         editorPanel.releasePanels();
         if ( panel instanceof GeneralPanel )
         {

Still can be confusing for the user when the main window appears to "hang" -- I did say that I do not like modal windows, rite?