Function name incomplete in button hover box

[CyberSimian]

I created a new device upgrade for my amplifier by starting with a code set that was built-in to my XSight Lite. The built-in code set is for a CD, but it has functions that control the volume (which is what I was looking for). However, it lacked the functions to select the input, so I copied those from other files. I assigned the functions to digits 1 to 6, and gave the functions these names:

MD/Tape 2
Tape 1
CD
Tuner
Phono
Aux

I uploaded the definition to the remote, and it works fine. However, I noticed the following oddity in RMIR: when I position the mouse pointer over the button on the "Layout" tab, the hover box appears, but the text for the function name shows only the first word (in the buttons for digits 1 to 3), or no words at all (in the buttons for digits 4 to 6). So :

"MD/Tape 2" appears as "MD/Tape"
"Tape 1" appears as "Tape"
"Tuner" appears as ""

I took a screen shot, but it does not seem possible to attach images to posts.

-- from CyberSimian in the UK

[The Robman]

I took a screen shot, but it does not seem possible to attach images to posts.

https://www.hifi-remote.com/forums/faq.php#19

https://www.hifi-remote.com/forums/viewtopic.php?t=6557

[CyberSimian]

Rob:

Thanks for the hints on where to place images, but as far as I can see, I need to sign up for yet another web site that will sell my contact details for spam, so I think that I will pass on that one.

Hopefully Mathdon can reproduce the problem from my description (the screen shot is merely a "nice to have").

While on the subject of RMIR, I have just added some notes to the device upgrade, and when I looked at the RMDU file after saving it, I noticed that the "Notes=" line occurs twice:

- Once following the "Remote.signature=" line.
- Once preceding the first "Function.0=" line.

The RMDU file reloads without error, so the duplication does not seem to cause a problem.

-- from CyberSimian in the UK

[mathdon]

I noticed the following oddity in RMIR: when I position the mouse pointer over the button on the "Layout" tab, the hover box appears, but the text for the function name shows only the first word (in the buttons for digits 1 to 3), or no words at all (in the buttons for digits 4 to 6).
...
Hopefully Mathdon can reproduce the problem from my description (the screen shot is merely a "nice to have").

If you want me to investigate this, please post a .rmir file that has this problem.

[The Robman]

Rob:

Thanks for the hints on where to place images, but as far as I can see, I need to sign up for yet another web site that will sell my contact details for spam, so I think that I will pass on that one.

Sure, then no images for you!!!

[CyberSimian]

If you want me to investigate this, please post a .rmir file that has this problem.

I put the RMIR and RMDU files here:

https://www.hifi-remote.com/forums/dload ... e_id=26093

-- from CyberSimian in the UK

[mathdon]

Sorry for the delay. I have just tried this in Windows 10, RMIR v2.12.0, Java 8 with Windows Classic look and feel and cannot reproduce it. All appears exactly as it should. MD/Tape 2 and Tape 1 show the numbers, buttons for 4-6 show the names correctly. So the problem must lie in the OS, the Java version or the look and feel. Can you say exactly what you are using?

[CyberSimian]

the problem must lie in the OS, the Java version or the look and feel. Can you say exactly what you are using?

Here is the relevant data:

- OS version = Windows 10 version 1607
- Java version = Java 14
- Java text scaling = 150%
- Physical screen resolution = 1920x1080
- Windows screen resolution = 1600x900
- Windows text scaling = 125%
- RMIR = 1.12.0
- Look and feel = not changed from default

The symptoms are somewhat indicative of the last word in the hover text being omitted, but it does not affect every button. All of my new buttons are affected, but some of the existing buttons are affected too. From memory, "Search Forward" appeared as "Search", but "Search Reverse" appeared correctly.

I shrank the screen shot (so as not to occupy too much space), and placed it here (I hope this is allowed):

https://www.hifi-remote.com/forums/dload ... e_id=26098

-- from CyberSimian in the UK

[mathdon]

I have changed to Java 14 with 150% scaling, and reset look and feel to the default of Windows (from Windows Classic) and still everything looks correct. My Windows 10 is version 2004, display resolution is 1920x1080, Windows scaling is 125% so almost everything is the same now as yours. My Win 10 version is later than yours but that seems to be the only difference. So I cannot explain it. You might try updating the Win10 version but it might be something else unique to your machine. I don't think there is anything further I can do.

[CyberSimian]

My Windows 10 is version 2004, display resolution is 1920x1080, Windows scaling is 125% so almost everything is the same now as yours.

Thanks for investigating this, Graham.

I thought that the problem might be caused by the logical screen size (1600x900) being different from the physical screen size (1920x1080), so I changed the logical size to 1920x1080, and the problem disappeared!

