I recently bought a JP1 USB interface for use with ir on a windows 10 machine.
When I came to search the latest version of IR, I found the release note for RMIR 3.2.0, so I downloaded and was delighted to find that I recognized my wife's old URC8910 and would upload/download. However when I tried the "edit device" button the app appeared to simply lock up. I spent two days editing in versiion 2.12 and uploading with version 3.2.0
For no known reason today when I tried the edit function in 3.2.4 instead of closing the app I moved the window. I found the upgrade open in a window directly behind the main window. I don't know if this is something wrong with my setup, or just how it works. I'm running on MAC OS Sonoma. I typically don't run any apps maximized, but I did try for this and found that the upgrade opened in the foreground as it should. I'm happy as a clam now, and I can finally dump the old Windows 95 machine whose only function was programming JP!.
RMIR bug/feature/operator error?
Moderator: Moderators
I don't have a URC8910 so if you want me to investigate the behaviour in RMIR 3.2.0, could you please post the .rmir file for which "edit device" locks up.pogo wrote:When I came to search the latest version of IR, I found the release note for RMIR 3.2.0, so I downloaded and was delighted to find that I recognized my wife's old URC8910 and would upload/download. However when I tried the "edit device" button the app appeared to simply lock up.
I can't tell from your post whether it still locks up in v3.2.4. Does it? As for the upgrade window opening behind the main window, I think this must be something to do with you using a Mac. I have not heard of this issue before but I have no way of testing RMIR on a Mac.
Graham
Re: RMIR bug/feature/operator error?
I have sometimes experienced that the new window, the device window, lands behind the main window, completely covered by the latter. If the popup window is modal (which is the default), this looks like a lock up. Nastypogo wrote:... when I tried the "edit device" button the app appeared to simply lock up.
A work-around is to check Options -> Advanced -> use non-modal Device Editor, and when the popup occurs, move the parent window away. Does this solve your problem?
I use Linux/Fedora 42/Cinnamon and the Metal LaF (Unless I am testing something else...).
I must say that, although I hate modal windows, RMIR is not written to allow intertwined editing in the main window and a device editor.
Re: RMIR bug/feature/operator error?
It really doesn't matter whether it's modal or not (although you make a strong case against modal). The upgrade editor window alwasy opens in the foreground in RMIR 2, and always opens in the background in RMIR 3.Barf wrote: A work-around is to check Options -> Advanced -> use non-modal Device Editor, and when the popup occurs, move the parent window away. Does this solve your problem?
Not that big a deal, just puzzling behavior. As long as I keep the editor window just slightly larger than the than the main window it's easy enough to grab it when it opens. I'm mostly annoyed that it took me more than two days to figure out what was going on. The benefits of 3.2 for me far outweigh a minor annoyance. I can finally manage all of my remotes on the MacBook Pro from the comfort of my easy chair.
Apologies for the delay in responding, but I have had both health and computer problems. Bengt, I think the calls toFront() are in the right places The issue seems to be that when the Device Upgrade Editor (DUE) window is created, it does not receive the focus. I understand that focus management is OS-dependent, so this makes sense to me as the issue is clearly OS-dependent. I cannot explain why RMIR v3 behaves differently from RMIR v2 in this respect, but I have posted development build RMIR v3.2.5 in the usual place which contains an attempt to ensure the DUE does have the focus when it is opened. Please try it and let me know if it has made any difference.
Graham
Graham,
I wish you the best of health both for your body, your soul and your computer(s).
As I said previously, although I have encountered the problem in the past, I could not reproduce using 3.2.4. If a potential problem in RMDU has been fixed, if something in my environment has been changed, or if I simply cannot recall what I did, is something we will probably never know. So the ball is by pogo.
I downloaded 3.2.5 (man, is Sourceforge slow today! ) and everything looked fine.
I wish you the best of health both for your body, your soul and your computer(s).
As I said previously, although I have encountered the problem in the past, I could not reproduce using 3.2.4. If a potential problem in RMDU has been fixed, if something in my environment has been changed, or if I simply cannot recall what I did, is something we will probably never know. So the ball is by pogo.
I downloaded 3.2.5 (man, is Sourceforge slow today!
) and everything looked fine.Ditto from me. I understand health problems too well.Barf wrote:Graham,
I wish you the best of health both for your body, your soul and your computer(s).
Ditto again. I'm really coming to believe that it's something in my setup.Barf wrote: ...if something in my environment has been changed, or if I simply cannot recall what I did, is something we will probably never know.
With every new iteration of MacOS Apple seems to get more fanatical about protecting me from myself.
I did download 3.2.5 and get no love, however in today's fiddling did uncover the reason I could up/download from my JP! remotes in version 2. in order to use RMIR on my Mac the first time I run it I have to acknowldge that I really do want to run something from an unknown developer. Then I have to open security in settings and for each jnilib file acknowledge that I know it's from an unknown developer and I want to allow it anyway.
Then we quit RMIR and restart it so I can say yes to the question do you want open for RMIR and each jnilib file I've allowed. Turns out when I installed version 2.12.8 I missed libjp12serial.jnilib. It's been an exercise, but I'm learning as I go.
Apologies for another delay but my problems continue 
. I have now posted development build RMIR v3.2.6 in the usual place, which is a second attempt to resolve the Mac OS Sonoma issue. If this doesn't work either then I'm afraid I will have to put it down to something in your setup, as you suggest.
The issue does seem to be OS-specific, which is why I thought it was related to focus management. I have since discovered that the operation of toFront() is also OS-dependent, so this time I have tried adding toFront() to the Device Upgrade Editor window when it is created. If this doesn't work then I am completely out of ideas.
. I have now posted development build RMIR v3.2.6 in the usual place, which is a second attempt to resolve the Mac OS Sonoma issue. If this doesn't work either then I'm afraid I will have to put it down to something in your setup, as you suggest.The issue does seem to be OS-specific, which is why I thought it was related to focus management. I have since discovered that the operation of toFront() is also OS-dependent, so this time I have tried adding toFront() to the Device Upgrade Editor window when it is created. If this doesn't work then I am completely out of ideas.
Graham
Sorry Barf, I don't understand what you're telling me. (No lack of ignorance hereBarf wrote:@pogo:
Apologize if this has been said before, or is trivial: but have you tested if all LaF (look and feels) behave the same? In another thread, LaF tuned out to be critical.
)Mathdon, tried 3.2.6. Here's the kink. Every time I open RMIR the device editor opens in the foreground first time it's invoked. Opens in background every time thereafter.
Pulldown menu Options -> Look and Feel; there are a few to select from. Try it. Selecting another LaF changes not only how some GUI elements look, but also some interactions are changed. For example, if a mouse click triggers an "action", the LaF can determine if the down-click, or the release, triggers the very action.
I take it that it opening in the foreground first time is new to v3.2.6. What are you then doing? Are you closing it then re-opening it or minimizing it then bringing it back to normal view? When it opens in the background, visible but partly obscured by another window, does it have the focus?pogo wrote:Mathdon, tried 3.2.6. Here's the kink. Every time I open RMIR the device editor opens in the foreground first time it's invoked. Opens in background every time thereafter.
My reading of the code is that if you are closing it with either the OK or Cancel buttons then re-opening it SHOULD behave exactly as opening it the first time. If you are raising it from minimized state then the issue is one of focus.
At least we seem to be getting somewhere in diagnosing the issue.
Graham
Closing the window with the Mac red ball, not minimizing. Edit window always gets the focus when it opens.mathdon wrote:I take it that it opening in the foreground first time is new to v3.2.6. What are you then doing? Are you closing it then re-opening it or minimizing it then bringing it back to normal view? When it opens in the background, visible but partly obscured by another window, does it have the focus?pogo wrote:Mathdon, tried 3.2.6. Here's the kink. Every time I open RMIR the device editor opens in the foreground first time it's invoked. Opens in background every time thereafter.
I had not tried the cancel or ok buttons. tried both now. behavior is the same no matter what method is used to close the editor.My reading of the code is that if you are closing it with either the OK or Cancel buttons then re-opening it SHOULD behave exactly as opening it the first time.
Oh, barf, no luck at all with LaF.