Re: sending msgs to nsoperation threads
On Nov 11, 2010, at 8:13 AM, Shane wrote:
> I've got an NSOperation thread running, but I'd like to be able to
> send a message to it so that the thread can be shut it down, or
> possibly other commands.
>
> What is considered a good way to send a message to an NSOperation
> thread from the apps main thread?
Usually, NSOperation objects execute on threads managed by the corresponding
NSOperationQueue where you added them, e.g.:
MyOperation* op = [[MyOperation alloc] initWithMyParams:params];
[self.myOperationQueue addOperation op];
So, whatever operation queue you use, the *operation queue* is responsible for
managing the threads your operation will execute on. The operation queue hides
the complexity to create and destroy the threads - which is a good thing. Which
threads the operation queue creates and when is a private thing to the
operation queue. So, you should not bother with this.
Note, that there is a global queue [NSOperationQueue mainQueue] which executes
its operations on the main thread.
In order to cancel an *operation* (not a thread) you can send the operation
object the -cancel message from any other execution context. All what is
required is to design the method -main of your operation such that it
periodically checks whether it has been cancelled, e.g.:
- (void) main {
if ([self isCancelled])
return;
BOOL done = NO;
while (!done) {
// do a peace of work
// ...
if ([self isCancelled]) {
// optionally send the "delegate" a notification about the
cancellation.
return;
}
}
// send the "delegate" a message about the result of the operation
}
Note: "delegate" is defined in your custom Operation.
When you send (custom) messages to an operation, you should care about proper
synchronization if necessary.
see also:
NSOperationQueue: -cancelAllOperations
NSOperation: -cancel
NSOperation: "Responding to the Cancel Command"
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/NSOperation_class/Reference/Reference.html
http://developer.apple.com/cocoa/managingconcurrency.html
Have fun!
Andreas
___
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 arch...@mail-archive.com
Re: sending msgs to nsoperation threads
On 11 Nov 2010, at 07:13, Shane wrote: > I've got an NSOperation thread running, but I'd like to be able to > send a message to it so that the thread can be shut it down, or > possibly other commands. > > What is considered a good way to send a message to an NSOperation > thread from the apps main thread? > ___ > NSOperation is a great way to schedule a distinct and largely none interacting operation. It is not a universal concurrency solution. I would drop down to NSThread in this situation. You have to do a bit more management but you get the control you need. Also NSOperation generated threads do not, IIRC, instantiate a run loop. If you want to message your thread using performSelector:onThread you will need a run loop. Regards Jonathan Mitchell Developer Mugginsoft LLP http://www.mugginsoft.com ___ 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 arch...@mail-archive.com
Re: Moderator - Re: iPad 4.2 (deploy to 3.2.2) error
On 10 Nov 2010, at 17:54, Shawn Bakhtiar wrote: > Only those who have actually signed an NDA with Apple are subject to this, > and they are certainly free to refrain from comment. > > Everyone else is free to talk, blog, and post about it how they please. Perhaps you could refrain from giving incorrect legal advice on the cocoa-dev mailing list? The material covered by an NDA is generally regarded as a trade secret; many jurisdictions have explicit trade secret legislation, and even those that don't may allow prosecution of *recipients* of trade secrets for receiving stolen goods (or similar). If you want to know how that affects you, you should consult a qualified lawyer. In any event, cocoa-dev is run by Apple. Even without the NDA, Apple is well within its rights to insist that some things can't be discussed here, and arguing with the moderator will just mean that you're moderated or eventually banned from the list (and maybe *all* of Apple's lists, in extreme cases) altogether. Kind regards, Alastair. -- http://alastairs-place.net ___ 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 arch...@mail-archive.com
Re: Moderator - Re: iPad 4.2 (deploy to 3.2.2) error
On 10 Nov 2010, at 19:00, Laurent Daudelin wrote: > Note: I am not an Apple's employee and have agreed/signed all NDAs. > > Now, although I agree with the above comment from Scott, if you haven't > signed an NDA specifically with Apple, how do you know when you're talking > about something that it's under NDA or not? For example, I have seen already > a few walkthrough of and information about iOS 4.2 on iPads/iPhones even > though iOS 4.2 hasn't been released yet. > > Not trying to nitpick, just wondering if you haven't agreed to any NDA, how > do you know you're stepping out or not? All of these are really questions for a lawyer, rather than cocoa-dev, and the answer almost certainly depends on the legal jurisdiction within which you are operating. Kind regards, Alastair. -- http://alastairs-place.net ___ 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 arch...@mail-archive.com
NSData magic change
I find this issue very puzzling. I read a plist dictionary containing one ony key-value: an NSData coming a RTFD string. I read this value, I do NO changes, then I re-save it to a different plist file, and now the 2 files are different. I have inspected these 2 plist files with TextWrangler, and the difference is at the last chars of the object. These chars change 'every time' I save. Why? How can I get 2 equal dicts? docDictR = [NSDictionary dictionaryWithContentsOfFile:@"/Dict1.plist"]; textDataR = [docDictR objectForKey:@"textData"]; mString = [[NSMutableAttributedString alloc] initWithRTFD:textDataR documentAttributes:nil]; // now I save it textRangeW = NSMakeRange(0, [mString length]); textDataW = [mString RTFDFromRange:textRangeW documentAttributes:nil]; docDictW = [NSMutableDictionary dictionary]; [docDictW setObject:textDataW forKey:@"textData"]; [docDictW writeToFile:@"/Dict2.plist" atomically:YES]; Dict1.plist last chars of the object ALS20y2AQA= Dict2.plist last chars of the object DHV20y2AQA= Regards Leonardo ___ 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 arch...@mail-archive.com
Re: NSData magic change
On 11 Nov 2010, at 11:57, gMail.com wrote: > I find this issue very puzzling. > > I read a plist dictionary containing one ony key-value: an NSData coming a > RTFD string. I read this value, I do NO changes, then I re-save it to a > different plist file, and now the 2 files are different. I have inspected > these 2 plist files with TextWrangler, and the difference is at the last > chars of the object. These chars change 'every time' I save. Why? > How can I get 2 equal dicts? > > docDictR = [NSDictionary dictionaryWithContentsOfFile:@"/Dict1.plist"]; > textDataR = [docDictR objectForKey:@"textData"]; > mString = [[NSMutableAttributedString alloc] initWithRTFD:textDataR > documentAttributes:nil]; > > // now I save it > > textRangeW = NSMakeRange(0, [mString length]); > textDataW = [mString RTFDFromRange:textRangeW documentAttributes:nil]; > docDictW = [NSMutableDictionary dictionary]; > [docDictW setObject:textDataW forKey:@"textData"]; > [docDictW writeToFile:@"/Dict2.plist" atomically:YES]; > > > Dict1.plist last chars of the object > ALS20y2AQA= > > Dict2.plist last chars of the object > DHV20y2AQA= > > > Regards > Leonardo Was the original plist created on another version of OS X? Might be embedded version info used internally by NSAttributedString. The NSData rep is private. NSAttributedString is tool free bridged to CFAttributedString but the latter is missing from http://www.opensource.apple.com/source/CF/CF-550/ One solution would be to not resave the NSData rep unless the NSAttributed content has actually changed. Regards Jonathan Mitchell Developer Mugginsoft LLP http://www.mugginsoft.com___ 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 arch...@mail-archive.com
Re: NSTableView within NSScrollView in code
Hallo Jerry
Thanks a lot. You got me going ...
Here's what I did:
defaultCenter = [NSNotificationCenter defaultCenter];
[defaultCenter addObserver:self
selector:@selector(clipviewFrameChanged:)
name:NSViewFrameDidChangeNotification
object:[scrollView contentView]];
- (void)clipviewFrameChanged:(NSNotification *)aNotification
{
[tableView sizeToFit];
}
After all the setup, I add an observer to the NSClipView
that is the scrollvies's contentView.
Whenever the clipview changes, I poke the tableview
as you suggested.
Thanks a lot for the idea !!!
Two sidenotes if someone cares:
1)
The corresponding setup in IB (TableView in ScrollView, which tracks window
size),
creates a scrollview that has both the documentView and the contentView
pointing to the
identical NSClipView (checked with gdb). This setup can not be done in code,
setting
the documentView changes something in the clipView leading to an exception
2)
I have created a custom TableColumn, implementing "setWidth:" by just calling
super. If you do so, you can look at the backtrace.
You'll note that the clipView post a frame change notification, which will
be observed in 'superviewFrameChanged:' in te tableview.
The fits thing I tried was to implenent that:
[defaultCenter addObserver:tableView
selector:@selector(superviewFrameChanged:)
name:NSViewFrameDidChangeNotification
object:[scrollView contentView]];
Strange thing, it does NOT work, allthough the contentView
is in fact posting these notifications.
I checked this by simply implementing the first snippet.
Cheers and thanks for reading.
Patrick
On 11.11.2010, at 05:11, Jerry Krinock wrote:
>
> On 2010 Nov 10, at 14:09, Patrick Mau wrote:
>
>> So someone must tell the tableView that it should resize its colums in
>> response
>> to a scrollview frame change.
>
> Try poking it with -[NSTableView sizeLastColumnToFit] or -[NSTableView
> sizeToFit].
>
> ___
>
> 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/pmau%40me.com
>
> This email sent to p...@me.com
___
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 arch...@mail-archive.com
Re: Detecting reading a key in KVC
Op 10-11-2010 15:31, Quincey Morris schreef: On Nov 10, 2010, at 06:10, jonat...@mugginsoft.com wrote: I was just thinking that the overrides would provide a convenient point to process all requests for undefined properties. Depends on the design and requirements of the model I suppose. I don't think that's happening here -- the property isn't undefined initially, it just has an incorrect value initially. :) The point is, I think, to avoid overriding 'valueForKey:', because of the potential horrendous performance problems that could result. Thanks for all replies. I think I've a problem there. I store all my properties in a NSMutableDictionary, so implementing my own getters is not possible. I tried overriding valueForKey: by subclassing NSMutableDictionary, but soon found out that was not possible as it is a cluster. Leaves me wondering whether I should hardcode all properties (82 items) on my own object or try to make a more intelligent subclass of NSMutableDictionary. Or maybe a composite object? Kind regards, Remco Poelstra ___ 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 arch...@mail-archive.com
Re: Detecting reading a key in KVC
On 11/11/2010, at 11:41 PM, Remco Poelstra wrote: > Leaves me wondering whether I should hardcode all properties (82 items) on my > own object or try to make a more intelligent subclass of NSMutableDictionary. > Or maybe a composite object? If the requirement is simply to distinguish between an uninitialised value and a real value, why not just implement your own object with a method -valueForKey: and do whatever you want in there. It could have a NSMutableDictionary as a backing store. One method (not 82) and problem solved. Sounds so simple I'm surely missing something --Graham ___ 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 arch...@mail-archive.com
Re: Detecting reading a key in KVC
On 11 Nov 2010, at 12:41, Remco Poelstra wrote: > Op 10-11-2010 15:31, Quincey Morris schreef: >> On Nov 10, 2010, at 06:10, jonat...@mugginsoft.com wrote: >> >>> I was just thinking that the overrides would provide a convenient point to >>> process all requests for undefined properties. >>> Depends on the design and requirements of the model I suppose. >> >> I don't think that's happening here -- the property isn't undefined >> initially, it just has an incorrect value initially. :) >> >> The point is, I think, to avoid overriding 'valueForKey:', because of the >> potential horrendous performance problems that could result. > > Thanks for all replies. I think I've a problem there. I store all my > properties in a NSMutableDictionary, so implementing my own getters is not > possible. I tried overriding valueForKey: by subclassing NSMutableDictionary, > but soon found out that was not possible as it is a cluster. > Leaves me wondering whether I should hardcode all properties (82 items) on my > own object or try to make a more intelligent subclass of NSMutableDictionary. > Or maybe a composite object? I would try composition. Regards Jonathan Mitchell Developer Mugginsoft LLP http://www.mugginsoft.com___ 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 arch...@mail-archive.com
Re: Detecting reading a key in KVC
Op 11-11-2010 13:48, Graham Cox schreef: On 11/11/2010, at 11:41 PM, Remco Poelstra wrote: Leaves me wondering whether I should hardcode all properties (82 items) on my own object or try to make a more intelligent subclass of NSMutableDictionary. Or maybe a composite object? If the requirement is simply to distinguish between an uninitialised value and a real value, why not just implement your own object with a method -valueForKey: and do whatever you want in there. It could have a NSMutableDictionary as a backing store. One method (not 82) and problem solved. Sounds so simple I'm surely missing something Seems so :) I just tried that and observing the change of properties is now non-functional, as the request for observing is not forwarded to the NSDictionary behind my own object. Seems I've to override a whole lot of methods to forward them all to the backingstore. Regards, Remco Poelstra ___ 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 arch...@mail-archive.com
Re: Detecting reading a key in KVC
On 12/11/2010, at 12:01 AM, Remco Poelstra wrote: > Seems so :) I just tried that and observing the change of properties is now > non-functional, as the request for observing is not forwarded to the > NSDictionary behind my own object. Seems I've to override a whole lot of > methods to forward them all to the backingstore. You seem to be overthinking this. Just write a wrapper for -setObject:forKey: and -valueForKey: The first just calls the same method on its (mutable) dictionary, the second can first check for whether the value is actually present and if not kick off some task to fetch it, or else just get it from the dictionary and return it. You don't need to do any general purpose forwarding, unless your object has to look exactly like a dictionary externally for some reason, but even then the few methods a dictionary implements are still easy to just write wrappers for individually rather than doing a general forwarding. This is an extremely common implementation for caching and I've rarely found it more complicated than this. --Graham ___ 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 arch...@mail-archive.com
Re: Detecting reading a key in KVC
Op 11-11-2010 14:11, Graham Cox schreef: On 12/11/2010, at 12:01 AM, Remco Poelstra wrote: Seems so :) I just tried that and observing the change of properties is now non-functional, as the request for observing is not forwarded to the NSDictionary behind my own object. Seems I've to override a whole lot of methods to forward them all to the backingstore. You seem to be overthinking this. Just write a wrapper for -setObject:forKey: and -valueForKey: The first just calls the same method on its (mutable) dictionary, the second can first check for whether the value is actually present and if not kick off some task to fetch it, or else just get it from the dictionary and return it. You don't need to do any general purpose forwarding, unless your object has to look exactly like a dictionary externally for some reason, but even then the few methods a dictionary implements are still easy to just write wrappers for individually rather than doing a general forwarding. This is an extremely common implementation for caching and I've rarely found it more complicated than this. It might well be that I forgot to implement change notification in my wrapper for setObject:forKey: breaking KVO compliance. I'll try that out. Regards, Remco Poelstra ___ 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 arch...@mail-archive.com
NSTextView vs NSTextField
It seems to me that NSTextView can do everything that NSTextField can and more. For example, on a NSTextView, one can use the method setHorizontallyResizable: and then call sizeToFit to get it to resize itself vertically instead of horizontally. Is this correct? If so and if I am programmatically creating one of these controls, is there any reason why I would want to use a NSTextField? (I know that IB uses a NSTextField for Labels, for example...is this just a historical artifact?) If not, what are the key differences between them that would cause me to want to use a NSTextField? Would it basically come down to whether or not I need more then a single line of text or not...NSTextField seems to be optimized for single lines of text, but one can still get the same behavior out of a NSTextView with a bit more work. Now, I know that NSTextFieldCell is commonly used as a superclass for one's own cell based stuff, but I would consider that as separate from the issue of NSTextField vs NSTextView. Thank you. ___ 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 arch...@mail-archive.com
RTFDFromRange returns different data
RTFDFromRange returns different data even if I do not change the variables mTextMutableString nor mDocAttributes. I just call several time: NSData *textData = [mTextMutableString RTFDFromRange:textRange documentAttributes:mDocAttributes]; NSLog(@"textData %@", textData); And 'every time' I get a different textData log text. Of course I compare the text starting from < For example, at any call I get (this is the last changing part of the log text) 1) edecdb4c b601 > 2) 2aebdb4c b601 > 3) a6f8db4c b601 > 4) bef8db4c b601 > Why does RTFDFromRange returns a different data, even if the variables didn't change? How to get the same data? Is it a bug? Regards Leonardo ___ 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 arch...@mail-archive.com
Invitation to connect on LinkedIn
LinkedIn amit jain requested to add you as a connection on LinkedIn: -- Cameron, I'd like to add you to my professional network on LinkedIn. - amit Accept invitation from amit jain http://www.linkedin.com/e/-bq75p7-ggdq471k-3v/AdB-vBGUaPDD8CAZeSRcxp2nG5JDH2anAKj_Cxr/blk/I947844194_3/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_cRYQej4Qd3wTd3B9bSRkj6xQmCBqbPgVe3cMdj8Ve34LrCBxbOYWrSlI/EML_comm_afe/ View invitation from amit jain http://www.linkedin.com/e/-bq75p7-ggdq471k-3v/AdB-vBGUaPDD8CAZeSRcxp2nG5JDH2anAKj_Cxr/blk/I947844194_3/0PnPgVcjgQe3sQekALqnpPbOYWrSlI/svi/ -- DID YOU KNOW your LinkedIn profile helps you control your public image when people search for you? Setting your profile as public means your LinkedIn profile will come up when people enter your name in leading search engines. Take control of your image! http://www.linkedin.com/e/-bq75p7-ggdq471k-3v/ewp/inv-22/ -- (c) 2010, LinkedIn Corporation ___ 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 arch...@mail-archive.com
Re: RTFDFromRange returns different data
On Nov 11, 2010, at 8:12 AM, gMail.com wrote: > RTFDFromRange returns different data even if I do not change the variables > mTextMutableString nor mDocAttributes. I just call several time: > > NSData *textData = [mTextMutableString RTFDFromRange:textRange > documentAttributes:mDocAttributes]; > NSLog(@"textData %@", textData); > > And 'every time' I get a different textData log text. > Of course I compare the text starting from < > > For example, at any call I get > (this is the last changing part of the log text) > 1) edecdb4c b601 > > 2) 2aebdb4c b601 > > 3) a6f8db4c b601 > > 4) bef8db4c b601 > > > Why does RTFDFromRange returns a different data, even if the variables > didn't change? How to get the same data? Is it a bug? RTFDFromRange returns an archived (flattened) version of RTFD, which is undocumented but probably includes things like time stamps or unique IDs. So it is not a bug - archiving the same original data is not guaranteed to return byte-for-byte identical archived results (but will return the same thing when unarchived). Glenn Andreas gandr...@gandreas.com The most merciful thing in the world ... is the inability of the human mind to correlate all its contents - HPL ___ 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 arch...@mail-archive.com
Re: sending msgs to nsoperation threads
On Nov 11, 2010, at 10:35 AM, jonat...@mugginsoft.com wrote:
>
> On 11 Nov 2010, at 07:13, Shane wrote:
>
>> I've got an NSOperation thread running, but I'd like to be able to
>> send a message to it so that the thread can be shut it down, or
>> possibly other commands.
>>
>> What is considered a good way to send a message to an NSOperation
>> thread from the apps main thread?
>> ___
>>
>
> NSOperation is a great way to schedule a distinct and largely none
> interacting operation.
> It is not a universal concurrency solution.
>
> I would drop down to NSThread in this situation.
Please checkout the Apple iOS example application "TopSongs". This is a
nontrivial example using a NSURLConnection within an operation which exactly
does what you think would only be doable when using NSThread. :)
> You have to do a bit more management but you get the control you need.
IMHO, using NSOperation/NSOperationQueue is exactly what I consider a higher
level API. It has also additional cool features which give you even more
control where NSThread doesn't provide such things at all. So, for me in many
cases it's much more easier to use NSOperations than implementing the same
thing using NSThread.
>
> Also NSOperation generated threads do not, IIRC, instantiate a run loop.
The thread executing an NSOperation scheduled from an NSOperationQueue already
has a run loop :) But of course you need to use it, see example below.
> If you want to message your thread using performSelector:onThread you will
> need a run loop.
In case you would like to do similar things when using NSOperation and
NSOperationQueue you might consider to send the message to the run loop
instead, e.g.: -performSelector:target:argument:order:modes:
Of course you would need a mechanism to get the corresponding run loop for that
operation. I would suggest to define a property in your custom operation and
set it when the operation enters its main method.
Example for using a run loop in a NSOperation:
- (void) main
{
if ([self isCancelled]) {
return;
}
NSRunLoop* runLoop = [NSRunLoop currentRunLoop];
// Setup the run loop:
// Add sources or timers, or use something like a NSURLConnection running
on top of a run loop.
// In case of a NSURLConnection you would specify self as the delegate of
the NSURLConnection.
// For this contrived example, add a dummy mach port to prevent the run
loop to exit
// prematurely, e.g.:
[runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
_done = NO; // delegate methods would eventually set this to YES, e.g.
when using a NSURLConnection.
while (![self isCancelled] || _done) {
// runMode:beforeDate: will block the thread and will only return after
an input source has
// been processed or after the timeout expired (1 s). Since there in
this example is no
// input source that can be processed, the method returns only after
the timeout expires.
[runLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate
dateWithTimeIntervalSinceNow:1]];
fprintf(stdout, ".");
}
if ([self isCancelled]) {
// perform undo or cleanup:
// ...
[self performSelectorOnMainThread:@selector(didCancel) withObject:nil
waitUntilDone:NO];
} else {
// get the result:
// ...
[self performSelectorOnMainThread:@selector(didFinish) withObject:nil
waitUntilDone:NO];
}
return;
}
(In this example, _delegate has been set to the app delegate which handles the
methods).
- (void) didFinish {
[_delegate runLoopOperationDidFinish:self]; // required
}
- (void) didCancel {
if ([_delegate performSelector:@selector(runLoopOperationCancelled:)]) {
[_delegate runLoopOperationCancelled:self];
}
}
You can cancel the NSOperation by sending it the message -cancel. E.g., the app
delegate sends it in response to a menu action.
Regards,
Andreas
>
> Regards
>
> Jonathan Mitchell
>
> Developer
> Mugginsoft LLP
> http://www.mugginsoft.com
___
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 arch...@mail-archive.com
Re: iPad 4.1 (deploy to 3.2.2) error
Wow I am so sorry I posted to this forum. I thought this was a forum for engineers, but turns out everyone on it is a lawyer. I fat fingered a 2 instead of a 1 in the subject field and ended up with a bunch of emails about legal agreements. btw, if there are any engineers out there who are interested the error message was related to a library dependency that was set to REQUIRED when it needed to be WEAK. Rich Collyer On Nov 10, 2010, at 8:26 PM, Scott Anguish wrote: > As the list Moderator and an Apple Employee, I am obliged to remind users > of/and enforce the NDA. iOS 4.2 hasn’t been released, is under NDA, and can’t > be discussed here. Apple provides the developer forums for discussion of > yet-to-be-released software. > > If you choose not to abide by the NDA or the list requirements that > unreleased software can’t be discussed here, you’ll be moderated. This is my > responsibility. What happens off the list is WWDR and Legal’s responsibility. > > This has been discussed on the list more than necessary. The steps have been > taken to handle this case. > > Thanks everyone for your patience. > > Scott > > ___ > > 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/iseecolors%40sbcglobal.net > > This email sent to iseecol...@sbcglobal.net ___ 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 arch...@mail-archive.com
Re: iPad 4.1 (deploy to 3.2.2) error
On Nov 11, 2010, at 9:39 AM, colors wrote: > Wow I am so sorry I posted to this forum. I thought this was a forum for > engineers, but turns out everyone on it is a lawyer. > > I fat fingered a 2 instead of a 1 in the subject field and ended up with a > bunch of emails about legal agreements. There were two instances of 4.2 (not 4.1) in the body of your first message, in addition to the subject. Steve Bird Culverson Software - Elegant software that is a pleasure to use. www.Culverson.com (toll free) 1-877-676-8175 ___ 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 arch...@mail-archive.com
Re: iPad 4.1 (deploy to 3.2.2) error
On 11 Nov 2010, at 14:50, Steve Bird wrote: > > On Nov 11, 2010, at 9:39 AM, colors wrote: > >> Wow I am so sorry I posted to this forum. I thought this was a forum for >> engineers, but turns out everyone on it is a lawyer. >> >> I fat fingered a 2 instead of a 1 in the subject field and ended up with a >> bunch of emails about legal agreements. > > > There were two instances of 4.2 (not 4.1) in the body of your first message, > in addition to the subject. Not only that, but 4.1 was never released for iPad. Bob___ 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 arch...@mail-archive.com
Re: NSTextView vs NSTextField
> If so and if I am programmatically creating one of these controls, is there > any reason why I would want to use a NSTextField? > (I know that IB uses a NSTextField for Labels, for example...is this just a > historical artifact?) For editing multiple strings it is more efficient to have multiple text fields than multiple text views. An NSTextView represents an entire text system, including an NSLayoutManager. For each editable string, you would create a completely new text system. Text fields share a common text system in the form of a field editor. This is all explained in the Text Editing Programming Guide. ___ 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 arch...@mail-archive.com
Re: sending msgs to nsoperation threads
On 11 Nov 2010, at 14:37, Andreas Grosam wrote: > >> You have to do a bit more management but you get the control you need. > IMHO, using NSOperation/NSOperationQueue is exactly what I consider a higher > level API. It has also additional cool features which give you even more > control where NSThread doesn't provide such things at all. So, for me in many > cases it's much more easier to use NSOperations than implementing the same > thing using NSThread. No doubt about it. NSOperation et al are very powerful > >> >> Also NSOperation generated threads do not, IIRC, instantiate a run loop. > The thread executing an NSOperation scheduled from an NSOperationQueue > already has a run loop :) But of course you need to use it, see example below. What I meant of course was that you cannot access an NSOperation's thread and target it with the assumption that the run loop will be running. But then you cannot access the NSOperation thread in the first place! > >> If you want to message your thread using performSelector:onThread you will >> need a run loop. > In case you would like to do similar things when using NSOperation and > NSOperationQueue you might consider to send the message to the run loop > instead, e.g.: -performSelector:target:argument:order:modes: > > Of course you would need a mechanism to get the corresponding run loop for > that operation. I would suggest to define a property in your custom operation > and set it when the operation enters its main method. > That's a great idea that never occurred to me. I ended up not using NSOperation recently because I could not figure out how to schedule a method. Will definitely use this. Regards Jonathan Mitchell Developer Mugginsoft LLP http://www.mugginsoft.com___ 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 arch...@mail-archive.com
Re: NSTextView vs NSTextField
NSTextField doesn't display or edit text at all. It uses an instance of NSTextView calle dthe "filed editor" to provide all text dispay and editing. So you are right: NSTextFiled cannot do anythingthat NSTextView can't because NSTextField uses NSTextView. NSTextView is a large and heavy weight object. If you research the text subsystem, you will find multiple classes that collaborate to provide text display and editing. NSTextView is just the tip of the ice burg. It is the user visible "View" part of a huge infrastructure that includes "Model" and "Controller" components. It is a big deal to set-up and tear-down the whole infrastructure each time an NSTextField becomes editable. Therefore, all NSTextFields (Actually NSTextFiledCells) share a single NSTextView, the filed editor, per window. As for why not set-up the whole text infrastructure for every label and leave it set up...the best answer is that all of this software worked well on 8MB NeXT Cubes, and not instantiating the entire text system for every field is one reason why. --- On Thu, 11/11/10, Eric Gorr wrote: > From: Eric Gorr > Subject: NSTextView vs NSTextField > To: "Cocoa Dev" > Date: Thursday, November 11, 2010, 8:45 AM > It seems to me that NSTextView can do > everything that NSTextField can and more. For example, on a > NSTextView, one can use the method setHorizontallyResizable: > and then call sizeToFit to get it to resize itself > vertically instead of horizontally. > > Is this correct? > > If so and if I am programmatically creating one of these > controls, is there any reason why I would want to use a > NSTextField? > (I know that IB uses a NSTextField for Labels, for > example...is this just a historical artifact?) > > If not, what are the key differences between them that > would cause me to want to use a NSTextField? Would it > basically come down to whether or not I need more then a > single line of text or not...NSTextField seems to be > optimized for single lines of text, but one can still get > the same behavior out of a NSTextView with a bit more work. > > Now, I know that NSTextFieldCell is commonly used as a > superclass for one's own cell based stuff, but I would > consider that as separate from the issue of NSTextField vs > NSTextView. > > Thank you. > > > > > > ___ > > 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/erik.buck%40sbcglobal.net > > This email sent to erik.b...@sbcglobal.net > ___ 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 arch...@mail-archive.com
Re: NSTextView vs NSTextField
Change Filed to Field where appropriate. Grumble...auto-correct...grumble. --- On Thu, 11/11/10, Erik Buck wrote: > From: Erik Buck > Subject: Re: NSTextView vs NSTextField > To: "Cocoa Dev" , "Eric Gorr" > > Date: Thursday, November 11, 2010, 10:50 AM > NSTextField doesn't display or edit > text at all. It uses an instance of NSTextView calle > dthe "filed editor" to provide all text dispay and > editing. So you are right: NSTextFiled cannot do > anythingthat NSTextView can't because NSTextField uses > NSTextView. > > NSTextView is a large and heavy weight object. If you > research the text subsystem, you will find multiple classes > that collaborate to provide text display and editing. > NSTextView is just the tip of the ice burg. It is the > user visible "View" part of a huge infrastructure that > includes "Model" and "Controller" components. It is a > big deal to set-up and tear-down the whole infrastructure > each time an NSTextField becomes editable. Therefore, > all NSTextFields (Actually NSTextFiledCells) share a single > NSTextView, the filed editor, per window. > > As for why not set-up the whole text infrastructure for > every label and leave it set up...the best answer is that > all of this software worked well on 8MB NeXT Cubes, and not > instantiating the entire text system for every field is one > reason why. > > > --- On Thu, 11/11/10, Eric Gorr > wrote: > > > From: Eric Gorr > > Subject: NSTextView vs NSTextField > > To: "Cocoa Dev" > > Date: Thursday, November 11, 2010, 8:45 AM > > It seems to me that NSTextView can do > > everything that NSTextField can and more. For example, > on a > > NSTextView, one can use the method > setHorizontallyResizable: > > and then call sizeToFit to get it to resize itself > > vertically instead of horizontally. > > > > Is this correct? > > > > If so and if I am programmatically creating one of > these > > controls, is there any reason why I would want to use > a > > NSTextField? > > (I know that IB uses a NSTextField for Labels, for > > example...is this just a historical artifact?) > > > > If not, what are the key differences between them > that > > would cause me to want to use a NSTextField? Would it > > basically come down to whether or not I need more then > a > > single line of text or not...NSTextField seems to be > > optimized for single lines of text, but one can still > get > > the same behavior out of a NSTextView with a bit more > work. > > > > Now, I know that NSTextFieldCell is commonly used as > a > > superclass for one's own cell based stuff, but I > would > > consider that as separate from the issue of > NSTextField vs > > NSTextView. > > > > Thank you. > > > > > > > > > > > > ___ > > > > 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/erik.buck%40sbcglobal.net > > > > This email sent to erik.b...@sbcglobal.net > > > ___ > > 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/erik.buck%40sbcglobal.net > > This email sent to erik.b...@sbcglobal.net > ___ 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 arch...@mail-archive.com
Re: NSTextView vs NSTextField
Thanks for the info (both you and Ross). You may be interested in: http://damnyouautocorrect.com/ On Nov 11, 2010, at 10:54 AM, Erik Buck wrote: > Change Filed to Field where appropriate. Grumble...auto-correct...grumble. > > --- On Thu, 11/11/10, Erik Buck wrote: > >> From: Erik Buck >> Subject: Re: NSTextView vs NSTextField >> To: "Cocoa Dev" , "Eric Gorr" >> >> Date: Thursday, November 11, 2010, 10:50 AM >> NSTextField doesn't display or edit >> text at all. It uses an instance of NSTextView calle >> dthe "filed editor" to provide all text dispay and >> editing. So you are right: NSTextFiled cannot do >> anythingthat NSTextView can't because NSTextField uses >> NSTextView. >> >> NSTextView is a large and heavy weight object. If you >> research the text subsystem, you will find multiple classes >> that collaborate to provide text display and editing. >> NSTextView is just the tip of the ice burg. It is the >> user visible "View" part of a huge infrastructure that >> includes "Model" and "Controller" components. It is a >> big deal to set-up and tear-down the whole infrastructure >> each time an NSTextField becomes editable. Therefore, >> all NSTextFields (Actually NSTextFiledCells) share a single >> NSTextView, the filed editor, per window. >> >> As for why not set-up the whole text infrastructure for >> every label and leave it set up...the best answer is that >> all of this software worked well on 8MB NeXT Cubes, and not >> instantiating the entire text system for every field is one >> reason why. >> >> >> --- On Thu, 11/11/10, Eric Gorr >> wrote: >> >>> From: Eric Gorr >>> Subject: NSTextView vs NSTextField >>> To: "Cocoa Dev" >>> Date: Thursday, November 11, 2010, 8:45 AM >>> It seems to me that NSTextView can do >>> everything that NSTextField can and more. For example, >> on a >>> NSTextView, one can use the method >> setHorizontallyResizable: >>> and then call sizeToFit to get it to resize itself >>> vertically instead of horizontally. >>> >>> Is this correct? >>> >>> If so and if I am programmatically creating one of >> these >>> controls, is there any reason why I would want to use >> a >>> NSTextField? >>> (I know that IB uses a NSTextField for Labels, for >>> example...is this just a historical artifact?) >>> >>> If not, what are the key differences between them >> that >>> would cause me to want to use a NSTextField? Would it >>> basically come down to whether or not I need more then >> a >>> single line of text or not...NSTextField seems to be >>> optimized for single lines of text, but one can still >> get >>> the same behavior out of a NSTextView with a bit more >> work. >>> >>> Now, I know that NSTextFieldCell is commonly used as >> a >>> superclass for one's own cell based stuff, but I >> would >>> consider that as separate from the issue of >> NSTextField vs >>> NSTextView. >>> >>> Thank you. >>> >>> >>> >>> >>> >>> ___ >>> >>> 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/erik.buck%40sbcglobal.net >>> >>> This email sent to erik.b...@sbcglobal.net >>> >> ___ >> >> 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/erik.buck%40sbcglobal.net >> >> This email sent to erik.b...@sbcglobal.net >> ___ 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 arch...@mail-archive.com
Re: Detecting reading a key in KVC
On Nov 11, 2010, at 7:11 AM, Graham Cox wrote: > Just write a wrapper for -setObject:forKey: and -valueForKey: The first just > calls the same method on its (mutable) dictionary, the second can first check > for whether the value is actually present and if not kick off some task to > fetch it, or else just get it from the dictionary and return it. You should not override -setValue:forKey: or -valueForKey: if you can avoid it. Instead, implement the methods -setValue:forUndefinedKey: and -valueForUndefinedKey:. They are precisely for implementing "dynamic" properties in this manner. Regards, Ken ___ 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 arch...@mail-archive.com
Re: NSTableView within NSScrollView in code
On Nov 11, 2010, at 4:29 AM, Patrick Mau wrote: > After all the setup, I add an observer to the NSClipView > that is the scrollvies's contentView. NSTableView already does this exact thing when it is set up properly. There should be no need for you to do this yourself. > > The corresponding setup in IB (TableView in ScrollView, which tracks window > size), > creates a scrollview that has both the documentView and the contentView > pointing to the > identical NSClipView (checked with gdb). This setup can not be done in code, > setting > the documentView changes something in the clipView leading to an exception No, it does not. Otherwise everyone who does this the right way (by using IB) would have broken table views. > > I have created a custom TableColumn, implementing "setWidth:" by just calling > super. If you do so, you can look at the backtrace. > > You'll note that the clipView post a frame change notification, which will > be observed in 'superviewFrameChanged:' in te tableview. This is NSTableView's implementation of the technique you reimplemented above. Please, stop trying to do this in code. There are so many things you have to do to get it right, and doing it in code provides you ZERO advantage. --Kyle Sluder___ 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 arch...@mail-archive.com
Re: NSSecureTextFieldCell detected a field editor ((null))
Somehow NSSecureTextFieldCell is receiving a nil field editor in -selectWithFrame:... or -editWithFrame:. Aki On 2010/11/10, at 10:21, FF wrote: > A NSSecureTextField works fine, but the msg. in the Console after entering > password says: > NSSecureTextFieldCell detected a field editor ((null)) that is not a > NSTextView subclass designed to work with the cell. Ignoring... > > Can anyone help?___ > > 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/aki%40apple.com > > This email sent to a...@apple.com ___ 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 arch...@mail-archive.com
[MEET]: Los Angeles CocoaHeads tonight, 7:30pm
Greetings LA CocoaHeads. Tonight we have our monthly meeting. We don't have a formal presentation planned, but we'll have an informal discussion of recent Apple announcements such as the new Mac App store, upcoming features in 10.7 "Lion", and general Q&A about Mac and iDevice development. (I personally have questions about NSNotificationCenter and NSDistributedNotificationCenter - but hey, who doesn't, am I right? ) See you all Tonight! We meet at the offices of E! Entertainment at 7:30pm. Our meeting location is 5750 Wilshire Blvd Los Angeles, CA 90036. Here's a google map of the location: http://www.google.com/maps?f=q&hl=en&q=5750+Wilshire+Blvd,+Los+Angeles+CA+90036&ie=UTF8&z=15&om=1&iwloc=addr Free street parking is available after 8pm - FEED THE METER UP TO 8PM OR YOU MIGHT GET A TICKET! I'd suggest trying Masselin Ave, which is one block East of Courtyard Place. We meet near the lobby of the West building at 5750 Wilshire Blvd, on the West side of Courtyard Place. There are picknick tables in front of the lobby and we'll gather there starting at 7:20pm. From there we go inside and up to conference room 3G at around 7:45pm . If you arrive late, please ask the building security personnel in the lobby to direct you to the E! Security office, and they will be able to contact the group in conference room 3G and send someone down to meet you. Rob___ 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 arch...@mail-archive.com
Re: sending msgs to nsoperation threads
On Nov 11, 2010, at 4:48 PM, jonat...@mugginsoft.com wrote: >> In case you would like to do similar things when using NSOperation and >> NSOperationQueue you might consider to send the message to the run loop >> instead, e.g.: -performSelector:target:argument:order:modes: >> >> Of course you would need a mechanism to get the corresponding run loop for >> that operation. I would suggest to define a property in your custom >> operation and set it when the operation enters its main method. Unfortunately, after more carefully reading the docs, the method -performSelector:target:argument:order:modes: seems not appropriate for this tasks since it "schedules the sending of a message on the *current* run loop" - which is certainly not what you want :( It seems, the receiver of this message is irrelevant, hence the confusion. But there is still the possibility to ask for the current thread in -main and retain it in the custom operation. You may provide it readonly via a property. Likewise, you could then use -performSelector:onThread:withObject:waitUntilDone* or you could use custom methods for your operation which invoke performSelector:onThread itself. Access to the thread ivar should be synchronized. Be carefully though, the operation may not execute anymore or did not yet start when you try to schedule a selector on its thread. Note also, that many operations may be executed on the same thread. >> > That's a great idea that never occurred to me. I ended up not using > NSOperation recently because I could not figure out how to schedule a method. > Will definitely use this. ___ 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 arch...@mail-archive.com
Re: sending msgs to nsoperation threads
On 11 Nov 2010, at 20:06, Andreas Grosam wrote: > > On Nov 11, 2010, at 4:48 PM, jonat...@mugginsoft.com wrote: > >>> In case you would like to do similar things when using NSOperation and >>> NSOperationQueue you might consider to send the message to the run loop >>> instead, e.g.: -performSelector:target:argument:order:modes: >>> >>> Of course you would need a mechanism to get the corresponding run loop for >>> that operation. I would suggest to define a property in your custom >>> operation and set it when the operation enters its main method. > > Unfortunately, after more carefully reading the docs, the method > -performSelector:target:argument:order:modes: seems not appropriate for this > tasks since it "schedules the sending of a message on the *current* run loop" > - which is certainly not what you want :( It seems, the receiver of this > message is irrelevant, hence the confusion. > Definitely confusing. Would make more sense as a class method. it also says: You should never try to call the methods of an NSRunLoop object running in a different thread, as doing so might cause unexpected results. > But there is still the possibility to ask for the current thread in -main and > retain it in the custom operation. You may provide it readonly via a > property. Likewise, you could then use > -performSelector:onThread:withObject:waitUntilDone* or you could use custom > methods for your operation which invoke performSelector:onThread itself. > Be carefully though, the operation may not execute anymore or did not yet > start when you try to schedule a selector on its thread. Note also, that many > operations may be executed on the same thread. Hmm. I'm not sure that I am convinced of the the case for using NSOperations in situations like this. NSOperation seems designed to insulate the coder from the underlying thread and here we are digging it out. Anyhow, next time runloop based concurrency is on the cards I will wrap it in an NSOperation and see how it goes. Regards Jonathan Mitchell Developer Mugginsoft LLP http://www.mugginsoft.com___ 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 arch...@mail-archive.com
Re: RTFDFromRange returns different data
Thank you Glenn. Me too I thought of a time stamp because I tried to call that function several times with 1 second interval and the data was different by 1, then 2, then 3... I workedaround the problem archiving the data directly from the attributedString this way: NSData* stringData = [NSKeyedArchiver archivedDataWithRootObject:mTextMutableString]; It works like a charm. Thanks. And I think there should always be a way to get the "same" out-data, given the same "in-variables". -- Leo > Da: glenn andreas > Data: Thu, 11 Nov 2010 08:21:18 -0600 > A: "gMail.com" > Cc: > Oggetto: Re: RTFDFromRange returns different data > > > On Nov 11, 2010, at 8:12 AM, gMail.com wrote: > >> RTFDFromRange returns different data even if I do not change the variables >> mTextMutableString nor mDocAttributes. I just call several time: >> >> NSData *textData = [mTextMutableString RTFDFromRange:textRange >> documentAttributes:mDocAttributes]; >> NSLog(@"textData %@", textData); >> >> And 'every time' I get a different textData log text. >> Of course I compare the text starting from < >> >> For example, at any call I get >> (this is the last changing part of the log text) >> 1) edecdb4c b601 > >> 2) 2aebdb4c b601 > >> 3) a6f8db4c b601 > >> 4) bef8db4c b601 > >> >> Why does RTFDFromRange returns a different data, even if the variables >> didn't change? How to get the same data? Is it a bug? > > > > RTFDFromRange returns an archived (flattened) version of RTFD, which is > undocumented but probably includes things like time stamps or unique IDs. So > it is not a bug - archiving the same original data is not guaranteed to return > byte-for-byte identical archived results (but will return the same thing when > unarchived). > > > Glenn Andreas gandr...@gandreas.com > The most merciful thing in the world ... is the inability of the human mind to > correlate all its contents - HPL > ___ 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 arch...@mail-archive.com
Re: Detecting reading a key in KVC
On 12/11/2010, at 3:30 AM, Ken Thomases wrote: > You should not override -setValue:forKey: or -valueForKey: if you can avoid > it. Instead, implement the methods -setValue:forUndefinedKey: and > -valueForUndefinedKey:. They are precisely for implementing "dynamic" > properties in this manner. Understood, but the OP's problem as I understand it is that it's not that the key is undefined, but the value associated with it is uninitialized. So rather than return nil, or zero, he wants to trigger a remote fetch of the value. KVC doesn't appear to provide a mechanism for that out of the box. --Graham ___ 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 arch...@mail-archive.com
Re: Detecting reading a key in KVC
On Thu, Nov 11, 2010 at 2:57 PM, Graham Cox wrote:
> Understood, but the OP's problem as I understand it is that it's not that the
> key is undefined, but the value associated with it is uninitialized. So
> rather than return nil, or zero, he wants to trigger a remote fetch of the
> value. KVC doesn't appear to provide a mechanism for that out of the box.
Nope, it doesn't. We have a very similar need, and solved it using a
custom protocol on our model objects. Now, in places where we are
about to demand an initialized value, we check to see if the model
object conforms to the protocol, and if so call the method that
switches from the uninitialized placeholder "zero" value to the
fully-fleshed object value.
// Typed in compose window, probably doesn't make sense.
@protocol KVOPlaceholder
- (void)needValueForKey:(NSString *)aKey;
@end
- (void)customerOrdered:(CatalogItem *)anItem {
// Because "0" is a valid quantity, this CatalogItem subclass might
need to be told that
// it can initialize its backing store for the "quantity" key now
if ([anItem conformsToProtocol:KVOPlaceholder])
[anItem needValueForKey:@"quantity"];
NSNumber *quantity = [anItem valueForKey:@"quantity"];
quantity = [NSNumber numberWithInteger:[quantity integerValue] - 1];
[anItem setValue:quantity forKey:@"quantity"];
}
--Kyle Sluder
___
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 arch...@mail-archive.com
NSHTTPCookieStorage
Did something recently change with sharedHTTPCookieStorage no longer sharing session cookies? -- Michael___ 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 arch...@mail-archive.com
Re: Detecting reading a key in KVC
On Nov 11, 2010, at 2:57 PM, Graham Cox wrote: > > On 12/11/2010, at 3:30 AM, Ken Thomases wrote: > >> You should not override -setValue:forKey: or -valueForKey: if you can avoid >> it. Instead, implement the methods -setValue:forUndefinedKey: and >> -valueForUndefinedKey:. They are precisely for implementing "dynamic" >> properties in this manner. > > > Understood, but the OP's problem as I understand it is that it's not that the > key is undefined, but the value associated with it is uninitialized. So > rather than return nil, or zero, he wants to trigger a remote fetch of the > value. KVC doesn't appear to provide a mechanism for that out of the box. There's setNilValueForKey: though it's only for scalars.___ 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 arch...@mail-archive.com
Fwd: NSSecureTextFieldCell detected a field editor ((null)) - Solved.
Thanks Aki. The problem vanished after redoing the password panel. Pity that still I don't know the source of the problem : -( Jack. Begin forwarded message: > From: Aki Inoue > Date: November 11, 2010 12:55:58 PM EST > To: FF > Cc: cocoa-dev@lists.apple.com > Subject: Re: NSSecureTextFieldCell detected a field editor ((null)) > > Somehow NSSecureTextFieldCell is receiving a nil field editor in > -selectWithFrame:... or -editWithFrame:. > > Aki > > On 2010/11/10, at 10:21, FF wrote: > >> A NSSecureTextField works fine, but the msg. in the Console after entering >> password says: >> NSSecureTextFieldCell detected a field editor ((null)) that is not a >> NSTextView subclass designed to work with the cell. Ignoring... >> >> Can anyone help?___ >> >> 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/aki%40apple.com >> >> This email sent to a...@apple.com > ___ 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 arch...@mail-archive.com
Re: Detecting reading a key in KVC
On Nov 11, 2010, at 4:57 PM, Graham Cox wrote: > On 12/11/2010, at 3:30 AM, Ken Thomases wrote: > >> You should not override -setValue:forKey: or -valueForKey: if you can avoid >> it. Instead, implement the methods -setValue:forUndefinedKey: and >> -valueForUndefinedKey:. They are precisely for implementing "dynamic" >> properties in this manner. > > Understood, but the OP's problem as I understand it is that it's not that the > key is undefined, but the value associated with it is uninitialized. So > rather than return nil, or zero, he wants to trigger a remote fetch of the > value. KVC doesn't appear to provide a mechanism for that out of the box. He was using an NSMutableDictionary for his model, instead of a custom class. The barrier to using a custom class was that he has many properties and didn't want to implement them all. The suggestion was to make a class which wraps a mutable dictionary and use the KVC methods to provide access to them and also serve as the trigger for retrieving those which are not yet cached. All fine so far. The suggestion, though, was to implement the wrapper by overriding -setValue:forKey: and -valueForKey:. You shouldn't override those, but rather override -setValue:forUndefinedKey: and -valueForUndefinedKey:. The respective implementations would be the same -- they would pass through to the mutable dictionary and initiate fetches for absent values. -setValue:forKey: and -valueForKey: have some "special powers" that you lose if you override them. Regards, Ken ___ 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 arch...@mail-archive.com
Re: NSTextView vs NSTextField
On 12/11/2010, at 12:45 AM, Eric Gorr wrote: > It seems to me that NSTextView can do everything that NSTextField can and > more. For example, on a NSTextView, one can use the method > setHorizontallyResizable: and then call sizeToFit to get it to resize itself > vertically instead of horizontally. > > Is this correct? > > If so and if I am programmatically creating one of these controls, is there > any reason why I would want to use a NSTextField? > (I know that IB uses a NSTextField for Labels, for example...is this just a > historical artifact?) > > If not, what are the key differences between them that would cause me to want > to use a NSTextField? Would it basically come down to whether or not I need > more then a single line of text or not...NSTextField seems to be optimized > for single lines of text, but one can still get the same behavior out of a > NSTextView with a bit more work. > > Now, I know that NSTextFieldCell is commonly used as a superclass for one's > own cell based stuff, but I would consider that as separate from the issue of > NSTextField vs NSTextView. > > Thank you. > One important difference the others forgot to mention is that NSTextField's are a subclass of NSControl. So they can send messages to, for instance, IBAction methods in your code whenever editing ends via a Tab or Enter key. Ron ___ 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 arch...@mail-archive.com
