Re: Accessing NSTimer object added to NSRunLoop object
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 17:20:34 -0800
Hello...
As long as your window controller only controls one of these
tableViews, you shouldn't need to store the selected row in an
instance variable, since you probably don't need to make that
comparison.
Anytime the user clicks on a different row, any previous rows that
had been selected do not matter since you cancel the previous perform
request. The delayed selector will only be called after the currently
selected row has been selected for 1.5 seconds.
For example:
Time 0.00 -- user clicks on row 5. Your controller recieves the
tableViewSelectionDidChange: notification. You call performSelector:
with a delay of 1.5 seconds.
Time 0.80 -- user selects row 6. Your controller recieves the
tableViewSelectionDidChange: notification. The previous request (from
0.00) is cancelled, and you set up a new performSelector: with a
delay of 1.5 seconds.
Time 1.00 -- user selects row 5 again. Your controller recieves the
tableViewSelectionDidChange: notification. The previous request (from
0.80) is cancelled, and you set up a new performSelector: with a
delay of 1.5 seconds.
Time 1.60 -- user selects row 7. Your controller recieves the
tableViewSelectionDidChange: notification. The previous request (from
0.80) is cancelled, and you set up a new performSelector: with a
delay of 1.5 seconds.
Time 2.10 -- since 1.5 seconds have passed since 1.60, the delayed
selector is called, and the tableView provides the currently selected
row (which is row 7), and you mark that message as read (or whatever).
In other words, since the tableViewSelectionDidChange: notification
is sent whenever the row changes and the previous perform request is
cancelled and a new delayed one set up with a 1.5 second delay, the
delayed selector will only be called if the currently selected row
has been selected for 1.5 seconds since the last time the selection
was changed.
Since all of this is happening in the main thread, there shouldn't be
any way that the row could be changed "behind your back", so as long
as you check to make sure that there is only one row selected in the
delayed method, it should work fine.
Hope that helps,
Louis
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:
...
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.