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.HWTest wrote:Unfortunately I get still the same error in RMIR v2.03 Alpha 27b also the raw download save behaves the same.
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.1a. what is the meaning of grey-shaded keymoves 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.1b. what is the meaning of bold hex in Raw data just after loading .ir?
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.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.
That is not under my control. That is what Java does with subsidiary windows.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.
3. I wanted to see what the import raw button does when click on a device.
.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.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.
I have no idea how this can have happened. If you can make it reproducible, I will look into it.I tried doing something in RM and abandoned it. Close without saving. Subsequent attempt to run RM continues to have the previous trash.
Just FYI: Parallel in use here as well. Not always, but I just tried it again.mathdon wrote: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?HWTest wrote:Unfortunately I get still the same error in RMIR v2.03 Alpha 27b also the raw download save behaves the same.
I didn't think of it either. BTW - do you have KM? or just read as text?mathdon wrote: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.
Not a word about "$" nor that lower case hex letters are also allowed, in case that matters.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).
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 wrote:BTW - do you have KM? or just read as text?
Understood. Thanks.mathdon wrote: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.1a. what is the meaning of grey-shaded keymoves 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.1b. what is the meaning of bold hex in Raw data just after loading .ir?
Then java stinks. What were they thinking of!mathdon wrote:That is not under my control. That is what Java does with subsidiary windows.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.
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.mathdon wrote: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.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.
Ok, if it hits again. Most likely I messed up.mathdon wrote:I have no idea how this can have happened. If you can make it reproducible, I will look into it.I tried doing something in RM and abandoned it. Close without saving. Subsequent attempt to run RM continues to have the previous trash.
Actually I was just reporting what I saw. I'm actually less puzzled by the SP becoming keymoves, than the DSMs becoming Special Functions.mathdon wrote: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.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.
Nope. That behavior is explicitly programmed in. DeviceUpgradeEditor.java, lines 83--98mathdon wrote:That is not under my control. That is what Java does with subsidiary windows.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.
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();
}
}
}
} );Oops!Barf wrote:Nope. That behavior is explicitly programmed in. DeviceUpgradeEditor.java, lines 83--98
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.DSMs are Special Functions, so this is what I expect. It's special functions becoming key moves that puzzles me.ElizabethD wrote:I'm actually less puzzled by the SP becoming keymoves, than the DSMs becoming Special Functions.
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() saysBarf wrote:You may like to remove the focusWindowAdapter on lines 50--57 too.
If this Window is visible, brings this Window to the front and may make it the focused Window.
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.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.
Fair enough. Means that RMIR needs to be fixed.mathdon wrote: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.
Yes, I am using Linux (as development platform), but i also have Windows computers, as well as a MacI 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?
. 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 .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 )
{