Need better dialog support for MS Surface Pro at 192 dpi

[BrHartmann]

Our QA team has been looking at our product installations on the new Microsoft Surface Pro tablets. At standard resolution (144 dpi), the dialogs looked ok, but in high resolution mode (192 dpi), all the check-boxes, radio buttons, etc. really look quite bad in the standard Installshield dialogs (Installscript project type). It would be a great deal of work to customize all dialogs to try to manually fix this. Does Flexera plan to address this, and if so, when?

Thank you.

[MichaelU]

I took a quick look at this, and while I see some font blurring with the way I tried to set up this DPI, I don't see anything that stands out as objectionable to me. Could you clarify the steps you used to configure the display settings (I'm using desktop Windows 8 rather than a Surface Pro; I'll try to use your request as justification to personally get my hands on one, but won't hold my breath :D), and perhaps attach a screenshot or two that highlight the problems?

[BrHartmann]

Hi Michael,

Thanks for looking into this. I asked our QA specialist who's been working with the Surface Pro, and he mentioned that he went to the dpi settings, selected Custom, then turned it up to 200%. I have a couple screen shots of dialogs with multiple checkboxes or radio buttons. Note that this is from an Installscript (no MSI) project, and it turned out both of these dialogs were customized, so that may be part of the root cause. The dialogs are SdSetupType and SdAskOptions (in the latter case I just needed to add a 5th checkbox). On a related note, there was also a 144 dpi Windows 8 issue I was reminded of where the Welcome maintenance dialog got shifted awkwardly within the Installshield window (this is actually in an Installscript-MSI project, and the dialog was customized to remove the modify option). Let me know if there's anything else you need. It sounds like you're already aware of text not being as sharp as perhaps it could be, so I'll leave those screenshots out for now.

-Brian

[MichaelU]

Alright, in screenshot order, here's what I think you're focusing on as objectionable:[LIST=1]

Borders of the checkboxes are wonky. Presumably this is less obvious or not a problem at 100%

Bold text is wrapped and/or truncated. Presumably it shows fine at 100%.

The dialogcache doesn't work correctly at 200%
Do I have that correct?

I think you can prevent the last of those with Disable(DIALOGCACHE), but that may not be an approach you want to take. The other cases I'll probably have to do more research on in order to diagnose exactly what's going on. It looks like your examples are using skinned dialogs; is this specific to skinned dialogs, or does the problem also occur with unskinned dialogs?

[BrHartmann]

Hi Michael,

My apologies, forgot to check back on the thread for a couple days.

Yes, points 1 and 2 sound about right. I had hoped not to have to do a lot of additional work to handle new user dpi settings for these dialogs with radio buttons and check boxes. I suppose I could enlarge the buttons, but I would need to do this several times (we localize to 9 additional languages, so far), and then I'm concerned making such changes might disrupt the standard cases more widely in use right now (96/120 dpi). It would be great if Installshield handled scaling these buttons so they appear roughly the same at different user dpi settings. The checkboxes are wonky, but the radio buttons having top and bottom truncated seems worse to me (though it is a problem i could probably solve with some customizing if necessary).

The font issue is probably something I could solve by scaling back a bit on the customization of that dialog. Several years ago I was asked to customize the SdSetupTypeDlg mainly to disable the "next" button until a user consciously chose one of the 3 product options (radio buttons), rather than setting one to be a default option (so they would ideally read the descriptions and understand the version they were choosing rather than quickly clicking-through). I was also asked to make the product names (next to the radio buttons) larger font. I took a look at my old script code, and here are some lines that are likely relevant to this problem:

hFontProducts = GetFont("Arial", 11, STYLE_BOLD);
...
CtrlSetFont (szDlg, hFontProducts, SD_RADIO_TYPICAL);

I can send you the full .rul file if that would be helpful.

These are all skinned dialogs. I'm afraid I haven't had a chance to explore this with unskinned dialogs yet. By your comment about the dialogCache, i'm guessing we lose the skin if we clear the cache? I remember at one point some years ago I disabled caching the installation in the release config, bit then uninstalls from ARP had no skin (while running the installer exe file again would still provide skins in maintenance mode). So yes, we'd like to avoid losing the skin, but the shifting in Windows 8 is certainly the greater of the 2 evils.

Thanks,
Brian

[MichaelU]

The state of DIALOGCACHE should not effect skins; instead it changes whether the "BlueBeam Revu x64 11 - InstallShield Wizard" window is visible at all behind the "Confirm Uninstall" window, and other cases like that. Historically it helped smooth transitions between adjacent pages of the wizard, but I don't think it's anywhere near as necessary on Windows Vista or later systems.

It wouldn't hurt to have your customizations around to ensure we fix everything at once (when we can get to it; this sounds like it will be best as part of a larger effort to support high DPI), but the skinned dialog sampler shows very similar behavior to that in the sceenshots. I've filed IOA-000078637 to track this, and can attach further information to it.

[phill_mn]

Not to sidetrack your discussion about a specific problem, but I have had lots of similar problems in the past when using customized skinned dialogs when the DPI is changed on the build PC for InstallScript projects. My problems generally showed up when I would get a new build PC for a new version of InstallShield, which was often related to a change in OS for the new PC. Currently I use a virtual server for my different tool versions and avoid that issue.

Skinned dialogs in which the layout had been customized in the dialog editor would no longer display the skins. See SIOC-000153152 (and I have SIOC-, OA-, and OC- numbers prior to that). At one point Support provided a 'hotfix' but then when the problem happened again with the next InstallShield tool release/ project upgrade, they told me that the solution I was previously given was 'unsupported'. While a 'new' project created with the new tool did not have the same problems, creating all of our deployed products from scratch was not an acceptable option. By comparing the 'new' project with the same customized dialog, with my upgraded, but dysfunctional project, I was able to find in the Direct Editor the parameters that needed to be corrected. The changes I made were to the Width and Height values in ISLocalDialog and ISLocalControl to set them to values that were similar to other dialogs that displayed correct for the specific language. So my situation related to a change to the DPI on the system that built the package, and I am sure that there are problems when the target system has a different DPI that I did not address. I hope this info helps because automatically handling DPI changes on both the build and target system is needed.