Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!srcsip!tcnet!pwcs!stag!daemon
From: ardvar!krs@stag.UUCP (Kent Schumacher)
Newsgroups: comp.sys.atari.st
Subject: Re: Designing HIs under GEM
Message-ID: <1989Sep5.093159.9328@stag.UUCP>
Date: 5 Sep 89 09:31:59 GMT
Sender: daemon@stag.UUCP (The devil himself)
Organization: Mindtools ST Access Group
Lines: 53

[jg@hpldola.HP.COM (Joe Gilray) writes...]

> Some seem to dislike the idea of nested dialogs, and I concur that they
> can complicate unnecessarily.  The reason I am using them (besides the
> unsubstantiated 255 editable character limit that I mentioned earlier) is
> that for my application, the user will be creating a "header" with an
> unlimited number of "attachments".  The header dialog box will allow the
> user to enter header information, then upon clicking a button the user
> will be offered a box (box 2) to enter a single attachment.  Another click
> and the user can return to the header, exit, or add another attachment
> (in which case s/he will be offered another box 2).  You see, this could
> not be achieved easily with a single box (I have thought of having a single
> box with an "attachment" section, which could be redrawn, but this
> is essentially the same as what I've described above, and uglier I think,
> (what do you think?)). <---- nested parentheses!!!!
> 
> [...stuff deleted...] 
> 
> Thanks for any help
> -Joe Gilray

I recently finished up a contract writing program for a client of mine.

The contract consisted of a header area (i.e. customer name, etc...),
from 0-25 products, and a footer (i.e. totals, notes, etc...).

I think this compares somewhat to your need.  What I did, was to install
the dialog in a window, and hide any unused products.

Put another way, when a new contract is initiated, all that is seen is
the header info in a sizeable (sizeable as in 'able to do sizing') 
window with sliders.

If the user invokes an add product function (via menu, function key,
alt key, or screen button), the program unhides one of the product 
sub-trees, shifts the y-coordinate of the footer down a little, and forces
a redraw of the window area.

Note that this is somewhat harder than simply calling form_do(), but not
prohibitively so, and the code developed for handling dialogs in windows 
is very useful to have around (because it can be made to be as generic as
form_do() is).

In my application, the on screen version of the contract was very similiar
to the printed out version.  This was a big plus in my clients eyes.

                                     +   +
                                       ^
                                       o


  - Kent Schumacher                  /* "A member of STdNET-         */
    ardvar!krs@stag.UUCP             /*  The ST developers network  */