🚀 go-pugleaf

In article <ejalbert-3C7D94.05135229102000@nntp.stanford.edu>, Eric
Albert <ejalbert@stanford.edu> wrote:

> In my application, I have an StDialogHandler that opens an LGADialog.  
> That dialog contains a button that, when clicked, creates another 
> StDialogHandler that opens another LGADialog (yes, I know that nested 
> dialogs are a poor UI).  When that second dialog closes, I want the 
> first dialog to close as well, but I can't get that to happen.  I've 
> tried all kinds of things:
> 
> -calling BroadcastMessage(msg_OK, nil);
> -calling mOKButton->SimulateHotSpotClick();
> -calling DoClose();
> -calling ((StDialogHandler *) 
> GetSuperCommander())->ListenToMessage(msg_OK, NULL)
> 
> among others, and not one of them closes that first dialog (OK, DoClose 
> does, but not correctly).  How do I get this code block to work?
> 
> ---
> StDialogHandler handler(kSecondDialogID, this);
> MyDialog *dialog = dynamic_cast<MyDialog *>(handler.GetDialog());
> ThrowIfNil_(dialog);
> 
> MessageT message;
> dialog->Show();
> do {
>    handler.DoDialog();
> } while(message != msg_OK && message != msg_Cancel);
> 
> if (message == msg_OK) {
>    // Close the current dialog as well, but how?
>    ...???...
> }

eric,

it's been a while since i've done this, but wouldn't your code look
something like this:

{
  StDialogHandler outerHandler( whatever... );

  do {
    message = outerHandler.DoDialog();
    if (message == msg_OpenOtherDialog) {
      StDialogHandler innerHandler( whatever... );

      // deal with the inner dialog here...
      message = msg_OK; // or msg_Cancel...whatever...
    }
  } while (message != msg_OK && message != msg_Cancel);
}

you could deal with the inner dialog in an entirely different method
(which is what i would do) but still set the "message" variable for the
outer dialog, after having dealt with the inner dialog, such that you
exit your while loop cleanly.

is that what you're looking for? HTH...

-joey

In article <291020001117102847%mjg@mac.com>, Joey Gray <mjg@mac.com> 
wrote:

> In article <ejalbert-3C7D94.05135229102000@nntp.stanford.edu>, Eric
> Albert <ejalbert@stanford.edu> wrote:
> 
> > In my application, I have an StDialogHandler that opens an LGADialog.  
> > That dialog contains a button that, when clicked, creates another 
> > StDialogHandler that opens another LGADialog (yes, I know that nested 
> > dialogs are a poor UI).  When that second dialog closes, I want the 
> > first dialog to close as well, but I can't get that to happen.  I've 
> > tried all kinds of things:
> > 
> > -calling BroadcastMessage(msg_OK, nil);
> > -calling mOKButton->SimulateHotSpotClick();
> > -calling DoClose();
> > -calling ((StDialogHandler *) 
> > GetSuperCommander())->ListenToMessage(msg_OK, NULL)
> > 
> > among others, and not one of them closes that first dialog (OK, DoClose 
> > does, but not correctly).  How do I get this code block to work?
> > 
> > ---
> > StDialogHandler handler(kSecondDialogID, this);
> > MyDialog *dialog = dynamic_cast<MyDialog *>(handler.GetDialog());
> > ThrowIfNil_(dialog);
> > 
> > MessageT message;
> > dialog->Show();
> > do {
> >    handler.DoDialog();
> > } while(message != msg_OK && message != msg_Cancel);
> > 
> > if (message == msg_OK) {
> >    // Close the current dialog as well, but how?
> >    ...???...
> > }
> 
> it's been a while since i've done this, but wouldn't your code look
> something like this:
> 
> {
>   StDialogHandler outerHandler( whatever... );
> 
>   do {
>     message = outerHandler.DoDialog();
>     if (message == msg_OpenOtherDialog) {
>       StDialogHandler innerHandler( whatever... );
> 
>       // deal with the inner dialog here...
>       message = msg_OK; // or msg_Cancel...whatever...
>     }
>   } while (message != msg_OK && message != msg_Cancel);
> }
> 
> you could deal with the inner dialog in an entirely different method
> (which is what i would do) but still set the "message" variable for the
> outer dialog, after having dealt with the inner dialog, such that you
> exit your while loop cleanly.

That's not all that ideal, because it requires the class that includes 
the StDialogHandler for the first dialog to know about the second, and 
I'd rather not do that -- it makes that part of the code a good bit 
harder to maintain.  It would work, but I'm hoping there's a better 
solution.

-Eric

-- 
Eric Albert         ejalbert@stanford.edu
http://www.stanford.edu/~ejalbert/

In article <ejalbert-AE5652.14240329102000@nntp.stanford.edu>, Eric
Albert <ejalbert@stanford.edu> wrote:

> In article <291020001117102847%mjg@mac.com>, Joey Gray <mjg@mac.com> 
> wrote:
> 
> > it's been a while since i've done this, but wouldn't your code look
> > something like this:
> > 
> > {
> >   StDialogHandler outerHandler( whatever... );
> > 
> >   do {
> >     message = outerHandler.DoDialog();
> >     if (message == msg_OpenOtherDialog) {
> >       StDialogHandler innerHandler( whatever... );
> > 
> >       // deal with the inner dialog here...
> >       message = msg_OK; // or msg_Cancel...whatever...
> >     }
> >   } while (message != msg_OK && message != msg_Cancel);
> > }
> > 
> > you could deal with the inner dialog in an entirely different method
> > (which is what i would do) but still set the "message" variable for the
> > outer dialog, after having dealt with the inner dialog, such that you
> > exit your while loop cleanly.
> 
> That's not all that ideal, because it requires the class that includes 
> the StDialogHandler for the first dialog to know about the second, and 
> I'd rather not do that -- it makes that part of the code a good bit 
> harder to maintain.  It would work, but I'm hoping there's a better 
> solution.

okay, so your objection is that the first dialog handler must know
about the second dialog. doesn't it have to? how else do you open the
second dialog from within the first dialog?

obviously there's more to the code than in the example that i
presented, but the general idea is there. in the outer dialog, when you
click on the button which is supposed to trigger the open of the inner
dialog you call the method(s) which deal with the inner dialog. don't
you have to do at least something like that in your current code?

perhaps something like this:

void COuterDialog::DoDialog( ... )
{
  StDialogHandler outerHandler( ... );

  do {
    message = outerHandler.DoDialog();
    if (message == msg_OpenOtherDialog) {
      CInnerDialog::DoDialog( ... );
      message = msg_OK; // or msg_Cancel
    }
  } while (message != msg_OK && message != msg_Cancel);
}

void CInnerDialog::DoDialog( ... )
{
  StDialogHandler innerHandler( ... );

  do {
    message = innerHandler.DoDialog();
    // ...
  } while (message != msg_OK && message != msg_Cancel);
}

perhaps you can have the inner dialog handler return some kind of
indicator as to how to deal with the outer dialog.

how does the code you have now pass control from the outer dialog to
the inner dialog?

-joey

in article 311020001930265668%mjg@mac.com, Joey Gray at mjg@mac.com wrote on
10/31/00 5:30 PM:

> okay, so your objection is that the first dialog handler must know
> about the second dialog. doesn't it have to? how else do you open the
> second dialog from within the first dialog?

<SNIP>

> perhaps you can have the inner dialog handler return some kind of
> indicator as to how to deal with the outer dialog.

I was thinking the same thing. Perhaps a generic inner/outer Dialog base
classes could be created which would have an additional message that
indicates that the outer wants the inner closed. Then you can create
concrete versions.