🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.atari.st
Article #38724

Re: That little black line

#38724
From: Rainer Klute
Date: Thu, 11 May 1989 06:20
111 lines
4872 bytes
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
Technical Details
Message-ID: <1355@laura.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!texsun!pitstop!sundc!seismo!uunet!mcvax!unido!laura!trillian.irb!klute
References: <809@stag.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!texsun!pitstop!sundc!seismo!uunet!mcvax!unido!laura!trillian.irb!klute
From: klute%trillian.irb@unido.uucp (Rainer Klute)
Newsgroups: comp.sys.atari.st
Subject: Re: That little black line
Message-ID: <1355@laura.UUCP>
Date: 11 May 89 06:20:36 GMT
References: <809@stag.UUCP>
Sender: root@laura.UUCP
Reply-To: klute@trillian.irb.informatik.uni-dortmund.de (Rainer Klute)
Organization: University of Dortmund, W-Germany
Lines: 111
Work-Address: Postfach 500500, D-4600 Dortmund 50, Tel. +49 231 755-4663
Home-Address: Vinckeplatz 5,   D-4600 Dortmund 1,  Tel. +49 231 128414