forums.silverfrost.com

[LitusSaxonicum]

John,

You don't get to the line after the last (second) WINIO@ call until you finish interacting with the window. By the time you get to GET_WINDOW_LOCATION the window has ceased to exist, so the call is meaningless. The DESTROY_WINDOW@ is superfluous too.

You need to put GET_WINDOW_LOCATION@ inside a callback function to a %cc closure control format code, thus:

[JohnCampbell]

Eddie,

Thanks for your example; I played around with it, introduced %`cc and learnt a bit more about what is happening. I tried this on my 2-screen setup, where the second screen is on the left. This gives -ve Y and X values. I introduced MODULE and more reporting.

John

(Oh the frustrations of the post size limit ! What about a 10th birthday present? )

[JohnCampbell]

[LitusSaxonicum]

Useful addition. Should help comprehension.

I assume without testing that a window left open with %lw could be examined with GET_WINDOW_LOCATION@ in lines of code executed after the last WINIO@. In such a case, it would perhaps be desirable to first check that the window still exists, although I can't find a Clearwin+ function for that.

Eddie

[LitusSaxonicum]

L means make the constant a long integer, i.e. INTEGER*4 even if the default is set otherwise. You could set that in the FTN95 cfg config file, or by including OPTIONS(INTL).

With a %ca@ you need to follow it with a string constant (like JC did) or a string variable. If you use a string constant it's the same as %ca[ ] because it is unchangeable. If you use a string variable then at some later point you can change the contents of the string and call WINDOW_UPDATE@ (name_of_variable).

If you want your application to be universal, you may find yourself getting lots of parameters about the screen and other environmental settings:

[LitusSaxonicum]

John,

It's complicated in more ways than one, because the widths of frames etc are different between different versions of Windows, and the character cell which gives you a lot of the layout in Windows as well as Clearwin+ (but not all, because some is done in pixels) varies with the system font, the version of windows in use, the size of the taskbar and the logical dpi setting - plus, what you want to display in the way of toolbars may depend on the space available.

The trad method is to show the window at a nominal size and let the user maximise it. This doesn't work well in Win8 because that seems to like the newly launched window to be max sized initially.

My applications normally have a master window with the whole client area taken up only by toolbars and a maximum size %gr. I struggle to get the %gr area to fill the remainder of the client area after allowing for the toolbars, and I have experimented with not using Clearwin+ toolbars but running my own, made up from icons, and managing their states myself, but mostly I've used Clearwin's toolbars. Every release of Windows causes my scheme to malfunction, and my study is full of threats of violence to the cannabis-smokers at M$ until I've got it sorted.

The whole logical dpi thing is a nonesensical solution to knowing how many pixels there are, but not knowing the physical size of the screen.

Eddie

[LitusSaxonicum]

Hi John,

Character cell:
Imagine yourself back in the DOS world of 80 characters wide x 25 rows high. If you had a CGA screen of 640x200, the characters would be 8 pixels wide and 8 high, and were all monospaced. If you moved to VGA, which was 640x480, it was possible to have more pixels vertically, or with some graphics cards, to get more rows in. Note that CGA's pixels weren't 'square' - but from VGA onwards they were, and the resolution options blossomed with time.

In Windows, apart from the first few versions maybe, the system font isn't monospaced. Hence, the height of a character cell may be fixed, but its width isn't. So something called the average character cell width is used, which you get by writing out the whole alphabet, and taking the number of pixels divided by the number of letters, then rounding it (up?) you get the average width. The height is simple in comparison: room for ascenders and descenders (up and down bits like bdhl and gjy have etc) and some space top and bottom. Characters always look better with more pixels, and always better with more vertically than horizontally.

Clearwin+ lays out the controls in a window on the basis of a regular grid of these character cells. There's even a format code %gd that draws the grid for you. But, a cell has to be an integer number of pixels wide and high. The upside of this is that it is simple, the downsides are that when things jump to the next cell it is a large jump, exact positioning is difficult (although you do have %ap and %rp) and sometimes text doesn't fit even though the number of characters allowed for is bigger than the number you have (may depend on which characters are involved, where iiiii takes less room than mmmmm). Sometimes you enlarge the font and nothing changes on screen, because original or enlarged, it fits in the same character cell!

The size of an average character cell depends on the font used, which in turn depends on the version of Windows and user selections, so what looks good in 7 may not in 8. It also affects the row spacing, so changes to the number of pixels high of the default font (which is user selectable in Windows) can make things go haywire too. If your user hasn't made any customisation to his Windows, this basically comes down to which version of Windows is he using.

Eddie

[LitusSaxonicum]

John,

Logical dpi
This is worse. You may remember that a point is 1/72 of an inch. I've had printers with various resolutions in dots per inch (dpi): Epsons at 360, 720 and 1440; loads of others e.g. HP at 300, 600, 1200. Take the Epson at 720 dpi - each point was 10 dots (pixels). If I tell the printer my character size in points, it takes care of the resolution setting and I always get the same output. If I tell it in pixels, then the size print I get depends on the resolution setting. The dpi is a real thing.

There is a problem in doing this with a monitor, because Windows doesn't know how big it is. In the early days, monitors were much the same size, and the same aspect ratio (height to width), plus the dots weren't real, they were driven by frequencies in the firmware of the electron gun. With LCD/LED screens the dots are real, and the range of physical sizes, aspect ratios and resolutions is enormous.

At some stage, it became obvious that with those original monitors, the dot size was such that if Windows assumed that the monitor was 96 dpi and the pixels were square, everything panned out right with the scaling from points to pixels. This may even have come from the Mac (ya! boo! hiss!). And as long as monitors don't vary much in size or resolution (1024x768 anyone?), assuming that is just fine. At least, assuming a standard equivalent dpi lets Windows know if a monitor is widescreen.

But, monitors got higher and higher resolution. I bought a 15" laptop with 1680x1080 resolution. On a 24" monitor, the 96 dpi assumption would look fine, but on the laptop, you'd have difficulty reading anything. This was XP, and Windows was just beginning to address this issue. They had a vested interest in the ways things were done up to then, and hey ho - if you alter the dpi assumption things could scale back into the visibility range. At one stage, you could chose any dpi setting, but they have, in later versions of Windows, settled on 96, 120 and 144 settings, and they call these 'logical dpi' because they don't have any bearing on the 'physical dpi'. Logical means something different this side of the pond, but so what?

Note that 120 is 125% of 96, and 144 is 150%, so you see these percentages bandied about too as well as the terms standard, fine and ultra fine.

As you go through from XP to Vista to 7 to 8, the logical dpi thing gets more and more embedded. What's more, from Vista onwards, Windows will take some of the logical dpi settings and do the scaling for you, whereas in XP you had to cope all by yourself. Windows taking care of it means that your hard work in XP was wasted, and things got bollixed up.

Now, remember those character cells based on the average character size rounded up into n*m pixels? Well, when a non-standard logical dpi setting is in place, they don't scale linearly, because the 'into pixels' roundup is done at the end.

Plus, when there is an ultra-fine logical dpi setting in place, Windows doesn't want you to know what the real pixel resolution is, because if you work to that, and it scales the result you'll get a mess. So when Windows' logical dpi scaling is in effect, it lies about what the physical resolution is. All fine and dandy if you know, but not if you don't. And just when you thought you understood it - it only does it for some logical dpi settings.

You ought to get some help by declaring your application 'logical dpi aware' for which there is a standard function. But, MSDN tells you not to use it, and instead, to put it in your application manifest. If you know what that is, then I salute you.

Fortunately, most devices run in standard mode, and if you don't want to run on a Microsoft Surface or equivalent, or a physically tiny tablet - just ignore it (for now). But beware, if a user installs it on a device that needs a non-standard logical dpi, or the user selects such a setting - your program display windows will go out of alignment at best, or be completely garbled at worst.

Eddie

[IanLambley]

Whilst I'm now totally confused and never bother with dpi as I always initially scale the width of a %gr to be 100.0 units and the height in the ratio of the pixel resolutions.
Here are some useful functions:

[LitusSaxonicum]

Ian,

You'll never need to bother with logical dpi as long as your users keep on using the standard setting. When one of them does, you'll know the answer as to why the display is messed up! I've only really come across it once, and that was with an XP laptop of my own.

There are some useful additional functions here, and now I'll look up SystemParametersInfo.

I've found oddities with %gr and an initially maximised window where the %gr doesn't fill the remaining client rectangle after the toolbars are taken into consideration. My workaround has been to get the available screen width and height then take off the frames etc, but not knowing your function I've taken off the system taskbar.

Eddie

[IanLambley]

John,
I am glad that I am not alone in hating C, C+ C++, or any other snobby language that generally looks down of the excellence that is Fortran.

These structures are just like the Fortran user type definitions (or "record" statement from VAX Fortran77), which I always seem to forget to use until I am a long way into a program. Just remember:

[JohnCampbell]

Ian,

I don't think you went too far and I also agree with you. The problem we have is that those who are controlling the direction of Fortran do not appear to agree with us.
I have done courses in Fortran and C and much prefer the approach that Fortran offers. Complex coding structures are a recipe for lots of bugs and that is the direction that Fortran is heading. Holding up a sign saying go back is mostly ridiculed and not fully appreciated.

John

[PaulLaidler]

I have not followed the detail in this thread and I may be missing the point but the following works fine for me...

[PaulLaidler]

The result is a call to ShowWindow(hwnd, SW_SHOWMAXIMIZED) where hwnd is the Windows handle for the main window.

Maybe you need a similar call for the child window that contains the controls and scroll bars.

[LitusSaxonicum]

John,

Put it in the callback to %sc. This is where everything you want done after the window is created should go. You can't put it inline with the WINIO@s because it has to be called after the window is created.

You have to pass the window handle to the callback, which I do via COMMON, and you might do by making the callback function CONTAINSed somewhere or other.

The callback to %sc is where you might also do the initial graphics (we discussed that) and handle the command line to see if the program was invoked by clicking on an associated file - if you do that before you open the main window then your startup may be slowed, plus, if you have to handle any errors, they look odd before your program main window has opened.

Eddie