dy@imsl.UUCP (Demetrios Yannakopoulos) (05/08/89)
I am writing an interactive application in the Aegis environment, which
uses a "more"-like utility programme a lot. The height of the current
window, therefore, is of major importance to the programme. The user,
however, can resize the window during this interactive process.
To obtain the height I use (in many appropriate spots) the following
system call:
pad_$inq_windows(..., wind-struct, ...)
The fun starts after I issue the above call. Then the returned height
which is in number of lines, is not always accurate. It can be +/- one
line off (apparently, it is rounded up/down to the nearest number of
full lines). Hence, the next "more" screen can one line too much or one
line less!
Given that during the process nobody touches the fonts, rasters, etc
(which maintain their original default values - whichever may be),
is there any way I can have more control over the resizing or/and the
returned information? Is there a way to use the raster units information
to calculate the precise number of lines?
The application is using system calls, is written in FORTRAN and
no C code is allowed.
The window used is a read-only one, with an input pad at the bottom.
During the "more" utility the input pad disappears (!)
By the way, I have another qustion which is also windows-related:
How many windows are actually in the default "window"?
I have called the Apollo guys (...or should I say HP ???) and I
have been told that there are two: the top (big) one which is usually
read-only, and the bottom read-write one (usually one line plus
"something" height).
Are these two independent? Why the bottom one disappears during the
"write"-ing of the text in the upper screen?
Any advise would be appreciated very (..VERY) much.
--
IMSL, Inc. Demetrios Yannakopoulos
2500 ParkWest Tower One
2500 CityWest Blvd. (713)-782-6060 x2307
Houston, TX 77042-3020 UUCP: ...!uunet!imsl!dy oj@apollo.COM (Ellis Oliver Jones) (05/12/89)
In article <621@imsl.UUCP> dy@imsl.UUCP (Demetrios Yannakopoulos) writes: > pad_$inq_windows(..., wind-struct, ...) > .....the returned height > which is in number of lines, is not always accurate. It can be +/- one > line off (apparently, it is rounded up/down to the nearest number of > full lines). Hence, the next "more" screen can one line too much or one > line less! By default, these quantities are relative to character sizes in the current font. You can cause them to be reported in pixels instead by using pad_$set_scale ( stream_id, 1, 1, &status); > During the "more" utility the input pad disappears (!) Indeed, the more(1) utility invokes the VT100 emulator. The VT100 emulator uses these fonts: /sys/dm/fonts/vt100l.dw (double wide) /sys/dm/fonts/vt100l.dhb (double high, bottom) /sys/dm/fonts/vt100l.dht (double high, top) /sys/dm/fonts/vt100l (ordinary, default) /sys/dm/fonts/vt100l.b (bold) (Under some circumstances it uses the vt100s series instead. To find out what fonts it's using at any given moment, do /com/las vt100_server .) Possibly the reason for your problem is that these vt100 emulator fonts are different from your dm default, and therefore the pad-height computation is being done with wrong input data. You could try doing a pad_$set_scale before your pad_$inq_windows, and computing the rounding based on the VT100 font sizes rather than the DM default font sizes. > I have called the Apollo guys (...or should I say H-P ???) Slack the rope, hangman! :-) We still have a few more days of being Apollo before the beginning of the H-P era! > ...I have been told that there are two: the top (big) one which is usually > read-only, and the bottom read-write one (usually one line plus > "something" height). Yes, that's so. See the writeup on pad_$create for more info. > Why does the bottom pad disappear during the > "write"-ing of the text in the upper screen? The VT100 emulator calls pad_$raw which hides the input pad. /Ollie Jones (speaking for myself, not for Apollo or any other company.)