• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Accessing NSTimer object added to NSRunLoop object
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Accessing NSTimer object added to NSRunLoop object


  • Subject: Re: Accessing NSTimer object added to NSRunLoop object
  • From: Dragan MiliÄ <email@hidden>
  • Date: Sun, 14 Mar 2004 23:44:51 +0100

Hello...

Thank you Louis, it works, but with minor modification. Whether table view object that posted notification is the same as the one that the themeTableView outlet points to isn't important, since I explicitly ask who is posting the notification at the beginning of the notification method. But I need to ask for selected row both times; in notification method and in delayed method as well. I actually want to achieve something similar as seen in Apple Mail: if unread message is selected alone, it should be marked as read after about 1.5 seconds of being continuously selected. That's why I need to ask for selected row once the selection changes and second time in delayed method, so if the two are equal, the message is marked as read. This also works with NSTimer approach, but then the user might select unread message and then, within 1.5 seconds deselect it and select it again, and after 1.5 seconds after first selection, the message would be marked as read, which is not correct behavior. That's why I needed to cancel already added timer after every selection change. Now I know how to cancel the delayed operation, but I have to pass the selected row to delayed method for comparison. And the reference to it is obtained through an instance variable selectedRowNumber. Now, I must admit that I don't particularly like the fact that I need to add new instance variable in my window controller object (which is delegate for themeTableView) just to keep record of selected row in the table view, but for now that' the way it is. Maybe I'll try with CFRunLoop and CFRunLoopTimer, just for the sake of exercising. Now it looks something like this:

- (void)tableViewSelectionDidChange:(NSNotification *)notification
{
...
...
int selectedRow = [[self themeTableView] selectedRow];
[NSObject cancelPreviousPerformRequestsWithTarget:self
selector:@selector(runDelayedSelector:)
object:[self selectedRowNumber]];
[self setSelectedRowNumber:[NSNumber numberWithInt:selectedRow]];
[self performSelector:@selector(runDelayedSelector:)
withObject:[self selectedRowNumber]
afterDelay:1.5];
...
...
}

- (void)runDelayedSelector:(NSNumber *)number
{
int numOfSelectedRows = [[self themeTableView] numberOfSelectedRows];
int prevSelectedRow = [number intValue];
int selectedRow = [[self themeTableView] selectedRow];
if ((numOfSelectedRows == 1) &&
(selectedRow == prevSelectedRow)) {
[self markMessageReadAction:self];
}
}

Thanks anyway.

Milke.

Hello...

Instead of using an NSTimer, you might be able to use the built in delayed perform capability of NSObject.
If you can look up the row from the delayed method, then the implementation would be pretty simple. If the object that the themeTableView outlet points to is the same tableView that sends this notification and not a different table, or the other table will not change it's row selection, then this method would work.

/* code typed in mail, untested, etc...


- (void)tableViewSelectionDidChange:(NSNotification *)notification
{
/* ... */
/* ... */

[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(selectionDidChangeAction) object:nil];
[self performSelector:@selector(selectionDidChangeAction) withObject:nil afterDelay:1.5];

/* ... */
/* ... */
}

- (void)selectionDidChangeAction
{
/* do your task here, after looking up the selectedRow of the other view/table */
int selectedRow = [[self themeTableView] selectedRow];

/* ... */
}


The reason that you wouldn't be able to pass the row as the withObject: argument of the performSelector:withObject:afterDelay: call is that you would need a reference to it to be able to cancel the request, which is the same sort of problem as you have with the NSTimer approach. If the table you are getting the row from is the same table where the row selection changed, then it doesn't matter if the row is looked up in the notification action or in the delayed method, and this should work perfectly.


Hope that helps,

Louis
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.


  • Follow-Ups:
    • Re: Accessing NSTimer object added to NSRunLoop object
      • From: "Louis C. Sacha" <email@hidden>
References: 
 >Accessing NSTimer object added to NSRunLoop object (From: Dragan MiliÄ <email@hidden>)
 >Re: Accessing NSTimer object added to NSRunLoop object (From: "Louis C. Sacha" <email@hidden>)

  • Prev by Date: XML-RPC calls in Cocoa - alternative to CURLHandle?
  • Next by Date: Re: storing default preferences
  • Previous by thread: Re: Accessing NSTimer object added to NSRunLoop object
  • Next by thread: Re: Accessing NSTimer object added to NSRunLoop object
  • Index(es):
    • Date
    • Thread