Events and sequential scenarios

Hello,
I am still struggling with the fundamentals of event driven programming.

As long as I am working with one window/widget, everything goes
reasonably well: events happen to its buttons and text fields,
and I can use Bind() to give them a follow up.

However, my main frame + main application is a menu system,
in which the menu items start a kind of sub-things
(applications + frames), and in which the only common trait
of these subs is that they use the same database.

And what makes it really difficult for me:
many of these sub-applications start as scenario’s, use cases,
which are essentially sequential constructions, maybe altered by
some control flow.

I tried to implement each scenario in a class in which a main method
sequentially executes a number of other low-level methods.
Some of these methods do contain wxPython elements,
Other methods don’t use wxPython, beause they do their business or
database work transparently in the background.
And they don’t generate events.

Obviously this doesn’t work well in an event driven environment.
But I dont see yet how I can mix events and my sequential wishes,
or how I can convert all of it to events.
egbert

···


Egbert Bouwman [GMail]

Hello,

  > I am still struggling with the fundamentals of event driven

programming.

  >

  > As long as I am working with one window/widget, everything

goes

  > reasonably well: events happen to its buttons and text

fields,

  > and I can use Bind() to give them a follow up.

  >

  > However, my main frame + main application is a menu system,

  > in which the menu items start a kind of sub-things

  > (applications + frames), and in which the only common trait

  > of these subs is that they use the same database.

  >

  > And what makes it really difficult for me:

  > many of these sub-applications start as scenario's, use

cases,

  > which are essentially sequential constructions, maybe

altered by

  > some control flow.

  >

  > I tried to implement each scenario in a class in which a

main method

  > sequentially executes a number of other low-level methods.

  > Some of these methods do contain wxPython elements,

  > Other methods don't use wxPython, beause they do their

business or

  > database work transparently in the background.

  > And they don't generate events.

  >

  > Obviously this doesn't work well in an event driven

environment.

  > But I dont see yet how I can mix events and my sequential

wishes,

  > or how I can convert all of it to events.

  > egbert

  >

  >

  > --

  > Egbert Bouwman [GMail]

  > --

  > To unsubscribe, send email to

  > > or visit

Pass events to trigger the sequence(s), pass back events to

trigger
display updates, etc., see wx.lib.newevent.NewEvent()
documentation
and the example in documents and demo’s for threads - You can also
use
callbacks to pass triggers/results or you can use streams or
semaphore
files to do the same sort of thing, (with timers to check your
semaphore files.

Gadget/Steve
···

wxPython-users+unsubscribe@googlegroups.com
http://groups.google.com/group/wxPython-users?hl=en

Anything that takes a “long time” will need to be done in a separate thread. You can use your menu event handler to create a new thread and use wx.CallAfter to tell wxPython to update. See the following for some examples:

http://www.blog.pythonlibrary.org/2010/05/22/wxpython-and-threads/

http://wiki.wxpython.org/LongRunningTasks

A lot of people recommend the Dabo framework when working with databases from wx. I haven’t used it, but you’re welcome to take a look: http://dabodev.com/

HTH

···

On Thu, Feb 10, 2011 at 12:11 PM, Egbert Bouwman egbert.bouwman@gmail.com wrote:

Hello,
I am still struggling with the fundamentals of event driven programming.

As long as I am working with one window/widget, everything goes
reasonably well: events happen to its buttons and text fields,

and I can use Bind() to give them a follow up.

However, my main frame + main application is a menu system,
in which the menu items start a kind of sub-things
(applications + frames), and in which the only common trait

of these subs is that they use the same database.

And what makes it really difficult for me:
many of these sub-applications start as scenario’s, use cases,
which are essentially sequential constructions, maybe altered by

some control flow.

I tried to implement each scenario in a class in which a main method
sequentially executes a number of other low-level methods.
Some of these methods do contain wxPython elements,
Other methods don’t use wxPython, beause they do their business or

database work transparently in the background.
And they don’t generate events.

Obviously this doesn’t work well in an event driven environment.
But I dont see yet how I can mix events and my sequential wishes,

or how I can convert all of it to events.
egbert


Egbert Bouwman [GMail]

To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com

or visit http://groups.google.com/group/wxPython-users?hl=en

Mike Driscoll

Blog: http://blog.pythonlibrary.org

... or broken down into bite-sized chunks to be done when the GUI is
otherwise idle. This technique works surprising well for a lot of
problems. You can do this, for example, by checking to see if work is
to be done and using CallAfter to put that chunk of work at the end of
the event queue. Animation is a perfect example that doesn't require
threads: render one scene then return to the event loop. Lather,
rinse, repeat.

One key to effective event based programming is to remember that the
event loop is just that: a loop, no different than any other loop.
Calling MainLoop is not much different than adding this to your code:

    while <we haven't been told to exit>:
      <get next event>
      <process next event>

The right solution really depends on what you're trying to do, of
course. Some long running procedures can't be easily broken up into
small chunks, in which case threads (or arguably even better, separate
processes) can be used.

Bottom line, though, is not to think of the event loop as anything
mysterious or magical. It's just a loop.

···

On Thu, Feb 10, 2011 at 1:49 PM, Mike Driscoll <mike@pythonlibrary.org> wrote:

Anything that takes a "long time" will need to be done in a separate thread.

That's a pretty good point. I'm not sure if it will work with a
lengthy SQL call, but I liked your example.

···

On Feb 10, 2:52 pm, Bryan Oakley <bryan.oak...@gmail.com> wrote:

On Thu, Feb 10, 2011 at 1:49 PM, Mike Driscoll <m...@pythonlibrary.org> wrote:
> Anything that takes a "long time" will need to be done in a separate thread.

... or broken down into bite-sized chunks to be done when the GUI is
otherwise idle. This technique works surprising well for a lot of
problems. You can do this, for example, by checking to see if work is
to be done and using CallAfter to put that chunk of work at the end of
the event queue. Animation is a perfect example that doesn't require
threads: render one scene then return to the event loop. Lather,
rinse, repeat.

One key to effective event based programming is to remember that the
event loop is just that: a loop, no different than any other loop.
Calling MainLoop is not much different than adding this to your code:

while &lt;we haven&#39;t been told to exit&gt;:
  &lt;get next event&gt;
  &lt;process next event&gt;

The right solution really depends on what you're trying to do, of
course. Some long running procedures can't be easily broken up into
small chunks, in which case threads (or arguably even better, separate
processes) can be used.

Bottom line, though, is not to think of the event loop as anything
mysterious or magical. It's just a loop.

-------------------
Mike Driscoll

Blog: http://blog.pythonlibrary.org

Definitely, a lengthy SQL call falls into the category of needing a
thread or separate process.

···

On Thu, Feb 10, 2011 at 4:08 PM, Mike Driscoll <kyosohma@gmail.com> wrote:

On Feb 10, 2:52 pm, Bryan Oakley <bryan.oak...@gmail.com> wrote:

Bottom line, though, is not to think of the event loop as anything
mysterious or magical. It's just a loop.

That's a pretty good point. I'm not sure if it will work with a
lengthy SQL call, but I liked your example.