has@ztivax.UUCP (Hans-Albert Schneider) (04/12/89)
Hi there!
I would like to consult the net's knowledge on some problems
which arose when we did some graphics programming on our machines.
The machines are DN4000 running AEGIS SR9.7.0.3 and Unix SR9.5.
One has a 19" (1024x800 pixel) colour display, the others have
1280x1024 pixel black and white displays.
1) When a window is opened (pad_$create_window) and its upper left
corner is specified to be at or near (0,0), it will be smaller
than specified. The amount of pixels it is smaller seems to
depend on the display type.
Is this a known bug/feature/what_else? Is there a system
call to obtain some correcting values, or could some kind
person provide a table stating all or part of the following
relation:
display type - x_min/y_min - x_corr/y_corr
where x_min/y_min are the x and y coordinates below which the
problem occurs, and x_corr/y_corr are the correcting values?
2) The width and height of the window borders seem to depend on
the screen. Is there a system call to retrieve them, or could
somebody provide me a table?
3) Is there a way to label a (bordered) window? I would like to
have some user defined text in the banner of a window, indicating
it is a "menu", a "browser window", and so on. The label can
change during program execution.
4) My refresh procedure is not called when a refresh is needed,
instead, the window remains blank. (The procedure IS called
by gpr_$acquire, as debug shows.) I was told that it would
be called during an event wait for mouse or keyboard input,
but this is not satisfying.
Here is how I declare and set the refresh procedure:
void refresh_window(unobs,posch)
boolean *unobs, *posch;
{
...
}
main()
{
status_$t st;
gpr_$rwin_pr_t refr_window;
gpr_$rhdm_pr_t refr_hidden;
pad_$create_window("test",0, pad_$transcript, (short) 1, window_data,
graphic_window, st);
gpr_$init(gpr_$direct, graphic_window, bitmap_size, (short) 0,
bitmap, st);
gpr_$set_obscured_opt(gpr_$pop_if_obs,st);
gpr_$set_auto_refresh(false,st);
gpr_$inq_refresh_entry(refr_window, refr_hidden, st);
gpr_$set_refresh_entry(refresh_window, refr_hidden, st);
printf("refresh entries set\n");
...
}
Is there anything wrong with this? Or did I miss something?
From the manuals, I think it should work.
Hans-Albert Schneider
---------------------------------------------------------------------------
paper mail: email: ARPA: has@ztivax.siemens.com
Siemens AG, ZFE F 2 INF 21 or: has%ztivax@siemens.siemens.com
Otto-Hahn-Ring 6, D-8000 Munich 83 Europe: ...!mcvax!unido!ztivax!has
Federal Republic of Germany Germany: has@ztivax.UUCP
phone: (+49) 89 636 45 890 others: "Ask your local Guru" oj@apollo.COM (Ellis Oliver Jones) (04/19/89)
In article <662@ztivax.UUCP> has@ztivax.UUCP (Hans-Albert Schneider) writes: >2) The width and height of the window borders seem to depend on > the screen.... The height of the banner at the top of DM windows is determined by the "std" font available on the node when the DM starts up. The "std" font links on my node are: std "f7x13" portrait nodes (old) std.1280bw "f5x9" hi-res mono std.1280color "f7x13.b" all 1280x1024 color nodes std.19l "f5x9" landscape mono, default std.color "f7x13.b" color nodes (1024x800, 1024x1024) These were chosen to give reasonable readability. We did not change them when the new 68Hz/70Hz F-series monitors (DNxx00F, DN10000VS) came along, even though the new monitors are much more readable than the old ones. You can experiment with changing the banner by changing these links and restarting the DM, but BEWARE: If you get the link wrong the DM won't start. You'll have to fix it by accessing the file system from some other node if this happens. >1) When a window is opened (pad_$create_window) and its upper left > corner is specified to be at or near (0,0), it will be smaller > than specified. The amount of pixels it is smaller seems to > depend on the display type. The dimensions of a pad are the outer dimensions. However, the dimensions of a gpr_$direct bitmap inside that pad will (always) be smaller. The exact amount smaller is a function of the banner font...see above. >3) Is there a way to label a (bordered) window? ... Pads are labelled with the file name. You can specify arbitrary file names, but once the pad's open you can't change the banner label. I often create custom-named pads with code like this (ansi C): pad_$create_window( "GPR Test", 8, pad_$transcript, 1, window, &stream_id, &status); This leaves a cruft file named "GPR Test" in my directory. That doesn't worry me, but it might worry you or the users of your software. Sorry, there's no other way that I know of to control the banner label. >4) My refresh procedure is not called when a refresh is needed, > instead, the window remains blank. (The procedure IS called > by gpr_$acquire, as debug shows.) I was told that it would > be called during an event wait for mouse or keyboard input, > but this is not satisfying. gpr_$event_wait does a release/acquire cycle automatically. If you have a refresh procedure it'll get called during the acquire if necessary. The refresh procedure isn't (and can't be) called asynchronously. Why? (1) There's no asynchronous cross-address-space call mechanism. In other words, when the DM or the X server gets a request to change a window size, or turn an icon into a window for example, it can't "call your refresh procedure" directly. Rather it sets a bit in a data structure for your window indicating that gpr_$acquire_display should call the refresh procedure for you next time you acquire the display. (2) You'd have to have the display acquired for your refresh procedure to work in the first place. So, acquire and release the display, or call gpr_$event_wait, and your refresh procedure will get called. Hope this helps. /oj (Speaking for myself, not necessarily for Apollo Computer, Inc. and definitely not yet for the Hewlett-Packard Company.)