I am having issue with subscribing to a topic in my classes with wx.lib.pubsub. I have three classes: Parent (Controller), Child (MainWindow) and GrandChild (Dialog) classes. Parent subscribes to a topic ‘UpdateConfig’ published by the GrandChild. Whenever the OK button of GrandChild is called, it calls pub.SendMessage(‘UpdateConfig’, connectionName = “…”). But Parent’s listener is triggered only for the first time and not there after.I don’t see any error messages either. Is there any hierarchy that is followed by pubsub?
attached a minimum example which could correlate what you are trying to do (I am on wxPython 2.9.5.0/py2.7.6/Win7 32).
It took me by surprise that subscribing to the pubsub event in the controller did never fire, whilst subscribing in the wx.Frame (even twice) woks as expected.
Then I changed the line
controller()
to
myctrl = controller()
So it seems if no reference is kept to the controller, pubsub will no longer care for it.
That does seem a little strange, you’d think the reference pubsub maintains
to the callable listener method would be enough to keep the object alive. As
you have proven, you need a reference to the entire controller object.
there is a function called setNotificationFlags you can do to capture
pubsub activity. I’m guessing you’ll get a “deadListener” notification
for that case.
On Tuesday, August 19, 2014 12:13:30 PM UTC-4, nepix32 wrote:
Hello too,
attached a minimum example which could correlate what you are trying to do (I am on wxPython 2.9.5.0/py2.7.6/Win7 32).
It took me by surprise that subscribing to the pubsub event in the controller did never fire, whilst subscribing in the wx.Frame (even twice) woks as expected.
Then I changed the line
controller()
to
myctrl = controller()
So it seems if no reference is kept to the controller, pubsub will no longer care for it.
I’ve had that happen with wx.Timer objects too… if you don’t save them somewhere, they evaporate and stop firing and the timer handler never hears from the timer again.
···
On Tuesday, August 19, 2014 9:13:30 AM UTC-7, nepix32 wrote:
Then I changed the line
controller()
to
myctrl = controller()
So it seems if no reference is kept to the controller, pubsub will no longer care for it.
Yes, that is strange. It worked. Great. Thank you so much.
···
On Tuesday, August 19, 2014 9:40:34 AM UTC-7, Rufus wrote:
That does seem a little strange, you’d think the reference pubsub maintains
to the callable listener method would be enough to keep the object alive. As
you have proven, you need a reference to the entire controller object.
there is a function called setNotificationFlags you can do to capture
pubsub activity. I’m guessing you’ll get a “deadListener” notification
for that case.
On Tuesday, August 19, 2014 12:13:30 PM UTC-4, nepix32 wrote:
Hello too,
attached a minimum example which could correlate what you are trying to do (I am on wxPython 2.9.5.0/py2.7.6/Win7 32).
It took me by surprise that subscribing to the pubsub event in the controller did never fire, whilst subscribing in the wx.Frame (even twice) woks as expected.
Then I changed the line
controller()
to
myctrl = controller()
So it seems if no reference is kept to the controller, pubsub will no longer care for it.
Pubsub uses weak references for listeners. This is a Feature (c) (r) ™. It’s only briefly mentioned in the reference though: http://pubsub.sourceforge.net/usage/core_classes.html#listener; there’s probably room for improvement in the documentation here.
That does seem a little strange, you’d think the reference pubsub maintains
to the callable listener method would be enough to keep the object alive. As
you have proven, you need a reference to the entire controller object.
Pubsub does not hold strong references to listeners, so that a listener is not “artificially” kept alive after the application no references it. Unfortunately there is no reliable way to determine if a listener will be dead as soon as the registration has completed (for example it is easy to have the reference count > 1 yet the listener is passed as a temporary). If you know one by all means let me know. So for now basically it is “beware of this gotcha” which is explained, by the way, on http://pubsub.sourceforge.net/usage/usage_basic_tasks.html, the big red warning box. Let me know if I can make it more obvious or clearer
···
On Tue, Aug 19, 2014 at 3:43 PM, Jérôme Laheurte fraca7@gmail.com wrote:
That does seem a little strange, you’d think the reference pubsub maintains
to the callable listener method would be enough to keep the object alive. As
you have proven, you need a reference to the entire controller object.
Pubsub uses weak references for listeners. This is a Feature (c) (r) ™. It’s only briefly mentioned in the reference though: http://pubsub.sourceforge.net/usage/core_classes.html#listener; there’s probably room for improvement in the documentation here.
Cheers
Jérôme
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
Then I realised that what I had searched for when first using pubsub was “Basic Usage”, not the “Quick Intro”. pyPubSub TOC is structured as follows:
…
Use
Basic Usage
Advanced Usage
…
When you click on “Basic usage” you get presented witch “Quick Intro”. If you do not read “Quick Intro” carefully (guilty as charged on document-skimming), you do not realise, that for going to “Basic Usage” you have to click a link in “Quick Intro” at the top first. Therefore I completely overlooked the chapter “Basic Usage”, what I was searching for in the first place. If I had clicked on “Use” in the main TOC I would maybe not have overlooked it (the link to “Basic Usage” in the TOC it is nicely presented there as it is in the first introductory sentence). Funnily “Basic Usage” here comes before “Quick Intro”.
Just my user experience for an otherwise very interesting module.
···
On Wednesday, August 20, 2014 4:06:28 AM UTC+2, schoenborno wrote:
means let me know. So for now basically it is “beware of this gotcha” which is explained, by the way, on http://pubsub.sourceforge.net/usage/usage_basic_tasks.html, the big red warning box. Let me know if I can make it more obvious or clearer
Missed that Obviously there are gotchas with weak references (Jython and its garbage collector…) but then strong references have their problems too. I don’t have any preference personally.
Pubsub does not hold strong references to listeners, so that a listener is not “artificially” kept alive after the application no references it. Unfortunately there is no reliable way to determine if a listener will be dead as soon as the registration has completed (for example it is easy to have the reference count > 1 yet the listener is passed as a temporary). If you know one by all means let me know. So for now basically it is “beware of this gotcha” which is explained, by the way, on http://pubsub.sourceforge.net/usage/usage_basic_tasks.html, the big red warning box. Let me know if I can make it more obvious or clearer
My own experience is that it is much easier to get around the ghost-listener trap (which results from using weak references) than it is to get around the orphan-zombie-listener trap (which results from strong references). The former just requires you store an additional variable, the latter requires you find ways to track when your listener is no longer in use and de-register it, typically much more work.
···
On Wed, Aug 20, 2014 at 8:16 AM, Jérôme Laheurte fraca7@gmail.com wrote:
Pubsub does not hold strong references to listeners, so that a listener is not “artificially” kept alive after the application no references it. Unfortunately there is no reliable way to determine if a listener will be dead as soon as the registration has completed (for example it is easy to have the reference count > 1 yet the listener is passed as a temporary). If you know one by all means let me know. So for now basically it is “beware of this gotcha” which is explained, by the way, on http://pubsub.sourceforge.net/usage/usage_basic_tasks.html, the big red warning box. Let me know if I can make it more obvious or clearer
Missed that Obviously there are gotchas with weak references (Jython and its garbage collector…) but then strong references have their problems too. I don’t have any preference personally.
Cheers
Jérôme
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
