Am 19.03.2010 09:20, schrieb Fred Kiefer:
My current position on NIB loading is that no magic should happen there.
Objects created while loading a NIB file should follow the standard
rules. Nothing will be retained except for the top level objects being
retained in the top level object array.
Hi Fred!
Am 19.03.2010 09:20, schrieb Fred Kiefer:
My current position on NIB loading is that no magic should happen
there.
Objects created while loading a NIB file should follow the standard
rules. Nothing will be retained except for the top level objects
being
retained in the top level
I'm not positive, but I'm guessing that these nib loading changes checked in
over the weekend are the cause of new crashes that we are seeing when building
with the latest code (r30018) on Windows.
Our app now crashes on launch. Here's the relevant gdb output:
Program received signal SIGSEGV,
Thank you for pointing out the problem with NSApp. This was caused by a
missing retain in some part of GSNibLoading that I hadn't cleaned up.
Hopefully this is fixed now. If there are any other issues I hope we can
resolve them as quick as that one.
Fred
Am 22.03.2010 18:24, schrieb Doug
Thanks Fred,
It looks like that has fixed the problem with NSApp. It also appears to have
solved the other problem that I reported to you privately. We will do some more
testing and let you know if we run into any other problems with nib loading.
Thanks for the quick fix!
Regards,
Doug
On
Great that you could work around the issue. It still remains to be
solved in a general way. It surely helps to know how your problem was
triggered. Did your controller retain the objects from the second NIB
file? And then when the controller was released these objects also
disappeared?
My current
Just in case my last mail wasn't clear enough on that point: All you
have to do to get your application working again with the current NIB
loading code is to add a setter method that retains its argument.
And for us it would be important to have an example of how it is failing
without that setter.
Okay, we've resolved this issue in our code at this point. We had a situation
where a controller object was being instantiated within our MainMenu.nib. When
that controller's init method was called it was loading another nib, and it was
an object in that nib (or maybe lots of them, who knows?)
Unfortunately, this change (Fred's commit in r29223) has broken our ported
Cocoa application (at least on Windows -- haven't had time to check on Linux
yet). At least some objects in our nib files are now freed after the nib loads,
and our application crashes when trying to access them.
I don't expect to see much differences between Windows and X11 on NIB
loading. If you could provide me with an stripped down example I would
try to have a look at what goes wrong there.
I'm already investigating an issue with the new code when loading a NIB
file that Wolfgang prepared for Ink.
Am 13.03.2010 00:31, schrieb Wolfgang Lux:
Fred Kiefer wrote:
Thank you for looking into this.
Looks like the basic difference between Cocoa and us is in the window,
window controller and document interaction. And you are the sole expert
we have on this :-)
At the end of the day it looks
Am 11.03.2010 19:46, schrieb Wolfgang Lux:
Fred Kiefer wrote:
Am 03.03.2010 10:06, schrieb Wolfgang Lux:
Fred Kiefer wrote:
I am not that sure about this.
When I changed to the current code it was to get the Beans application
working with GNUstep. There we had the case the components
Fred Kiefer wrote:
Thank you for looking into this.
Looks like the basic difference between Cocoa and us is in the window,
window controller and document interaction. And you are the sole
expert
we have on this :-)
At the end of the day it looks like my expertise isn't needed here.
The
Fred Kiefer wrote:
Am 03.03.2010 10:06, schrieb Wolfgang Lux:
Fred Kiefer wrote:
I am not that sure about this.
When I changed to the current code it was to get the Beans
application
working with GNUstep. There we had the case the components loaded
via
NIB where released to early by
Am 03.03.2010 10:06, schrieb Wolfgang Lux:
Fred Kiefer wrote:
I am not that sure about this.
When I changed to the current code it was to get the Beans application
working with GNUstep. There we had the case the components loaded via
NIB where released to early by GNUstep.
We rather
Am 02.03.2010 09:24, schrieb Wolfgang Lux:
Author: fredkiefer
Date: Sun Feb 8 13:54:21 2009
New Revision: 27812
URL: http://svn.gna.org/viewcvs/gnustep?rev=27812view=rev
Log:
Use KVC call setValue:forKey: to establish the outlet connection.
This will result in ivars being properly
Hi!
I remember having stumbled over this piece of code being the source of
a memory management issue of mine. Basically I renamed my setter
methods so the 'GSObjCSetVariable' branch would get used, all my
problems disappeared that way. I will dig out my project which had this
issue in the
17 matches
Mail list logo
