"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> Eric Brunel wrote: > > > But Hendrik's solution is better, since it avoids the use of lambda, which > > is often difficult to understand. > > storing the button reference in a variable doesn't help if you want to use the > same callback for multiple buttons, though... > > </F> I can't see how to use it for that - on the other hand, it enables you to use the same button for different things at different times by re configuring the command binding... This can be used as a sort of "state machine" to keep track of what the user is doing - changing button text, colour and command binding from "On", "green" and onOn to "Off", "red" and onOff... In my current project this style has developed to a point where onOn would change the colour,etc, as well as setting up a deferred callback to onOnTimeout, and firing off a message to the hardware in the field. A response from the successful completion is then used to call onOnEnd, which cancels the timed callback. onOnTimeout does emergency stuff because something did not work, as onOnEnd was not called... It is a bit more complex than the above - as there are intermediate "grey out" states - but the above illustrates the principle simply. It seems to work quite robustly, and I am also developing a Simple Distributed Control Language - SDCL (tm) , to do the work on the small micros in the field, tying everything together. - It was fun and almost indecently easy to write a one pass "compiler" resolving forward references on the fly in Python - more of an assembler, really - and no trace of lexx or yacc or bison - just a few lines of Python code - but I digress... And yes I know what SDLC is... *WEG* - Hendrik -- http://mail.python.org/mailman/listinfo/python-list