Dialog size on a tablet

[milesg]

I have a Winbatch program that opens a dialog with numerous buttons displayed on it. When I run this program on a Windows 10 Tablet the dialog screen is minute, so much so that it is impossible to ready the text on the buttons. Is there an easy way to control the dialog screen, button and font size on high resolution tablets?
Thanks

[td]

Your problem isn't so much  display pixel dimension as it is the current scaling factor.  Your dialog control sizes would be readable on your tablet, if the scale factor was set to to a greater percentage. (This can be thought of as making an inch bigger...)

You have a few options for addressing this issue.  You could create one your more dialog templates that are targeted for specific scaling factor plus pixel dimension configurations or you could try to use Jim Taylor's dialog size adjustment script to dynamically change the size of your controls.   

http://forum.winbatch.com/index.php?topic=1866.msg9415#msg9415

If you chose the latter, you must keep in mind that as the controls get bigger you can not put as many of then on a dialog without overlap.  One way to determine if you need to adjust the size and position of dialog controls and the size of the dialog is to check how many pixels it takes to make a single dialog unit in each dimension given the display's pixel dimensions.   The WinMetrics function's request -6 and -7 can be used to obtain that information.  Use the WinMetrics function's request 0 and 1 to obtain the display's pixel dimensions. 

[JTaylor]

Assuming I understand the response regarding my resizing functions, which I may be missing the point, there should never be any overlap if configured properly.  The controls will scale/move smoothly with the dialog growth but as one might expect, it simply gets more tedious configuring the MOVE/GROW settings the more controls you have.


Jim

[JTaylor]

The part I am not certain of is changing fonts?   That cannot be done directly can it?    If not, if one loads the Dialog code with the "Do Not Process" option can one change the Dialog Variables and then call the Dialog and achieve that end?   Or, will growing the Dialog solve the font issue?

Jim

[td]

Assuming I understand the response regarding my resizing functions, which I may be missing the point, there should never be any overlap if configured properly.  The controls will scale/move smoothly with the dialog growth but as one might expect, it simply gets more tedious configuring the MOVE/GROW settings the more controls you have.


Jim

I believe you are missing the point.   You can only make a set of controls so big  before there is not enough room on the screen to display them without overlap unless you implement scrolling and I wasn't address the specific intended usage of your script.   The point is of concern because the OP stated that the dialog had "numerous buttons" and was looking for a way to resize the dialog to make it legible on a table with high pixel density and potentially low percentage scaling.  It is not the same problem your script solves but some aspects of it could be used for or are at least suggestive of a solution to this problem.

[td]

The part I am not certain of is changing fonts?   That cannot be done directly can it?    If not, if one loads the Dialog code with the "Do Not Process" option can one change the Dialog Variables and then call the Dialog and achieve that end?   Or, will growing the Dialog solve the font issue?

Jim

You would need to edit the template with the correct font before calling the Dialog function.  That could be done using the Item* functions or substitution.

[JTaylor]

Thought so but wanted to make sure I was thinking correctly in addition to offering it as a suggestion.  Thanks.

Jim

You would need to edit the template with the correct font before calling the Dialog function.  That could be done using the Item* functions or substitution.

[JTaylor]

Understood but if properly configured the controls could never grow big enough to overlap because not only can you grow them you can and would also move them as needed....unless there is something about this particular situation that would confuse the sizing and moving and maybe that is where I am going wrong???   I'll do some testing because you now have me curious :)

Jim

I believe you are missing the point.   You can only make a set of controls so big  before there is not enough room on the screen to display them without overlap unless you implement scrolling and I wasn't address the specific intended usage of your script.   The point is of concern because the OP stated that the dialog had "numerous buttons" and was looking for a way to resize the dialog to make it legible on a table with high pixel density and potentially low percentage scaling.  It is not the same problem your script solves but some aspects of it could be used for or are at least suggestive of a solution to this problem.

[JTaylor]

