You can put panels of widgets into HTML very nicely with wxPython.
The version of HTML that the wxHtmlCtrl supports is pretty simple,
but it includes a hook for extending it, the WXP tag. This looks
something like this embedded in your html:
<wxp module = "somemodule " class="SomeClas s" width="95%">
<param name="id" value="-1"> </wxp>
Although the demo that comes with wxPython does something simple
like embedding a button, I just about always derive SomeClass from
wxPanel, and I use sizers to control the layout of several
controls within the panel. The constructor will start like this:
class SomeClass(wxPan el):
def __init__(self, parent, id=-1, size=wxDefaultS ize)
wxPanel.__init_ _(self, parent, id, size=size)
IDK how to pass in object references as constructor parameters in the
embedded HTML, so these panels seem to often wind up using globals to
communicate with the rest of the program.
Keep in mind that the constructor for this panel is not called until
the HTML actually gets put into the wxHtmlCtrl (by SetPage, etc).
The panel also gets automatically destroyed when the next contents get
put into the wxHtmlCtrl, so don't hang on to any references to it.
IDK if PythonCard supports this control or not. Haven't used
pythoncard.
I alsways use wxCallAfter to send the next page to the wxHtmlCtrl.
That way I don't have to worry about a panel destroying itself while
its still running by changing the screen contents. wxCallAfter waits
until the current UI event is completely processed before doing
whatever it does.
This all leads to a pretty convenient style of programming. I throw
something at the screen, the user clicks something, maybe this makes
me throw something else at the screen, maybe it doesn't. If not,
he's still got the same screen to try something else. You don't
have to work out a hierarchy of screens where the user is forever
drilling down and popping up -- they can have more browser-like
freedom. Makes their heads spin. Keep a copy of the HTML and give
them a back button.
Al
