[Pythoncard-users] dialog and window issues

[Kevin A. <al...@se...>]

Many of these thoughts aren't fully formed, but here goes...

1. Non-modal dialogs versus regular windows
I'm not sure what big differences there are between a non-modal dialog and a
regular window in an app from the standpoint of PythonCard. The Background
class in PythonCard already uses a wxPanel so tab traversal is handled
automatically and it is simple enough to support a default button, which I'm
already doing for the modal dialogs.

I'm inclined to create a variation on the Background class like I did for
the GenericDialog class and that will give us a generic window class that
can contain widgets. The difference will be that the windows will all be
children of the background they are created from and they won't appear
automatically when the app starts up, only in response to an invocation from
user code. Once we have some transparent data storage mechanism, they
probably won't inherit that capability either, though I could see reasons
for wanting to do that.

A better idea might be to add support for multiple backgrounds first, then
the non-modal and generic windows can simply be separate backgrounds and
we'll support multiple background windows as part of the basic UI. At some
point, Background, GenericDialog, and the other window-related classes will
need to be refactored, so the implementation is cleaner, but we're at the
prototype stage, so that's to be expected.

2. Dialog resource and source code organization
Where should the resource descriptions and classes for dialogs be stored? In
my current example, I'm storing the Find dialog resource in a separate file
'find.rsrc.py'. The FindDialog class is part of the main sample module just
like the Background subclass for the main app. There are a few alternative
possibilities.
A. Store all dialogs for an app in the main .rsrc.py file for the app. The
classes for the dialogs would be stored in the main app module.
B. Store the dialog resources in a separate dialog.rsrc.py for each app. The
classes for the dialogs would go into their own module which the main module
would import.
C. Store each dialog in its own file, possibly storing the class that goes
with the resource in the same file. Otherwise, store the code in its own
file as well.

There are probably some other variations with merit. The last option
probably appeals to me the most, where each dialog would have two files. For
example, the find code I posted earlier might have find.dialog.py and
find.dialog.rsrc.py. I think this might foster code reuse among apps the
most, particularly if we have a dialogs folder as part of the distribution
that is available to apps at runtime. The find dialog example would go into
that 'dialogs' folder. Other common dialogs would be added over time.

3. Validators
Modal modal dialogs often have an associated validator. If the user needs to
enter a particular value to dismiss the dialog then that can be done in the
default or cancel button handler. For example, if you wanted the user to
enter some text in order to do a Find, you might use:

    def on_btnFindNext_mouseClick(self, target, event):
        txt = self.components.fldFind.text
        # this test could be a separate validate method
        if not txt == ''
            event.skip()
        else:
           # present an error dialog or other message here
           ...

4. Editing dialog resources
The resourceEditor sample will not be able to create or edit the dialog
descriptions until the code is updated. In the meantime, a workaround will
be to edit a normal background and copy the components list to place into a
dialog description. I don't want to change the resourceEditor until we
decide on the storage format and organization for dialogs.

Please comment and add your own thoughts.

ka