In the event it might be helpful....here is a test case.  Created this in an 800x600 environment.   Assuming a fairly recent version of WinBatch here.  Would be very interested to know if it grows correctly as I only have a 1920x1080 display.  I did not do anything with fonts.

Jim

[JTaylor]

Perhaps a better example...but still didn't attempt the font change.

Jim

[td]

Understood but if properly configured the controls could never grow big enough to overlap because not only can you grow them you can and would also move them as needed....unless there is something about this particular situation that would confuse the sizing and moving and maybe that is where I am going wrong???   I'll do some testing because you now have me curious :)

The underlying concern is that  "if properly configured" may not be big enough to achieve the desired readability goal because of the number of controls and several other unknowns.   Because of variables like scaling there are simply too many unknowns to conclude one way or the other.  So the hart of the issue being raised has nothing to do with whether or not your script works correctly.  The concern is about it being the appropriate solution.

The Windows OS has built in support for high resolution displays like 4096 x 2160 pixels monitors.  For example, WinBatch's UI applications have a manifest setting that lets the OS know that applications understand this type of display.   The most troublesome part of OS support from a developer's perspective is scaling.  The user adjustable scaling factor controls the size of UI elements like dialogs and their buttons without affecting the size of other display elements like video.  This can lead to multiple issues when designing user interfaces - even on monitors with the same native pixel dimensions.

One of the projects on the to-do list is to get our hands on some more large and small form factor high resolution devices so that we can determine whether or not we need to better support them in WinBatch.   High resolution displays are likely going to become more common on both the large and small form factor in the future.

[td]

Thought so but wanted to make sure I was thinking correctly in addition to offering it as a suggestion.  Thanks.

Jim

You would need to edit the template with the correct font before calling the Dialog function.  That could be done using the Item* functions or substitution.

It's good that you pointed it out.

[JTaylor]

And since I don't know how to quit :)     Here is an example showing font change on screen resolution.   It is very crude and I took the easy way out by using the Dialog Font rather than Control Fonts but gives an idea of what one could do.

Jim

[td]

Ran a every quick and dirty test of the script using a VM guest OS*  by trying a few combinations of display resolution and scaling.  Ran into a couple of combinations where I could not get it to display without some text being clipped but I am sure that was nothing that could be fixed with a little tweaking.  The caveat being that this limited testing was done on a conventional workstation form factor.     

Nice work, not knowing when to quit is a good thing, and thanks for sharing.

*  VMs simulate screen resolution by making a virtual monitor bigger or smaller and adding scroll bars when needed so it is not exactly the same as testing on systems with different native display resolutions. 

[JTaylor]

Yes.  My choice of font size was done with more guesswork than testing as it was simply to demonstrate that one could automate the resizing of controls and fonts.   It would definitely need a bit more fine tuning for production.

Jim

[td]

I suppose one could try making a few DllCalls to recalculate and set the control fonts on the fly.  I vaguely remember writing a script that did something like that many years ago but I am not sure it ever made it into the Tech Database.  If it didn't make it, it was likely for a reason.

[JTaylor]

I wondered about DLLCalls and started to ask but got distracted with other things.

Jim

[JTaylor]

Guido, of course, has the answer but not sure if the work would be worth the trouble.   Probably not that wide of range of resolutions and would seem easier to decide on font size for the environments and then just check at the beginning of the script and set the desired font size.

Wonder how Guido is doing?   For a Pharmacist he sure knew Windows.

Jim

[td]

Of course, dynamic fonts are created and used frequently in Win32 based Windows application.   Recently wrote a library test driver that took advantage of fonts to improve readability.   I wanted easily readable visual output to be used during development in addition to the file output used during testing.   It's one of those cases where implementing a solution in low level native code was much simpler than in a high level scripting language. 

The OP's combination of small form factor, high resolution, and minimal scaling adds an additional variable to conventional monitor resolution and scaling.  It is something that will need to be investigated for future possible enhancements at some point.