Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #86100 > unrolled thread

Re: Design thought for callbacks

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-02-22 07:07 -0500

#86100 — Re: Design thought for callbacks

On Feb 21, 2015, at 10:55 AM, Chris Angelico <rosuav@gmail.com> wrote:

> On Sun, Feb 22, 2015 at 2:45 AM, Cem Karan <cfkaran2@gmail.com> wrote:
>> OK, so if I'm reading your code correctly, you're breaking the cycle in your object graph by making the GUI the owner of the callback, correct?  No other chunk of code has a reference to the callback, correct?
> 
> Correct. The GUI engine ultimately owns everything. Of course, this is
> a very simple case (imagine a little notification popup; you don't
> care about it, you don't need to know when it's been closed, the only
> event on it is "hit Close to destroy the window"), and most usage
> would have other complications, but it's not uncommon for me to build
> a GUI program that leaves everything owned by the GUI engine.
> Everything is done through callbacks. Destroy a window, clean up its
> callbacks. The main window will have an "on-deletion" callback that
> terminates the program, perhaps. It's pretty straight-forward.

How do you handle returning information?  E.g., the user types in a number and expects that to update the internal state of your code somewhere.

Thanks,
Cem Karan

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web