Index Keywords list scrolls to wrong position

[Greg Smith]

When I have the Index tool visible and type a keyword that requires a scroll of the list to display it, the next matching keyword is highlighted, BUT it is often off the bottom of the screen, so invisible. I wonder if you have made some assumption about screen resolution when calculating positions? This happens when H&M is on a seconday screen set to 100% scale, but I have a high-res main screen set to 175%.

In any case, why do you put the match at the bottom of the page (possibly minimum scroll distance)? I am often looking for sub topics of the keyword, so bottom (even if it were visible) is pessimal for my use. Top or middle would be better, for me.

Greg Smith

[Tim Green]

Hi Greg,

That depends a lot on which skin you are using. Is it one of the standard skins included with Help+Manual, with the "keyword list" phrase in its name?

[Greg Smith]

Hi Tim,

Many thanks for your (always) prompt reply.

This is a project that has been in use for years through several versions of H&M... I have not looked at skins in many years... OK, found in in the Publish format... I am using: CHM Skin, Dark Blue Header, Feature Images, Print.hmskin

However, how can this have anything to do with what happens when writing help... Oh, you are assuming I am talking about what the user sees. Sorry, I did not make this clear. I am talking about the Keywords pane that appears in the H&M IDE when writing help, not the index that the user sees.

Greg

[Greg Smith]

Hi Tim,
Did you see my clarification? Or have I misunderstood your original response?
Greg

[Tim Green]

Did you see my clarification? Or have I misunderstood your original response?

Sorry, I did see your response but I got distracted before I could answer and then your posting was no longer listed as "unread". My bad...

You're right, the keywords do scroll into view, but only right down at the bottom of the pane. I'm passing this on as a Wish List request.

[Greg Smith]

For me, they scroll,very annoyingly, just off the bottom of the list. My guess is that this is because my secondary screen does not have the same scaling as the primary. I am hoping that if you aim for the top, or second best, the middle, this will be less of an issue. I regularly work with my application running on the Main screen and H&M on a second screen.

My main screen is 3840x2160 at 175% (my eyesight is not what it was), and the secondary screen I use for H&M is a mere 1920x1200 at 100%.

I know (from bitter experience coding it) that having multiple monitors with different dpi and scalings is a royal PIA... I keep making a case for all my screens to be the same resolution but with no luck so far!

I have just tried things out with a different H&M project that I created a year ago (so no inherited files from years ago) and this reliably places the found topic at the bottom of the list. In my mega project (which has many times more index entries), I typed in 'X' and the bottom of the visible list was in the 'W' region and I had to scroll down 45 lines of index to find the highlighted topic... and this was on the main screen this time. If I drag to the secondary screen and repeat, the X entry is 53 lines or so below the bottom of the visible list, so the screen does make a difference. However, the index has 4700 or so entries, so maybe that is something to do with it. The recent project that worked OK (i.e. the desired entry was visible at the bottom of the visible list) has a couple of hundred entries.

[Tim Green]

Hi Greg,

For me, they scroll,very annoyingly, just off the bottom of the list. My guess is that this is because my secondary screen does not have the same scaling as the primary.

Hmm. Is the list undocked and on the second scree? Try docking it again and/or moving it to the main screen. Does that change the current behavior?

[Greg Smith]

It was docked. I undocked it (a new experience) and the result was still wrong. Docked it again, and still wrong, but not the same as undocked. I wonder if this is a calculation problem based on rounding which varies with the height of the window (which was different in the docked and undocked case) and the length of the list.

Just had a note from Alexander saying that this is fixed in version 10, so I will stop the noise about this. Thanks for your help.