------=_NextPart_001_0019_01C303FA.55B5F000
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>  Less ugly fix:
> wxGlade is great for GUI design. Do your GUI magic in another file that =

> imports and uses MyFrame. Then if you need to do GUI reworking, you =
don't=20
> lose your GUI magic. wxGlade is pretty good at taking care of your code =
vs=20
> its code, but I don't trust anyone else not to overwrite my code.
That sounds like a fabulous idea, but I'm scratching my head to a
polished chromedome trying to wrap my peabrain around it. So you would
keep the wxGlade generated code in say, MyGUI.py and the functions the
GUI is supposed to execute in say MyAPP.py? Then instantiate MyFrame=20
in MyAPP.py or somesuch like in your DemoApp class? The events would=20
still go into MyGUI I take it, but where would OnExit() go? If all the
functions go into into MyGUI.py anyway, then what's the point?

I would simply KILL for an example of this scheme. Any ideas? Or maybe I
should wait until I have gleaned through demo.py.

You're pretty much on the money, its just the details:

This is a very ugly example, but it works. I usully put menu stuff in =
with the rest of event functions - it seems to grow very quickly when =
I'm adding features, and seems more relevant there. To my mind it seems =
more of an application detail rather than gui detail, but that may just =
be the way my mind works.

Ugly detail - passing around ID_EXIT. There's a better way, but I =
couldn't come up with it right now (I have an appointment with my 3yo =
daughter to play Barbie's with here - sorry).

Carefull using names like OnExit which get called when exiting for =
functions which you are connecting to events.

temp1.py is the wxGlade generated file.
temp2.py is the application stuff.=20

Have fun,

Chris.




------=_NextPart_001_0019_01C303FA.55B5F000--