There's several ways, whatever you can think of to implement canceling
or ignoring a previous request. For instance maybe just use an
incrementing counter. Before you detach the thread tell the PDF view
what number it should expect, then pass that number to the thread,
which will then be passed back to the PDF view from the thread. The
PDF view can then check if the number of the response is equal to the
number it's currently waiting for.
Or you can identify each item in the table view with ascending numbers
or names (a string name, file path, row number) and use that as the
unique ID for the corresponding PDF. The advantage to this is if the
PDF view gets an old response back, it can cache it in a dictionary
for when the table item it belonged to is selected again. Before
loading the data it can first check if the data had already been
loaded and just grab it from the dictionary, using the unique ID as
the key. Caching responses depends how often you might load the same
PDF multiple times and how large the data is.
performSelectorOnMainThread:withObject:waitUntilDone: only allows one
argument, but you can put multiple args in an array and pass that in.
There's better ways to pass multiple arguments such as Distributed
Objects, but that's a whole other concept you'll have to learn. DO is
a mechanism where threads can communicate and pass objects back and
forth between each other, even threads in different processes.
Also, it might make more sense to put up the progress indicator from
the main thread before detaching to load and then dismiss the
indicator when the PDF view gets the PDF it wants. Since it's
possible for multiple load threads to be running at the same time, you
don't want them both fighting over control of the progress indicator.
As you become more familiar with threading and making it work you'll
find more elegant ways to implement all of this. My suggestions are
less elegant but easier to start with. Just remember there's no
guarantee with the order threads will complete; it's possible a later
request can finish before a previous one.
These are just a few ideas, but there's many ways you could handle this.
On May 6, 2008, at 7:25 AM, Karl von Moller wrote:
I think you are right. It is the PDF loading that appears to be
causing the crashing. I think your guess on the previous call to the
Thread completing when a new PDF should load is absolutely the
problem. Trouble is I really don't know how to implement the Unique
ID system you speak of. I might have to do some serious reading
before advancing much from here. Any suggested reading or example
code I could look at?
_______________________________________________
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 [EMAIL PROTECTED]
