to_stdnet@stag.UUCP (05/07/89)
From: stag!thelake!steve@bungia.mn.org (Steve Yelvington)
I have a minor visual neatnss problem in the application I'm working on (a
point-and-click shell for a group of .TTP programs).
When the Desktop launches a .PRG application, it draws a little black line
between the menu bar region of the screen and the working region. The line
does not appear to "belong" to either the desk workspace or the menu bar,
for reasons that become apparent below:
When my GEM shell execs a .TTP program, I erase the menu bar, clear the
screen and home the vt52 cursor so that the .TTP program can write
anywhere it wants.
When it returns, I want to put things back the way they were. I restore
the menu bar, then clean up the desk area by drawing a solid green G_BOX
object clipped to the size of the Desktop's work window, like so:
#define DESKTOP 0
int x,y,w,h;
/* first, we get the dimensions of the full GEM Desktop */
wind_get(DESKTOP, WF_FULLXYWH, &x, &y, &w, &h);
/* then we draw our own desk surface, clipping appropriately */
objc_draw(mydesk, ROOT, 0, x,y,w,h);
Everything looks fine except that I've lost that little black line between
the menu bar and the big green playing field. This looks messy, and it
looks even messier when I point into the menu bar, because the AES redraws
the portions of the missing bar that are disturbed by the drop-down menus.
(My program is not the only one in which I have seen this phenomenon.)
Is there a way to redraw that little black line without getting into the
VDI?
Another question:
I don't have a monochrome monitor, so I don't know the effect of using a
solid (value of 7) GREEN to redraw the desk area. I've read that GEM maps
all nonwhite values to black. Since the monochrome GEM Desktop is
halftoned, I have to assume that either (a) GEM does not really map all
nonwhite values to black, or (b) the Desktop checks to see if it's using a
monochrome monitor, and if so, adjusts its background to a halftone.
Which is it?
/*
* UUCP: {uunet!rosevax,amdahl!bungia,chinet,killer}!orbit!thelake!steve
* ARPA: crash!orbit!thelake!steve@nosc.mil
* #member <STdNET> The ST Developers Network
*/bob@cmpfen.UUCP (Bob Breum) (05/09/89)
In article <809@stag.UUCP> to_stdnet@stag.UUCP writes: >From: stag!thelake!steve@bungia.mn.org (Steve Yelvington) >Another question: >I don't have a monochrome monitor, so I don't know the effect of using a >solid (value of 7) GREEN to redraw the desk area. I've read that GEM maps >all nonwhite values to black. Since the monochrome GEM Desktop is >halftoned, I have to assume that either (a) GEM does not really map all >nonwhite values to black, or (b) the Desktop checks to see if it's using a >monochrome monitor, and if so, adjusts its background to a halftone. When the GEM Desktop redraws the desktop background, it performs a fill rectangle to do so. When a monochrome monitor is attached, it uses a 50% fill pattern for this operation. Interestingly, the original RAM-loaded TOS also used a 50% fill with color systems, yielding a pleasant light green background; unfortunately, when Atari released the TOS ROMs, they altered this to a solid green fill color systems, which seems to please no one. -- Computer Fenestrations Bob Breum Post Office Box 151 {uiucuxc|hoptoad|petsd|ucf-cs}!peora!cmpfen!bob Lake Monroe, FL 32747 USA +1 407 322-3222 "C is the new BASIC"
klute%trillian.irb@unido.uucp (Rainer Klute) (05/11/89)
In article <809@stag.UUCP> to_stdnet@stag.UUCP writes: >I have a minor visual neatnss problem in the application I'm working on (a >point-and-click shell for a group of .TTP programs). > >When the Desktop launches a .PRG application, it draws a little black line >between the menu bar region of the screen and the working region. The line >does not appear to "belong" to either the desk workspace or the menu bar, >for reasons that become apparent below: > >When my GEM shell execs a .TTP program, I erase the menu bar, clear the >screen and home the vt52 cursor so that the .TTP program can write >anywhere it wants. > >When it returns, I want to put things back the way they were. I restore >the menu bar, then clean up the desk area by drawing a solid green G_BOX >object clipped to the size of the Desktop's work window, like so: > > #define DESKTOP 0 > > int x,y,w,h; > /* first, we get the dimensions of the full GEM Desktop */ > wind_get(DESKTOP, WF_FULLXYWH, &x, &y, &w, &h); > /* then we draw our own desk surface, clipping appropriately */ > objc_draw(mydesk, ROOT, 0, x,y,w,h); > >Everything looks fine except that I've lost that little black line between >the menu bar and the big green playing field. This looks messy, and it >looks even messier when I point into the menu bar, because the AES redraws >the portions of the missing bar that are disturbed by the drop-down menus. >(My program is not the only one in which I have seen this phenomenon.) > >Is there a way to redraw that little black line without getting into the >VDI? > >Another question: > >I don't have a monochrome monitor, so I don't know the effect of using a >solid (value of 7) GREEN to redraw the desk area. I've read that GEM maps >all nonwhite values to black. Since the monochrome GEM Desktop is >halftoned, I have to assume that either (a) GEM does not really map all >nonwhite values to black, or (b) the Desktop checks to see if it's using a >monochrome monitor, and if so, adjusts its background to a halftone. > >Which is it? You should do this in a quite different way! There is no need to explicitly draw your program's desktop. Let GEM do that for you! Here is a piece of code (from my ARCGSH) stripped down to the significant points to show you and everybody else interested how this can be achived: /* Disable the menu bar: */ rsrc_gaddr (R_TREE, MENU, &menu); menu_bar (menu, 0); if (tos_program) /* extension TOS or TTP */ { handle = graf_handle (&dummy, &dummy, &dummy, &dummy); vq_extnd (handle, 0, work_out); /* Here comes the main point (part 1): form_dial (FMD_START, ...) tells GEM that the whole screen (except the menu bar, to be exact) is to be reserved for the application. */ form_dial (FMD_START, 0, 0, width, height, 0, 0, width, height); /* Prepare screen for alphanumeric output: */ v_hide_c (handle); v_enter_cur (handle); v_curhome (handle); v_eeos (handle); }; /* Pexec program */ v_hide_c (handle); v_show_c (handle, 0); if (tos_program) { v_exit_cur (handle); /* This is part 2 of the main point: form_dial (FMD_FINISH, ...) tells GEM that the specified area is no longer reserved. GEM now draws the normal desktop background color/pattern in that area. Don't worry about color or monochrome monitor! GEM also sends redraw messages to applications with windows in that area so that they have a chance to redraw them properly. */ form_dial (FMD_FINISH, 0, 0, width, height, 0, 0, width, height); }; /* Finally the menu bar is restored: */ menu_bar (menu, 1); Rainer Klute ---- klute@trillian.irb.informatik.uni-dortmund.de Univ. Dortmund, IRB |)|/ klute@unido.uucp, klute@unido.bitnet Postfach 500500 |\|\ ...uunet!mcvax!unido!klute D-4600 Dortmund 50 ---- Tel.: +49 231 7554663
rosenkra@hall.cray.com (Bill Rosenkranz) (05/13/89)
--- on a related note, i just found some odd behavior with AES. my application does not use a menu bar, at least not all the time. the main screen has an item which the user can click on. it is very near the top (i.e. top 20 pixels in hi res) so it would normally be in the menu area. i have a provision to allow users to get at the desk accessories in whihc case i do the normal menu_bar (tree, 1); etc. all works fine. after the user is done mucking about, i do menu_bar (tree, 0); and redraw the normal screen. the trouble is that now i can't detect button events near the top of the screen (well, i can if i start with the button down below the invisible menu_bar and drag into the object). i have tried editing the resource and changing the size of the menu bar itself, but it seems like AES is tracking mouse position rather than mouse position IN THE MENU BAR which is what it SHOULD do. is there a solution here? would a call to form_dial fix things up? thanx... -bill rosenkranz rosenkra%boston@hall.cray.com