Tue 10 Jan 2006 04:56:56 PM UTC, comment #9:
I tried this ... it compiled, but when I ran it it immediately got an exception because it was trying to send a -saveWindowCoordinates message to TestWindow.
I wrote a dummy implementation of that method ... then the program ran.
The problem appears to be that you are not removing the observations you are setting up, because the notification names you are using in the addObserver... calls are not the same as the names you are using in the removeObserver... calls. This means that when subviews are destroyed, the expanding view still has them registered, and when a new subview happens to be created at the same location in memory and is registered as a notification object, you effectively get the same object registered twice.
The fix is to remove the notification registrations properly in the -removeExpandingSubview: method ... the simplest way to do that is
[[NSNotificationCenter defaultCenter] removeObserver: self name: nil object: [sender object]];
Using nil as the notification name will remove self as an observer for all notifications sent with that object.
|
Tue 10 Jan 2006 04:03:31 PM UTC, comment #8:
Here is the source, it is ready to compile and run. Please read the README.
Thanks
(I hope this is not a programming problem from me).
|
Tue 10 Jan 2006 08:59:03 AM UTC, comment #7:
I will delivery the source code ASAP, please wait. (I must cut out the interesting parts, otherwise it would be too huge).
Just one more remark: the very notification is sent once and the observer is registered once at the initialisation of the subview which is stored in a view. After sending the remover notification, the subview is deregistered from the notificationcenter and released.
|
Tue 10 Jan 2006 07:28:06 AM UTC, comment #6:
Cancel the second thoughts ... a little test on macos-x tiger shows that apple still has the behavior where adding an observer multiple times means it should receive multiple copies of the notification. I've added a note to the GNUstep documentation to say that, for compatibility, we do the same thing.
|
Tue 10 Jan 2006 07:12:00 AM UTC, comment #5:
Second thoughts ... I recall that a recent MacOS-X version noted some rewriting of the notification system, and checking the MacOS-X documentation I see that it no longer tells you that an observer can receive multiple copies of a notification if you register it as an observer multiple times, so it may be that the apple behavior has changed to only send one notification no matter how many times an observer is registered ... in which case it may make sense to change the gnuustep behavior too. I guess I'll do a small test program on macos-x to see what their current behavior actualy is.
|
Tue 10 Jan 2006 06:43:27 AM UTC, comment #4:
Fred, You would need to see a code example to be sure, but it's perfectly possible/legal for multiple copies of a notification to be received by an observer ... all that observer needs to have done is register for the notification multiple times.
My inclination would be to mark this bug report as declined/invalid ... since it's likely an error in the application code, and we have no examples to indicate an error in the gnustep libraries. Unless I see some evidence showing that the bug actually exists in the base library. I'll do that.
|
Tue 10 Jan 2006 12:16:32 AM UTC, comment #3:
The last comment from the originator makes this rather sound as a base bug, not a gui one. I therefore changed the category for this bug again.
|
Sun 01 Jan 2006 12:53:39 AM UTC, comment #2:
I'am trying to make a stripped down version of the source, please be patient.
BTW, this is the action method of mine that sends a notification on button pressing. I've tested: for one single buttonpress, the receiver gets sometimes two or more identical (id, etc.) notification objects. I suppose nsnotificatincenter does not clear objects with no observer, but I may be wrong. I will make further experimenting.
|
Sat 31 Dec 2005 04:33:04 PM UTC, comment #1:
Sorry, I don't quite understand this bug report. When a button gets pressed the action for the button get send. As far as I can tell no notification gets send. So which methods are transforming the actions into notifications? And is it possible to reproduce the same problem with actions only?
This could only be traced back to a GNUstep problem, if you are able to proof that the action sometimes gets send twice, when a button is pressed. For this it would help if you could either strip down your problem to a simpler scenario or add the code from your application to the bug report.
|
Thu 29 Dec 2005 02:46:51 PM UTC, original submission:
It is difficult to explain, but i am trying it:
I have a (sub)view A with to buttons (add, remove) in a (super)view S.
If I push the add button, a new (sub)view of this type (A) is created by the view S with the [addsubview:positioned:relativeTo:] method on a "addnewbutton" notification (defaultcenter) with this very (sub)view A as notification object.
If I push the remove button, the sender (sub)view A object is removed from the superview S on a "removebutton" notification (defaultcenter) with this very (sub)view A as notification object.
The (super)view S is registered for each (sub)view A.
The remove works fine. But after some removed (sub)view A, at the third or fourth try, the superview S receives multiple notifications with the same object and creates multiple (sub)views A in place of only one.
It sometimes results a crash with message "insertObject:atIndex: out of range".
I don't know if this a bug at all, or a bug in nsview or nsnotificationcenter or nsbutton. Strange.
Remark: I use the debian sarge package of gnustep, not a most recent from cvs. Any help is welcome. thanks
|