Re: change the content of the datasource for a tableView from a different class
Re: change the content of the datasource for a tableView from a different class
- Subject: Re: change the content of the datasource for a tableView from a different class
- From: Graham Cox <email@hidden>
- Date: Fri, 06 May 2011 09:46:06 +1000
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 (email@hidden)
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:
This email sent to email@hidden