rcb@netcom.COM (Roy Bixler) (04/24/91)
I am writing a GEM application based on a dialog box which occasionally has another dialog box written over it. When this 'pop-up' dialog box is done and I have called form_dial() the second time, instead of the original dialog box being restored, the desktop background is restored. Obviously, that doesn't 'cut it'. Is there a way for me to save the background and restore it when I'm done with the 'pop-up' dialog? It looks like the problem is that GEM is not aware that my original dialog box is the background. How do I notify GEM that the background is not the original desktop? I've thought about doing a 'wind_set(0, WF_NEWDESK, ...)' but, if I do that, how would I get the original desktop back when my application is done? Maybe insanity is the best answer. Any suggestions otherwise? -- Roy Bixler rcb@netcom.com -or- (UUCP) uunet!apple!netcom!rcb "Just when you think you know it all, it changes!"
marc@sequoia.cray.com (Marc Bouron) (04/25/91)
In article <1991Apr24.012040.22627@netcom.COM>, rcb@netcom.COM (Roy Bixler) writes: |> |> I am writing a GEM application based on a dialog box which |> occasionally has another dialog box written over it. When this |> 'pop-up' dialog box is done and I have called form_dial() the second |> time, instead of the original dialog box being restored, the desktop |> background is restored. Obviously, that doesn't 'cut it'. Is there a |> way for me to save the background and restore it when I'm done with |> the 'pop-up' dialog? |> |> It looks like the problem is that GEM is not aware that my original |> dialog box is the background. How do I notify GEM that the background |> is not the original desktop? I've thought about doing a 'wind_set(0, |> WF_NEWDESK, ...)' but, if I do that, how would I get the original |> desktop back when my application is done? |> |> Maybe insanity is the best answer. Any suggestions otherwise? You should write your application so that it uses AES - i.e. use evnt_mesag() or envt_multi() calls. This way, when you free up a patch of screen where your dialog used to be with the form_dial() call, the AES will send you a message to tell you what area of the screen needs redrawing. (It's up to you to do the redrawing - if your dialog is an object tree, this is no problem.) If all this is news to you, then I would suggest Tim Oren's ProGEM series of articles as a damn decent way to teach you about these things. Certainly an improvement on my ramblings... [M][a][r][c] ################################################################################ # # marc@sequoia.cray.com # . . # # Marc CR Bouron # M.Bouron@cray.co.uk (ARPA) # _|\ /|_ # # Cray Research (UK) Ltd. # M.Bouron@crayuk.uucp (DOMAIN) # (_|_V_|_) # # +44 344 485971 x2208 # M.Bouron@uk.co.cray (JANET) # | | # # # ...!ukc!crayuk!M.Bouron (UUCP) # # ################################################################################
bittrolff@evans.enet.dec.com (Steve Bittrolff) (04/25/91)
In article <115241.1926@timbuk.cray.com>, marc@sequoia.cray.com (Marc Bouron) writes... > >In article <1991Apr24.012040.22627@netcom.COM>, rcb@netcom.COM (Roy Bixler) writes: >|> >|> I am writing a GEM application based on a dialog box which >|> occasionally has another dialog box written over it. When this >|> 'pop-up' dialog box is done and I have called form_dial() the second >|> time, instead of the original dialog box being restored, the desktop >|> background is restored. Obviously, that doesn't 'cut it'. Is there a >|> way for me to save the background and restore it when I'm done with >|> the 'pop-up' dialog? >|> >|> It looks like the problem is that GEM is not aware that my original >|> dialog box is the background. How do I notify GEM that the background >|> is not the original desktop? I've thought about doing a 'wind_set(0, >|> WF_NEWDESK, ...)' but, if I do that, how would I get the original >|> desktop back when my application is done? >|> >|> Maybe insanity is the best answer. Any suggestions otherwise? There are a couple of other ways to handle this. One that I use is to save the screen area under the dialog box when you put it up and restore it when you put it back, using the blit routines. Specifically, you can use the vro_copyfm() routines. Or you can save each dialog box using the same technique and restore all of it when you get a redraw message. Or you can save the whole screen, although this uses 32K of memory. As far is insanity, I came pretty close when I was first trying to implement this stuff! :^) ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ Steve Bittrolff | KlugeMaster bittrolff@pikes.enet.dec.com or | bittrolff@evans.enet.dec.com | | ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
warwick@cs.uq.oz.au (Warwick Allison) (04/25/91)
[ re multiple dialog boxes ] >There are a couple of other ways to handle this. One that I use is to save the >screen area under the dialog box when you put it up and restore it when you >put it back, using the blit routines. Specifically, you can use the >vro_copyfm() routines. Or you can save each dialog box using the same technique >and restore all of it when you get a redraw message. Or you can save the whole >screen, although this uses 32K of memory. The trouble with this is, you only get 1 level of nesting (or another 32K every time you open another dialog on top of an old one!). A far better, and easier method is to just redraw the form AFTER the nested form is complete. Just use objc_draw for this purpose. I do recommend you read Tim Oren's ProGEM series - they are at atari.archive. You asked about setting your own desktop object, here's how: First, to set an object as the new desktop: (note, this is hacked from Modula-2, so beware) NewDesk=14 rsrc_gaddr(tree,FormNumber,&Form); wind_set(0,NewDesk,Form,0); To go back to the original desktop: wind_set(0,NewDesk,0,0); Warwick. -- _-_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.-._/ University of Queensland, v Brisbane, AUSTRALIA.
rcb@netcom.COM (Roy Bixler) (04/26/91)
warwick@cs.uq.oz.au writes: >You asked about setting your own desktop object, here's how: > >First, to set an object as the new desktop: >(note, this is hacked from Modula-2, so beware) > >NewDesk=14 >rsrc_gaddr(tree,FormNumber,&Form); >wind_set(0,NewDesk,Form,0); > >To go back to the original desktop: > >wind_set(0,NewDesk,0,0); I tried this and it worked fine. I will do this, but as an alternative, I could go back to what I was doing before (redrawing my original object when the dialog is finished). It's just a lot nicer to have system support, instead of having to program everything yourself. > > >Warwick. >-- > _-_|\ warwick@cs.uq.oz.au > / * <-- Computer Science Department, > \_.-._/ University of Queensland, > v Brisbane, AUSTRALIA. Thanks very much! -- Roy Bixler rcb@netcom.com -or- (UUCP) uunet!apple!netcom!rcb "Just when you think you know it all, it changes!"
bittrolff@evans.enet.dec.com (Steve Bittrolff) (04/26/91)
>The trouble with this is, you only get 1 level of nesting (or another 32K >every time you open another dialog on top of an old one!). > >A far better, and easier method is to just redraw the form AFTER the nested >form is complete. Just use objc_draw for this purpose. I couldn't use the objc_draw because I had some background graphics (directly into the window) that were being written on top of, with no easy way to recreate. ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ Steve Bittrolff | KlugeMaster bittrolff@pikes.enet.dec.com or | bittrolff@evans.enet.dec.com | | ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
marc@sequoia.cray.com (Marc Bouron) (04/26/91)
In article <3012@shodha.enet.dec.com>, bittrolff@evans.enet.dec.com (Steve Bittrolff) writes: |> |> >The trouble with this is, you only get 1 level of nesting (or another 32K |> >every time you open another dialog on top of an old one!). |> > |> >A far better, and easier method is to just redraw the form AFTER the nested |> >form is complete. Just use objc_draw for this purpose. |> |> I couldn't use the objc_draw because I had some background graphics (directly |> into the window) that were being written on top of, with no easy way to |> recreate. If you're drawing `custom' objects in your dialog box that can't be managed with the given set of boxes, buttons, etc, you should consider using a G_PROGDEF object: the ob_spec should then point at a data structure (can't remember the name) which contains the address of a routine to do the custom drawing, and a longword parameter. This way you can still use objc_draw(), which will automatically use your code to draw your custom object. Again, I would recommend Tim Oren's ProGEM for a better explanation of this. [M][a][r][c] ################################################################################ # # marc@sequoia.cray.com # . . # # Marc CR Bouron # M.Bouron@cray.co.uk (ARPA) # _|\ /|_ # # Cray Research (UK) Ltd. # M.Bouron@crayuk.uucp (DOMAIN) # (_|_V_|_) # # +44 344 485971 x2208 # M.Bouron@uk.co.cray (JANET) # | | # # # ...!ukc!crayuk!M.Bouron (UUCP) # # ################################################################################
bittrolff@evans.enet.dec.com (Steve Bittrolff) (04/27/91)
>If you're drawing `custom' objects in your dialog box that can't be managed >with the given set of boxes, buttons, etc, you should consider using a >G_PROGDEF object: the ob_spec should then point at a data structure (can't >remember the name) which contains the address of a routine to do the custom >drawing, and a longword parameter. This way you can still use objc_draw(), >which will automatically use your code to draw your custom object. Again, I >would recommend Tim Oren's ProGEM for a better explanation of this. My custom objects were on the background window, not the dialog box. I haven't used the PROGDEF pointer before, however. Does it point to executable code or just some sort of bitmap? (It would be kind of nifty if it pointed to an executable routine). I'll also check out ProGEM. I know you posted a pointer to it, and I lost it, where can I find it? Thanks ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ Steve Bittrolff | KlugeMaster bittrolff@pikes.enet.dec.com or | bittrolff@evans.enet.dec.com | | ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
bjoern@drdhh.hanse.de (Bjoern Kriews) (04/29/91)
From article <115241.1926@timbuk.cray.com>, by marc@sequoia.cray.com (Marc Bouron): > |> I am writing a GEM application based on a dialog box which > |> occasionally has another dialog box written over it. When this > |> 'pop-up' dialog box is done and I have called form_dial() the second > |> time, instead of the original dialog box being restored, the desktop > |> background is restored. Obviously, that doesn't 'cut it'. Is there a > |> way for me to save the background and restore it when I'm done with > |> the 'pop-up' dialog? GEM's form_dial is just a way to tell the screen manager that it has to force the application to redraw it's screen. Since dialogs are not windows, you have to use code like this: form_center(dial1,...); form_center(popup,...); redraw=TRUE; form_dial(FMD_START,dial1....); do{ if(redraw) { objc_draw(dial1,....); redraw=FALSE; } ex=form_do(dial1...) & 0x7fff; switch(ex) { case CALLPOP: form_dial(FMD_START,popup...); /* not needed if popup is < dial */ objc_draw(popup,....); form_do(popup,....); form_dial(FMD_FINISH,popup....); /* "" */ redraw=TRUE; break; case ANYTHING: form_alert(1,"[0][What you want][XXX]"); break; } } while(ex != EXDIAL1); form_dial(FMD_FINISH,dial1....); I hacked this from memory because my sources are on backup for the moment, but that's the way my applications handle it. Notes: Alerts restore there bg automatically. I discovered that form_dial(START/FINISH) may be used out of specific order but I never found this being official, be aware. Hope that helps, Bjoern --- bjoern@drdhh.hanse.de = Bjoern Kriews / Stormsweg 6 / 2000 Hamburg 76 / FRG "gaaga mahwe Bjoern urgl ufzae Turbo-C bnub" (J. Willamowius)