Updater Object In 2 Xib in the same application

ok, i'll try that.

thank you!

Thanks Andy Matuschak, that solved my question.

This makes no sense. The SUUpdater instance SHOULD be unique in this case. I think there's something else wrong. Though I don't understand the description, and I wonder what exception is thrown. Could it be that you're binding the updater to something?

Weeeell, I'm not so sure about that, Hofman. We don't override allocWithZone.

No the updater object was in both nib's not bound to anything.
just having 2 instances of the object breaks, even if it is not connected to any controls or properties.

I solved the problem in moving all my property window's related stuff to the main nib.

Not overriding allocWithZone: is not a relevant issue, because all custom objects in a nib are created by sending alloc+init (and before anything else is done with it), an uninitialized object will never be used for anything. And the updater returned by -init should always be the shared instance.

Now if the bundle objects were not unique, then the bundlePath should be used as the key in the dictionary. Much of the code assumes that the updater is shared.

BTW, I still don't know what the exception is.

I thought they're all created by sending alloc + initWithCoder.

No, not custom objects. NSObject does not even implement NSCoding. Custom subclasses of NSObject (and NSWindow, NSView, and NSControl) are instantiated using the designated initializer, which for NSObject is just -init.

instead of arguing for semantics why don't you guy's try it out.

1: mainmenu.xib, add a updater object foloing the instructions in the documentation
2: bind a check updates button to the updater object
3: save the nib.

4: create a window Xib for the preference pane,
5: instanciate another Updater object foloing the preferences instruction in the documentation.

create the glue code to load the nib and show the preference window, ino debug mode XCode will will report a binding problem.

a bit of code... load the nib and show the window.

 if (!preferenceWindowController) {
  preferenceWindowController = [[PreferenceWindowController alloc] init];
 }
 preferenceWindowController.mount = mount;
 [preferenceWindowController showWindow:self];

An excellent point. :)

I'll give it a try next time I'm hitting the bug queue.

First of all: this is not semantics, it's an important part of the design of Sparkle. If this fails, there's a serious bug somewhere.

Also, when I do what you say I see no problems.

humm.

I've tried it again and again...

me too...

I wonder if it's not the -unregisterAsObserver in -[SUUpdater dealloc]. That's potentially dangerous and moreover totally unnecessary, because instances that did register as observer will never be deallocated (as they're retained by the sharedUpdaters dictionary), while instances that are deallocated are never initialized (and therefore never registered).

Sandro, perhaps you can rebuild Sparkle with that line (SUUpdater line 373) commented out, and use that build instead in your test case?

Hofman, I was having the same issue and have done as you've indicated. It certainly stops the exception from occurring, but what other flow on effects will this have? Is there a cleaner answer to this problem?

It is -unregisterAsObserver that is causing the NSException.

Andy, many of us have a breakpoint set for NSException (and/or objc_exception_throw) in XCode. So every time we run the app and get to the point of the second nib instance it causes the breakpoint to fire and stop execution. This gets rather annoying after a while. :)

I solved this by adding a flag to SUUpdater called hasRegisteredObservers. I set it in -registerAsObserver and in -unregisterAsObserver if it is not set it returns.

No more unnecessary NSExceptions.

Ah, thanks. See related bug.