But when I tried to return to my original settings, I could not get back to the original text size. 1600x900@125% now used the same text size as 1920x1080@125%.

These changes were made in my test partition. But I have a reference partition which I keep in a "clean" state (very few applications installed), and that still displayed larger text for 1600x900@125%.

Looking at my notes, I see that I had customised the sizes of some of the individual text components, increasing the font size from 9 to 10. So I suspect that this customisation is what has caused the problem.

Unfortunately, these customised text sizes are reset when the screen resolution and/or overall text size are changed, making these customised sizes rather too volatile for permanent use. I will have to reconsider my strategy for text size in Windows 10.

Thank you for taking the time to investigate this, and apologies for wasting your time on a problem of my own making.

-- from CyberSimian in the UK

[CyberSimian]

apologies for wasting your time on a problem of my own making.

I have simplified my text-size strategy, but I still get the problem of missing hover text, so I no longer think that it is a problem of my own making.

I eliminated the use of customised text size for individual panel elements, and used Windows defaults. I also defined the logical screen size (Windows screen size) to be the same as the physical screen size (1920x1080).

Windows text scaling of 100% and 125% gives text that is far too small to read on a 15-inch laptop screen. A scaling of 150% is slightly too small for comfort, so I have settled for the time being on a scaling factor of 175%.

With the above settings, the Java 14 scaling factor of 150% is no longer big enough, so I changed that to 200%.

Even with these extreme settings, the panels generally look OK, but one problem is the hover text. I was testing a device upgrade for a Humax DVB-T tuner box. The definitions built-in to the XSight Lite define soft button 12 to be "Page Down", and soft button F to be "Page Up". This is what the hover text looks like for soft button 12:

Button: Soft12
Device: DVB-T (1427)
Function: Page Down

This is what the hover text looks like for soft button F:

Button: SoftF
Device: DVB-T
(1427)

Notice that the device name "DVB-T (1427)" is split over two lines, and the function-name line is missing completely. The width of the hover box varies according to its contents. The width should be:

max(button_line, device_line, function_line)

but it looks as though the code is taking only the length of the function line. For soft button F, the function line is "Function: Page Up", which (allowing for proportionally-spaced fonts, and maybe kerning too) is narrower than the device line. So the width of the hover box is too small, causing the device line to be split over two lines. Since the hover box is only three lines in height, it means that the function line is pushed below the bottom of the hover box, and so is not visible.

This behaviour is not specific to any particular device, and can be seen with any device upgrade that has an unfortunate combination of button name, device name, and function name.

-- from CyberSimian in the UK

Edit: changed a wrong reference from "soft button 12" to "soft button F".

[mathdon]

The problem may not be of your making, but neither is it of my making. The display feature uses what Java calls a "tooltip" and the code sets the text of that tooltip but it is up to Java how it displays it. I have just looked at the layout panel for an upgrade that I have been working with that has a long device name. I see a display, for example, of

Button: 4
Device: Marantz Audio
Function: 4

where the Device entry is entirely visible and far longer than the other two lines. So wherever the problem lies, it is not something in my control.

[Barf]

The display feature uses what Java calls a "tooltip" and the code sets the text of that tooltip but it is up to Java how it displays it.

Exactly. And the way to render the text is determined by the currently active Look-and-Feel (LAF). A LAF may even decide to ignore tooltips altogether...

So I suggest (for understanding of the problem) to try all the available LAFs (in particular Metal and Nimbus), to see if there is any difference. And please leave out scaling while debugging.

[CyberSimian]

I suggest (for understanding of the problem) to try all the available LAFs (in particular Metal and Nimbus), to see if there is any difference.

I checked all of the "Look and Feel" choices, using one of my RMDU files that exhibits this problem. I retained the scaling, since for me (as a user) the whole point of this is the scaling.

Windows screen resolution: 1920x1080 (== physical screen resolution)
Windows text scaling: 175%
Java 14 text scaling: 200%

What I found is this:

(1) "Metal", "Nimbus", and "Motif" all displayed the hover text correctly. I checked the text for all buttons, and all were correct. For some buttons, the device line was the longest, while for other buttons the function line was the longest, but all displayed correctly.

(2) "Windows" and "Windows Classic" exhibited the missing hover text for some buttons.

-- from CyberSimian in the UK

[Barf]

(1) "Metal", "Nimbus", and "Motif" all displayed the hover text correctly. ...

(2) "Windows" and "Windows Classic" exhibited the missing hover text for some buttons.

So it appears that we have found the culprit. As Graham wrote, there is no way we can fix it.

If you really care, you can see if there possible is one JVM where it is working, but subjectively I would say that the chances are slim: probably someone decided that the current behaviour is the correct one for Windows ("feature, not a bug").