RE: [Pythoncard-users] dictionary return values for dialogs?

It sounds like the right thing to do. Any dissent?

If not, I'll go ahead and convert dialog.py, dialognew.py and all the
samples and their dialogs so all modal dialog results are placed in a
dictionary return value. If I run into any issues I won't check the changes
in until I've brought the issue up on the list. This is probably going to
take a few days because I might need to rethink how the GenericDialog class
works, so if you see a fundamental problem with this approach please speak
up now, before I dive in.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> Patrick K. O'Brien
> Sent: Wednesday, February 13, 2002 2:31 PM
> To: Kevin Altis; pythoncard-Users
> Subject: RE: [Pythoncard-users] dictionary return values for dialogs?
>
>
> Sounds like a good thing to me.
>
> ---
> Patrick K. O'Brien
> Orbtech
>
> > -----Original Message-----
> > From: pyt...@li...
> > [mailto:pyt...@li...]On Behalf Of Kevin
> > Altis
> > Sent: Wednesday, February 13, 2002 3:41 PM
> > To: pythoncard-Users
> > Subject: [Pythoncard-users] dictionary return values for dialogs?
> >
> >
> > I've been thinking about redoing the general dialog interface so
> > that rather
> > than creating a dialog and then getting all of the elements via
> > methods such
> > as:
> >
> >   dlg.accepted()
> >
> > The return value would always be a dictionary with named
> > parameters for all
> > the options {'accepted':1, 'returned':'Ok'}, something like
> that. You can
> > look at the dialogs.py sample to see how method calls are
> > currently used. We
> > can already do dialog one-liners for the simplest dialogs as this shell
> > session shows:
> >
> > >>> from PythonCardPrototype import dialog
> > >>> dialog.AlertDialog(None, 'a message', 'a title')
> >
> > But this isn't possible with more complex dialogs. Using a
> > dictionary return
> > value seems simpler and more Pythonic since the user doesn't have to
> > explicitly call ShowModal or Destroy and regardless of the
> dialog type the
> > result will always be a dictionary of name/value pairs.
> >
> > It may cause issues where previously some dialog setup was done after
> > __init__, but I won't know until I dig a little deeper. The ModalDialog
> > class (dialog.py) in PythonCard already hides ShowModal and Destroy, but
> > still requires the use of methods after the dialog returns to
> get results.
> > GenericDialog (dialognew.py) hides less and would also need to be
> > upgraded.
> >
> > Opinions?
> >
> > ka