• 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: "Louis C. Sacha" <email@hidden>
  • Date: Sun, 14 Mar 2004 12:37:10 -0800

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


Hi!

Is there any way to access instances of NSTimer class, added to an
instance of NSRunLoop class, without importing CoreFoundation framework
and messing with CFRunLoop and CFRunLoopTimer classes. What I want to
achieve is to remove all timers previously added to currentRunLoop
object and prevent them from firing, before adding the new one. This
fragment of code will make it more clear:

- (void)tableViewSelectionDidChange:(NSNotification *)notification
{
...
...
int selectedRow = [[self themeTableView] selectedRow];
NSTimer *readMessageTimer = [NSTimer timerWithTimeInterval:1.5
target:self
selector:@selector(fireTimer:)
userInfo:[NSNumber numberWithInt:selectedRow]
repeats:NO];
NSRunLoop *currentRunLoop = [NSRunLoop currentRunLoop];

// HERE, ALL TIMER PREVIOUSLY ADDED TO currentRunLoop SHOULD BE REMOVED
// SINCE I HAVE NO REFERENCE TO THEM TO CALL invalidate:

[currentRunLoop addTimer:readMessageTimer
forMode:NSDefaultRunLoopMode];
...
...
}

TIA,

Milke.
_______________________________________________
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: Dragan MiliÄ <email@hidden>
References: 
 >Accessing NSTimer object added to NSRunLoop object (From: Dragan MiliÄ <email@hidden>)

  • Prev by Date: Re: Writing a non-NSDocument based multiple document window apps
  • Next by Date: Re: Writing a non-NSDocument based multiple document window apps
  • Previous by thread: Accessing NSTimer object added to NSRunLoop object
  • Next by thread: Re: Accessing NSTimer object added to NSRunLoop object
  • Index(es):
    • Date
    • Thread