Previous: 12 Printing graphics
Next: 14 Inputting and editing tables
In this section:
Windows behaves by default with an assumption that the computer’s screen is measured in inches, and that it displays 96 pixels per inch. These aren’t real inches, but relative inches, or as Windows puts it illogically, logical inches. The 96 is therefore the logical dots per inch (DPI). On high resolution displays, especially on physically small screens, the assumption of 96 logical DPI can lead to text, especially, being rather too small to read easily (or at all). Microsoft’s answer to this problem is a simple one: and that is basically to increase the logical DPI setting, and of course, you can do this too as a user setting. Back in Windows 7, it was possible to change the DPI setting to more or less what you like, but Windows 10 has a restricted range of logical DPI settings, notably 120 and 144.
Several things flow from the choice of ‘DPI’ whether logical or not, and one of them is the impact on fonts specified in points. A 36-point character would take half an inch, which would be 48 pixels high, and some heights would also map to exact numbers of pixels, but others to fractional pixels, so the characters are rounded up or down. Hence, whereas a 36-point character would be 60 pixels at logical DPI of 120, a 10pt character which is 5/36 of an inch in height wouldn’t be an exact number of pixels at any of the standard DPI settings.
While this scarcely matters at printer resolutions, it does on a screen, especially with text. It also matters with things specified directly in pixels, because they aren’t scaled, and to a large extent ClearWin+ behaves as though it was designed for 96 DPI!
The problems that can arise with a DPI setting other than 96 include:
There isn’t a simple solution if high DPI settings mess up your dialogs, The only way I know is to interrogate Windows to find the DPI setting for the device with the handle jHDC, which we get using the Windows function GetDC, fed with the parameter 0 (meaning the screen):
jHDC = GetDC (0)
IXDPI = GetDeviceCaps (jHDC, LOGPIXELSX)
IYDPI = GetDeviceCaps (jHDC, LOGPIXELSY)
(DC means ‘Device Context’)
Then, after testing your program on computers using high DPI settings, either modify your dialogs so that they still work, or program alternative dialogs that are used according to the DPI setting found. If possible, avoid relative and absolute positioning, and use them only if you have to.
To hark back once again to the early history of personal computers, it was by no means certain that IXDPI and IYDPI would be the same, but there came a point where most graphics systems used ‘square’ pixels, and they are the same. I would advise not trusting this, as there is a possibility, albeit a remote one, that they aren’t the same.
You should note that anything that relies on points, for example, SIZE_IN_POINTS@ will be scaled, whereas anything defined in pixels will not, and also that pixels do not necessarily coincide with points, except perhaps at 150% scaling, where a point equals 2 pixels. The grid as defined by %gd is also an exact number of pixels, and hence ClearWin+’s alignment of things in dialogs may change with the scaling.
I have friends who are rich enough to afford laptop/tablets of the Microsoft Surface family, and I once had a rather large screen, but heavy to carry, Acer desktop-substitute ‘laptop’ that was fine to carry in the boot of my car and lug only a small distance, but which was really too heavy to carry any distance. What you will find is that your application will need to be designed to look good on a variety of monitor sizes as well as those that have large font settings by default. The problem that manifests itself is unlikely to be with the Microsoft defaults, because Microsoft can afford to do a huge amount of user testing. It is far more likely that the problem will arise from some choice that you have made, for example in the size of the icons for toolbars or in the size of particular features in a graphic. To avoid such difficulties, it is wise to be aware of the size of the screen and to draw things on a screen drawing surface with the size and resolution of that display firmly in mind. There is very little that you can do about toolbars and toolbar icons except to produce multiple versions (with the concomitant effort required in creating bitmaps) suitable for each family of variants.
A particular issue that is comparatively easy to solve is the placement of toolbars. In ClearWin+, the placement is essentially decided when you build the master window. The traditional placement of toolbars is immediately underneath the menu bar, but, with a low resolution monitor, particularly one with a widescreen format, then assuming that whatever goes on in the rest of the client area can accommodate it, it may well be better to position toolbars down the left hand side of the screen.
I found that having designed the toolbars in section 10.12, they were unsuited to putting down the left-hand side and so my experience is that you should investigate this possibility before you settle on a format that prevents you using the icons in a particular way.
Some monitors may rotate so that you can have either a landscape or portrait format with Windows resizing some things automatically. This may happen whether you like it or not on some tablet computers. If you think it is an issue, and cannot program round it, then it may be something that you have to highlight in the program documentation. I have monitors like that but never rotate them into the portrait orientation because it is so difficult to get them realigned back, although I suspect that if I only had one monitor, I might be more prepared to rotate it when I had work to do that is taller than it was wide, for instance writing this book!
Ordinarily I would use the ‘along the top’ position for my main toolbars and reserve the ‘down the side’ position for a toolbox of icons for graphic interaction. When I have had to use the lefthand side and not the top position then I have been fortunate that they have been applications where there are comparatively few toolbar actions.
I operate with a dual monitor setup, and find sometimes that applications do not work quite so well as they do on a single monitor. For example, if an application is moved to a different monitor, then dialogs continue to appear on the original one. This ‘feature’ affects some commercial software too! I also sometimes lecture with a projector attached to a computer, and almost inevitably the projector does not work with the same resolution as the laptop or computer monitor, and some trials are required to make sure that fine details continue to show, for example pastel shades may not render so well on the projector.
ClearWin+ does not have any specific features that deal with the multiple monitor case, and so you are thrown back into the arena of Windows functions, for which there is no help generally in the ClearWin+ documentation, although with a great deal of foresight all of the Windows functions and the names of their parameters are defined in the .INS files (or equivalent .MOD files), so that once you get the hang of using the functions they are easy enough and work with Fortran.
The problem of lacking documentation is that you may not even know that a function exists at all. One way of discovering whether a function exists is to look at the .INS files, and then follow up something that looks interesting or relevant in the webpages maintained by Microsoft for the Microsoft software development network or MSDN.
The projectors installed in university lecture theatres and large auditoriums are usually much higher resolution and with far better colour rendition than portable projectors or those in seminar rooms or meeting rooms. Sometimes you will find that meeting rooms are equipped with what is basically a fancy TV screen to which you connect your computer rather than using a projector. The issues are still the same as far as programming is concerned, but you will find that a hand-held laser pointer does not show up on the TV screen type, and may be too weak for the lecture theatre screen. (Pointers that are bright enough for large lecture theatre projection can potentially damage eyesight. My advice is to not even try.)
If you rely on the internet for up to date help information, then a user who is working without the requisite connection may be left stranded. Nowadays, the era of great big user manuals is behind us, and anyway, who carries them on their travels? It pays to have at least basic help integrated into the application itself, with only updates online. It may then be useful to permit updates to be downloaded when there is a connection.
Something similar applies to user authorisation that requires an internet connection. None of my software has ever needed that, and the only time I have ever used a password is to stop casual or accidental alteration of data where a publicly-accessible password is all that it takes to prevent accidents. PASSWORD is an option with the %rs edit control, where the characters typed appear onscreen as asterisks.
FORTRAN and the ART of Windows Programming, Copyright © Eddie Bromhead, 2023.