On 06/05/2011, at 9:21 AM, Martin Batholdy wrote:
> - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
>
> test = [tableViewController sharedPrefsWindowController];
> [test showWindow:self];
>
> updateTest *deleteEntry;
> deleteEntry = [[updateTest alloc] init];
> }
The problem could simply be how you are testing it, assuming that all the IB
connections are correctly hooked up - as I can't see them I have to take it as
read that they are. In particular, that the controller's 'window' outlet is set
and that the table view's datasource is indeed the controller.
First off, using an object to perform a test like this is bizarre, to say the
least. It's not wrong, exactly, but I wouldn't do it this way.
But anyway, you invoke your test immediately after calling -showWindow: on the
controller. While that call will load the window and schedule it for display,
it won't actually be drawn yet. That won't happen until the event loop gets a
chance to run, some time after your test has already run. (Note: also ensure
that 'visible at launch' is UNCHECKED in IB for this window. I have no idea why
this setting still defaults to on after all these years, but you almost never
want it on. If it is, that could also be tricking you into thinking that the
window is being shown by your code, when in fact it's just being shown
automatically).
What I would expect to see is that your table shows up with one line - you
added two elements to your content when initialising the table, and your test
deletes the first one, leaving one. Is that what you see? In which case, it's
working as expected as far as the code presented goes.
A better way to test this would be to hook up a temporary 'test' menu item to
an action that calls your -updateView method (do change that name). That way
you can manually decide when to invoke the test and see that it has the desired
effect. I'd get rid of your 'updateTest' object and just invoke the tests you
want directly - the test object is just adding complication that is clouding
any real issues (the opposite of what it is intended to do, presumably).
Separating out the test from the start-up/initialisation of the app will also
make it much easier to set breakpoints so you can follow what's going on in the
debugger without tripping these during launch, at which time the app is not yet
in a fully running state.
Also, point of order - since this is a follow-up to your questions yesterday,
you should have kept it in the same thread.
--Graham
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
