RE: [Pythoncard-users] moving menubar and getting rid of stack?

> From: Rowland Smith
>
> Kevin Altis wrote:
>
> >>From: Andy Todd
> >>
> <snip>
> >>The separation of the window from the background is quite a powerful
> >>'feature'. One of the neat things you can do in Oracle forms is
> >>dynamically/programatically swap the canvases (backgrounds in our
> >>terminology) within a window. This allows some pretty fancy layout - but
> >>then again may be too complicated for our kind of applications. Its a
> >>feature that I have used in the past, but I don't have a sample
> >>application in mind which would need it - yet.
> >>
> >
> > Yes, this is a bit more like HyperCard. This still feels like
> an app that
> > should be built on top of the framework and not the framework
> itself. What
> > do other people think?
>
>
> Setting a Form on a Window ( myWindow.setForm( f ) ) is a reasonable
> responsibility for a Window to fullfill.  This would allow the user to
> build their own navigation system for viewing different Forms in the
> same window.
>
> A higher level class like MultiFormWindow could be constructed with a
> list of Forms, and provide navigation between the forms in the list.
> This is like HyperCard where each Card has a different background and
> allows the creation of multi-media style apps.

To be more precise, each Card in HyperCard has an associated Background.
Stacks contain Backgrounds. It was quite common to have a Stack with a
single Background that contained many cards. One of the things which made
HyperCard Cards different from say individual records in a table in a normal
database is that each Card could also have its own script, buttons, fields,
and graphics. In object terms, each Card (instance) could have its own
attributes in addition to the Background (class) attributes; Python's object
model certainly supports that, but it can be confusing. If a stack uses that
capability it makes it much more difficult to translate to a different
environment.

This gets back to the confusion between GUI widgets bound to an underlying
document model and those that aren't. PythonCard doesn't provide any
inherent binding yet, though some of the samples like addresses, textIndexer
hint at what we might do.

Of course, many times the additional backgrounds and cards in a stack took
the place of what would normally be placed in a separate window or dialog in
a "normal" application.

Anyway, the framework we have today requires a Background (wxFrame) to
always contain a Panel (wxPanel). It is simple to hide the current panel and
show another one or remove the panel and insert another one. The problem is
that we are putting the event handlers in the Background instead of the
Panel. A change to an application/window/form or panel organization means
that handlers should be bound to the panel or at least the event binding
should be more flexible.

ka