date:20111006

NSArrayController Selection and Managed Object Context Undo

2011-10-06 Thread Richard Somers

It is very common for Applications to update the selection during undo 
operations.

By default NSArrayController automatically selects objects as they are 
inserted. This works if objects are added using one of the controller's add or 
insert methods. If objects are added directly to the controller content object 
using other means then this mechanism does not work.

Take for example a NSArrayController with a managed object context for the 
content. If one or more objects are added to managed object context as the 
result of an undo, the controller's selection does not change or update.

Is there an easy way to set the controller's selection when an undo operation 
adds objects back into a managed object context?

--Richard

___

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: Writing a simple vector graphics editor - how to implement?

2011-10-06 Thread Nick

Thanks a lot for the advices! Will do it that way
___

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

adding something to a setter

2011-10-06 Thread Torsten Curdt

The property syntax is great until you need one more thing.

Think of a NSView and that view displays a value.

 @synthesize value;

Now you also want to setNeedsDisplay: when a new value is set. So one
can override the setter.

 - (void)setValue:(NSString*)theValue
 {
   ...
   [self setNeedsDisplay:YES];
 }

but - you would have to implement the setter yourself. No big deal -
but... it sucks.
Is there a way to forward the setting to the originally synthesized
setter? Super cannot be it.

Of course one could add another selector that to the interface

  - (void) setValueAndUpdateDisplay:(NSString*)theValue
  {
self.value = theValue;
   [self setNeedsDisplay:YES];
  }

...but that sucks, too.

There gotta be a better way!
How do you deal with this?

cheers,
Torsten
___

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: Windows _findfirst , _findnext (koko)

2011-10-06 Thread Sander Stoks

> Thanks for all the input.  I am doing x-platform development and we like
> to keep mainline code identical so I implemented functions _findfirst and
> _findnext using NSFileManager ... it work s pretty cool as follows:
>
> intptr_t _findfirst(CString search, _finddata_t *data)
> {
>   intptr_t rtx = 0;
>   _breakdown(search);
>   if([results count])
>   {
>   const char* name = [[results objectAtIndex:0]
> cStringUsingEncoding:NSUTF8StringEncoding];
>   strcpy(data->name,name);
>   rtx = 1;
>   }
>   return rtx;
> }
>
> int _findnext(intptr_t& next, _finddata_t *data)
> {
>   int rtx = 0;
>   if(next < [results count])
>   {
>   const char* name = [[results objectAtIndex:next]
> cStringUsingEncoding:NSUTF8StringEncoding];
>   strcpy(data->name,name);
>   next++;
>   }
>   else rtx = 1;
>   return rtx;
> }
>
> void _breakdown(CString search)
> {
>   nssearch = [NSString stringWithCString:(const char*)search
> encoding:NSUTF8StringEncoding];
>   path = [nssearch stringByDeletingLastPathComponent];
>   fileManager = [NSFileManager defaultManager];
>   directoryContents = [fileManager contentsOfDirectoryAtPath:path
> error:&error];
>   lastPathComponent = [nssearch lastPathComponent];
>   predicate = [NSPredicate predicateWithFormat:@"SELF like [c] %@",
> lastPathComponent];
>   results = [directoryContents filteredArrayUsingPredicate:predicate];
> }

The MSDN documentation says that _findfirst returns -1 if it can't find
anything, instead of 0 (your client code may depend on that).  See
http://msdn.microsoft.com/en-us/library/zyzxfzac(v=vs.71).aspx

Also, what does your _finddata_t look like?  If it contains a fixed-size
char array for its "name" member, be aware that the "maximum sensible path
name" is a platform-dependent number.  When I see the unguarded strcpy(),
I'd rather replace it with a strncpy instead.

Also, CString seems like a typedef for char*, but "normally" if it's a
class encapsulating a string (which its name suggests), you can't simply
cast it to a char*.

___

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: adding something to a setter

2011-10-06 Thread Thomas Davie

I don't know of any better way than simply writing the setters yourself.  One 
thing I'd love to see apple add to the language is allowing us to specify a 
code block to be included in setter and getting in the synthesize:

@property (readwrite, retain, nonatomic) NSString *theValue;

@synthesize (setCode={ [self setNeedsDisplay:YES]; }, getCode={ NSLog(@"It's 
being set"); });

would be lovely if it desugared to this in the implementation:

{
NSString *theValue;
}

- (NSString *)theValue
{
{ NSLog(@"It's being set"); }
return [[theValue retain] autorelease];
}

- (void)setTheValue:(NSString *)newTheValue
{
if (theValue != newTheValue)
{
[theValue release];
theValue = [newTheValue retain];
{ [self setNeedsDisplay:YES]; }
}
}

Does anyone have any comments on why that might not work, before I file a bug 
report to request it?

Bob

if (*ra4 != 0xffc78948) { return false; }

On 6 Oct 2011, at 12:28, Torsten Curdt wrote:

> The property syntax is great until you need one more thing.
> 
> Think of a NSView and that view displays a value.
> 
> @synthesize value;
> 
> Now you also want to setNeedsDisplay: when a new value is set. So one
> can override the setter.
> 
> - (void)setValue:(NSString*)theValue
> {
>   ...
>   [self setNeedsDisplay:YES];
> }
> 
> but - you would have to implement the setter yourself. No big deal -
> but... it sucks.
> Is there a way to forward the setting to the originally synthesized
> setter? Super cannot be it.
> 
> Of course one could add another selector that to the interface
> 
>  - (void) setValueAndUpdateDisplay:(NSString*)theValue
>  {
>self.value = theValue;
>   [self setNeedsDisplay:YES];
>  }
> 
> ...but that sucks, too.
> 
> There gotta be a better way!
> How do you deal with this?
> 
> cheers,
> Torsten
> ___
> 
> 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/tom.davie%40gmail.com
> 
> This email sent to tom.da...@gmail.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: adding something to a setter

2011-10-06 Thread Mike Abdullah


On 6 Oct 2011, at 13:09, Thomas Davie wrote:

> I don't know of any better way than simply writing the setters yourself.  One 
> thing I'd love to see apple add to the language is allowing us to specify a 
> code block to be included in setter and getting in the synthesize:
> 
> @property (readwrite, retain, nonatomic) NSString *theValue;
> 
> @synthesize (setCode={ [self setNeedsDisplay:YES]; }, getCode={ NSLog(@"It's 
> being set"); });
> 
> would be lovely if it desugared to this in the implementation:
> 
> {
>NSString *theValue;
> }
> 
> - (NSString *)theValue
> {
>{ NSLog(@"It's being set"); }
>return [[theValue retain] autorelease];
> }
> 
> - (void)setTheValue:(NSString *)newTheValue
> {
>if (theValue != newTheValue)
>{
>[theValue release];
>theValue = [newTheValue retain];
>{ [self setNeedsDisplay:YES]; }
>}
> }
> 
> Does anyone have any comments on why that might not work, before I file a bug 
> report to request it?

Well it would become rather unreadable for anything more than a single line of 
code.___

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: adding something to a setter

2011-10-06 Thread Stephan Michels

I use KVO to execute custom code if a property has changed.

[self addObserver:self forKeyPath:@"graphics" 
options:(NSKeyValueObservingOptionNew|NSKeyValueObservingOptionOld) 
context:self];

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object 
change:(NSDictionary *)change context:(void *)context {
if (context != self) {
[super observeValueForKeyPath:keyPath ofObject:object change:change 
context:context];
}

if ([keyPath isEqualToString:@"graphics"]) {
[self setNeedsDisplay:YES];
}
}

AFAIK the observe method will not be executed instantaneously, but on the other 
side setNeedsDisplay has also a
deferred execution.

Stephan.

Am 06.10.2011 um 13:28 schrieb Torsten Curdt:

> The property syntax is great until you need one more thing.
> 
> Think of a NSView and that view displays a value.
> 
> @synthesize value;
> 
> Now you also want to setNeedsDisplay: when a new value is set. So one
> can override the setter.
> 
> - (void)setValue:(NSString*)theValue
> {
>   ...
>   [self setNeedsDisplay:YES];
> }
> 
> but - you would have to implement the setter yourself. No big deal -
> but... it sucks.
> Is there a way to forward the setting to the originally synthesized
> setter? Super cannot be it.
> 
> Of course one could add another selector that to the interface
> 
>  - (void) setValueAndUpdateDisplay:(NSString*)theValue
>  {
>self.value = theValue;
>   [self setNeedsDisplay:YES];
>  }
> 
> ...but that sucks, too.
> 
> There gotta be a better way!
> How do you deal with 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: adding something to a setter

2011-10-06 Thread Thomas Davie


On 6 Oct 2011, at 13:36, Mike Abdullah wrote:

> 
> On 6 Oct 2011, at 13:09, Thomas Davie wrote:
> 
>> 
>> Does anyone have any comments on why that might not work, before I file a 
>> bug report to request it?
> 
> Well it would become rather unreadable for anything more than a single line 
> of code.

I'm not sure it would be any less readable than code involving blocks tbh.

What's wrong with:

@synthesize (
setCode =
{
[a b];
[c d:e f:g];
[h i];
},
getCode =
{
...
})

Bob

if (*ra4 != 0xffc78948) { return false; 
}___

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: adding something to a setter

2011-10-06 Thread Torsten Curdt

Hm... using KVO for an object to observe it's own properties?
That's feels wrong to me.
Is that just me?

cheers,
Torsten
___

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: adding something to a setter

2011-10-06 Thread Thomas Davie

On 6 Oct 2011, at 14:16, Torsten Curdt wrote:

> Hm... using KVO for an object to observe it's own properties?
> That's feels wrong to me.
> Is that just me?

No, definitely not just you... But then, I find KVO pretty wrong in the first 
place.

if (*ra4 != 0xffc78948) { return false; }

___

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: adding something to a setter

2011-10-06 Thread glenn andreas


On Oct 6, 2011, at 6:28 AM, Torsten Curdt wrote:

> The property syntax is great until you need one more thing.
> 
> Think of a NSView and that view displays a value.
> 
> @synthesize value;
> 
> Now you also want to setNeedsDisplay: when a new value is set. So one
> can override the setter.
> 
> - (void)setValue:(NSString*)theValue
> {
>   ...
>   [self setNeedsDisplay:YES];
> }
> 
> but - you would have to implement the setter yourself. No big deal -
> but... it sucks.
> Is there a way to forward the setting to the originally synthesized
> setter? Super cannot be it.
> 
> Of course one could add another selector that to the interface
> 
>  - (void) setValueAndUpdateDisplay:(NSString*)theValue
>  {
>self.value = theValue;
>   [self setNeedsDisplay:YES];
>  }
> 
> ...but that sucks, too.
> 
> There gotta be a better way!
> How do you deal with this?


In your .m file, inside either the class extension or an "internal use only" 
class category, declare:

@property (nonatomic, retain) NSString *sideEffectFreeValue;  // or whatever 
property specifier were on the original property

and then synthesize it to use the original ivar

@synthesize sideEffectFreeValue=value;

and change your setter to:

- (void) setValue: (NSString *) value
{
self.sideEffectFreeValue = value;
[self setNeedDisplay: YES];
}


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: adding something to a setter

2011-10-06 Thread Peter

But probably that bad feeling is self-inflicted ...

At least for standard views or controls, if there is a need to redisplay, the 
property in question should probably belong to a model object not a view 
object. And in that case your object would not observe its *own* property but a 
property of the model object - and this observation then would trigger a 
display refresh. MVC+KVO.

I hope I am not too wide off the mark.

Am 06.10.2011 um 15:23 schrieb Thomas Davie:

> 
> On 6 Oct 2011, at 14:16, Torsten Curdt wrote:
> 
>> Hm... using KVO for an object to observe it's own properties?
>> That's feels wrong to me.
>> Is that just me?
> 
> No, definitely not just you... But then, I find KVO pretty wrong in the first 
> place.
> 
> if (*ra4 != 0xffc78948) { return false; }
> 
> ___
> 
> 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/magnard%40web.de
> 
> This email sent to magn...@web.de
> 

___

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

NSPrintInfo and NSPageLayout

2011-10-06 Thread Torsten Curdt

So I have a custom view and I am adding printing support. I've set it
up like this:

 https://gist.github.com/919d845b2e1b5becbaac

where I create a custom instance of my view, setup the NSPrintInfo and
then run the NSPrintOperation.

Now there are a couple of things I couldn't quite figure out yet.

1) Currently I set the width of the view to the page size width minus
the left and right margin. Frankly speaking I have no clue if that is
the right thing to do. Or is imageablePageBounds the one to use?

2) When I configure the page layout with [[NSPageLayout pageLayout]
runModal] the layout settings don't make it over to my print dialog.
For example I tried to change the orientation but when I get the print
dialog it's still in portrait. It's not that surprising as I don't see
the connection between the two yet - but how do I make the connection?

cheers,
Torsten
___

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: adding something to a setter

2011-10-06 Thread Torsten Curdt

Well, if the model is more complex and you bind the view to the model
you can of course trigger the re-display on the observed changes. But
what about a simple title property of e.g. a NSButton?

...and I guess triggering a re-display is not the only use case for
this "setter extension" - or whatever you want to call it.

cheers,
Torsten

On Thu, Oct 6, 2011 at 3:32 PM, Peter  wrote:
> But probably that bad feeling is self-inflicted ...
>
> At least for standard views or controls, if there is a need to redisplay, the 
> property in question should probably belong to a model object not a view 
> object. And in that case your object would not observe its *own* property but 
> a property of the model object - and this observation then would trigger a 
> display refresh. MVC+KVO.
>
> I hope I am not too wide off the mark.
>
> Am 06.10.2011 um 15:23 schrieb Thomas Davie:
>
>>
>> On 6 Oct 2011, at 14:16, Torsten Curdt wrote:
>>
>>> Hm... using KVO for an object to observe it's own properties?
>>> That's feels wrong to me.
>>> Is that just me?
>>
>> No, definitely not just you... But then, I find KVO pretty wrong in the 
>> first place.
>>
>> if (*ra4 != 0xffc78948) { return false; }
>>
>> ___
>>
>> 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/magnard%40web.de
>>
>> This email sent to magn...@web.de
>>
>
> ___
>
> 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/tcurdt%40vafer.org
>
> This email sent to tcu...@vafer.org
>
___

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: adding something to a setter

2011-10-06 Thread Stephan Michels


Am 06.10.2011 um 15:54 schrieb Torsten Curdt:

> Well, if the model is more complex and you bind the view to the model
> you can of course trigger the re-display on the observed changes. But
> what about a simple title property of e.g. a NSButton?
> 
> ...and I guess triggering a re-display is not the only use case for
> this "setter extension" - or whatever you want to call it.

I never implement setters/getters for myself. I find it error-prone and it 
feels wrong to me.

To give you another example. I use KVO to generate background images
in UIButton

[self addObserver:self forKeyPath:@"color" options:NSKeyValueObservingOptionNew 
| NSKeyValueObservingOptionOld | NSKeyValueObservingOptionInitial context:NULL];
[self addObserver:self forKeyPath:@"size" options:NSKeyValueObservingOptionNew 
| NSKeyValueObservingOptionOld | NSKeyValueObservingOptionInitial context:NULL];
[self addObserver:self forKeyPath:@"showShadow" 
options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld | 
NSKeyValueObservingOptionInitial context:NULL];

- (void)observeValueForKeyPath:(NSString *)keyPath
  ofObject:(id)object
change:(NSDictionary *)change
   context:(void *)context {
if (![change keyValueChanged]) {
return;
}

if([keyPath isEqualToString:@"color"] ||
   [keyPath isEqualToString:@"size"] ||
   [keyPath isEqualToString:@"showShadow"]) {
[self setBackgroundImage:[HDEButton 
backgroundImageForButtonWithColor:self.color size:self.size] 
forState:UIControlStateNormal];
[self setBackgroundImage:[HDEButton 
backgroundImageForButtonWithColor:HDEGrayBackgroundColor size:self.size] 
forState:UIControlStateDisabled];
[...]

Self observing works great for 
me.___

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: NSArrayController Selection and Managed Object Context Undo

2011-10-06 Thread Keary Suska

On Oct 6, 2011, at 1:14 AM, Richard Somers wrote:

> It is very common for Applications to update the selection during undo 
> operations.
> 
> By default NSArrayController automatically selects objects as they are 
> inserted. This works if objects are added using one of the controller's add 
> or insert methods. If objects are added directly to the controller content 
> object using other means then this mechanism does not work.
> 
> Take for example a NSArrayController with a managed object context for the 
> content. If one or more objects are added to managed object context as the 
> result of an undo, the controller's selection does not change or update.
> 
> Is there an easy way to set the controller's selection when an undo operation 
> adds objects back into a managed object context?

AFAIK you will need to manage selection restoration semantics yourself, and it 
may not be easy and it may be fragile. Note also that the preserve and avoid 
empty selection settings will also have an effect. That being said, the 
approach would be--before adding/deleting outside the controller--to grab the 
managed object context's undo manager, open an undo group, add selection 
restoration operations, perform the operation, then close the group. This 
should cause the undo to restore selection. Of course, this is theory, as I 
haven't had to actually do it, and more experienced Core Data wranglers may 
have more to add.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

___

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: adding something to a setter

2011-10-06 Thread Andy Lee

On Oct 6, 2011, at 9:16 AM, Torsten Curdt wrote:
> Hm... using KVO for an object to observe it's own properties?
> That's feels wrong to me.
> Is that just me?

You could factor the observing out into a separate object.

I'm just rattling this idea off the top of my head, so it might be flawed (if 
not outright nuts), but... you could have a class called MyDisplayTickler with 
a global shared instance. It observes a fake view property called 
myNeedsDisplay.

Here is a totally untested MyDisplayTickler class, plus a category on NSView:

With these in place, your view class does three trivial things:

* In its init, it does [[MyDisplayTickler sharedInstance] 
startObservingView:self].

* In its dealloc, it does [[MyDisplayTickler sharedInstance] 
stopObservingView:self].

* It implements +propertiesThatTriggerDisplay, something like this:

+ (NSArray *)propertiesThatTriggerDisplay
{
return [NSArray arrayWithObjects:
@"titleColor",
@"fontForHighScore",
@"selectedShape",  // etc.
nil];
}

What do you all think? I've run into the problem Torsten describes and would 
like to think there's *some* better solution than writing setters.

--Andy

___

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: adding something to a setter

2011-10-06 Thread Mike Abdullah


On 6 Oct 2011, at 15:23, Stephan Michels wrote:

> 
> Am 06.10.2011 um 15:54 schrieb Torsten Curdt:
> 
>> Well, if the model is more complex and you bind the view to the model
>> you can of course trigger the re-display on the observed changes. But
>> what about a simple title property of e.g. a NSButton?
>> 
>> ...and I guess triggering a re-display is not the only use case for
>> this "setter extension" - or whatever you want to call it.
> 
> I never implement setters/getters for myself. I find it error-prone and it 
> feels wrong to me.
> 
> To give you another example. I use KVO to generate background images
> in UIButton
> 
> [self addObserver:self forKeyPath:@"color" 
> options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld | 
> NSKeyValueObservingOptionInitial context:NULL];
> [self addObserver:self forKeyPath:@"size" 
> options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld | 
> NSKeyValueObservingOptionInitial context:NULL];
> [self addObserver:self forKeyPath:@"showShadow" 
> options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld | 
> NSKeyValueObservingOptionInitial context:NULL];
> 
> - (void)observeValueForKeyPath:(NSString *)keyPath
>  ofObject:(id)object
>change:(NSDictionary *)change
>   context:(void *)context {
>if (![change keyValueChanged]) {
>return;
>}
>   
>if([keyPath isEqualToString:@"color"] ||
>   [keyPath isEqualToString:@"size"] ||
>   [keyPath isEqualToString:@"showShadow"]) {
>[self setBackgroundImage:[HDEButton 
> backgroundImageForButtonWithColor:self.color size:self.size] 
> forState:UIControlStateNormal];
>[self setBackgroundImage:[HDEButton 
> backgroundImageForButtonWithColor:HDEGrayBackgroundColor size:self.size] 
> forState:UIControlStateDisabled];
> [...]
> 
> Self observing works great for me.

Note that you should really pass in a context pointer and test that in the 
-observe… method, rather than testing the key paths. Call super for all other 
key paths.

___

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: adding something to a setter

2011-10-06 Thread Andy Lee

On Oct 6, 2011, at 10:55 AM, Andy Lee wrote:
> It observes a fake view property called myNeedsDisplay.
> 
> Here is a totally untested MyDisplayTickler class, plus a category on NSView:
> 
> 

Oops, in my code I called the fake property "needsTickle", not 
"myNeedsDisplay". It compiles, but again I haven't tested it.

--Andy

___

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: adding something to a setter

2011-10-06 Thread Andy Lee

On Oct 6, 2011, at 10:57 AM, Mike Abdullah wrote:
> Note that you should really pass in a context pointer and test that in the 
> -observe… method, rather than testing the key paths. Call super for all other 
> key paths.

Ah, right. I've updated my gist accordingly.

--Andy


___

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

How to blink with a focus ring of the text box?

2011-10-06 Thread Nick

Hello
I am wondering if there's a way to do this, notifying the user that he can't
enter any more text into NSTextField edit box?
Is there a way to change the color of the NSTextField's focus ring to red
(to highlight that this is an error)?
How difficult would that be to implement?
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

Re: How to blink with a focus ring of the text box?

2011-10-06 Thread Thomas Davie

The correct way to notify a user that he can't enter text in a text box is to 
disabled it.

Bob
if (*ra4 != 0xffc78948) { return false; }

On 6 Oct 2011, at 16:33, Nick wrote:

> Hello
> I am wondering if there's a way to do this, notifying the user that he can't
> enter any more text into NSTextField edit box?
> Is there a way to change the color of the NSTextField's focus ring to red
> (to highlight that this is an error)?
> How difficult would that be to implement?
> 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/tom.davie%40gmail.com
> 
> This email sent to tom.da...@gmail.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: How to blink with a focus ring of the text box?

2011-10-06 Thread Peter

Read carefully:

The original poster stated: "any more text" - or are you suggesting that he 
should disable the text box when a certain number of characters are reached? I 
guess not.

AFAIK, the focus ring is not accessible programmatically, except form setting 
it by making something the first responder.

You could use a text formatter or one of the validation methods and simply stop 
accepting key strokes, change the text color to red and/or display an alert.

Am 06.10.2011 um 17:43 schrieb Thomas Davie:

> The correct way to notify a user that he can't enter text in a text box is to 
> disabled it.
> 
> Bob
> if (*ra4 != 0xffc78948) { return false; }
> 
> On 6 Oct 2011, at 16:33, Nick wrote:
> 
>> Hello
>> I am wondering if there's a way to do this, notifying the user that he can't
>> enter any more text into NSTextField edit box?
>> Is there a way to change the color of the NSTextField's focus ring to red
>> (to highlight that this is an error)?
>> How difficult would that be to implement?
>> 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/tom.davie%40gmail.com
>> 
>> This email sent to tom.da...@gmail.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/magnard%40web.de
> 
> This email sent to magn...@web.de
> 

___

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: How to blink with a focus ring of the text box?

2011-10-06 Thread Gary L. Wade

I'm guessing you're wanting this for invalid characters as well as exceeded 
number of characters? It sounds like an intriguing extension to the UI. It 
might be easier to flash a red translucent overlay on the field contents 
instead.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

On Oct 6, 2011, at 8:33 AM, Nick  wrote:

> Hello
> I am wondering if there's a way to do this, notifying the user that he can't
> enter any more text into NSTextField edit box?
> Is there a way to change the color of the NSTextField's focus ring to red
> (to highlight that this is an error)?
> How difficult would that be to implement?
> 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

Re: How to blink with a focus ring of the text box?

2011-10-06 Thread Peter

Adding to my own post I just found this in my snippets collection:

This listing shows how you draw such a focus ring. It requires you to override 
the NSCell drawWithFrame:inView: In this method, if the cell is supposed to 
draw evidence of first-responder status, set the rectangle for the focus ring, 
call NSSetFocusRingStyle with an argument of NSFocusRingOnly, and then create 
and fill a bezier path defining that rectangle. Filling in this case simply 
draws the ring.

- (void)drawWithFrame:(NSRect)cellFrame inView:(NSView *)controlView;
{
// other stuff might happen here
if ([self showsFirstResponder]) {
 // showsFirstResponder is set for us by the NSControl that is drawing  
us.
NSRect focusRingFrame = cellFrame;
focusRingFrame.size.height -= 2.0f;
[NSGraphicsContextsaveGraphicsState];
NSSetFocusRingStyle(NSFocusRingOnly);
[[NSBezierPath bezierPathWithRect: NSInsetRect(focusRingFrame, 4.0f, 
4.0f)] fill];
[NSGraphicsContext restoreGraphicsState];
}
// other stuff might happen here
}

So possibly you could create your own NSTextFieldCell, set your NSTextField to 
use it, call [super drawWithFrame.] somewhere in the above method to do the 
standard drawing and move on from there. The flashing could be implemented 
using a CALayer animation or something.

If you manage to implement this you should make it open source :-) since I 
guess it's quite a bit of work to get it done.

> Read carefully:
> 
> The original poster stated: "any more text" - or are you suggesting that he 
> should disable the text box when a certain number of characters are reached? 
> I guess not.
> 
> AFAIK, the focus ring is not accessible programmatically, except form setting 
> it by making something the first responder.
> 
> You could use a text formatter or one of the validation methods and simply 
> stop accepting key strokes, change the text color to red and/or display an 
> alert.
> 
> Am 06.10.2011 um 17:43 schrieb Thomas Davie:
> 
>> The correct way to notify a user that he can't enter text in a text box is 
>> to disabled it.
>> 
>> Bob
>> if (*ra4 != 0xffc78948) { return false; }
>> 
>> On 6 Oct 2011, at 16:33, Nick wrote:
>> 
>>> Hello
>>> I am wondering if there's a way to do this, notifying the user that he can't
>>> enter any more text into NSTextField edit box?
>>> Is there a way to change the color of the NSTextField's focus ring to red
>>> (to highlight that this is an error)?
>>> How difficult would that be to implement?
>>> 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/tom.davie%40gmail.com
>>> 
>>> This email sent to tom.da...@gmail.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: How to blink with a focus ring of the text box?

2011-10-06 Thread Kyle Sluder

On Oct 6, 2011, at 8:54 AM, "Gary L. Wade"  wrote:

> I'm guessing you're wanting this for invalid characters as well as exceeded 
> number of characters? It sounds like an intriguing extension to the UI. It 
> might be easier to flash a red translucent overlay on the field contents 
> instead.

I don't know about the red overlay, but I agree that it's a very intriguing 
extension to the UI.

As suggested, you could use a custom formatter to reject strings over a certain 
length. That will do the expected thing and play the bonk! sound effect when 
the user tries to enter too much text.

But you should definitely file a radar asking for that flash behavior. That 
sounds like a promising line of investigation. Plus we could really stand to 
get access to the focus ring.

--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: How to blink with a focus ring of the text box?

2011-10-06 Thread Scott Ribe

On Oct 6, 2011, at 9:54 AM, Gary L. Wade wrote:

> I'm guessing you're wanting this for invalid characters as well as exceeded 
> number of characters? It sounds like an intriguing extension to the UI. It 
> might be easier to flash a red translucent overlay on the field contents 
> instead.

Or some little red arrow icon next to it, as on some web sites. Or if on Lion, 
a popover attached to the text field with an explanation of the error. Or a 
small label underneath showing a count of remaining characters, that turns red 
once the length goes over. 

The last one is something that I've actually used. I like it because it allows 
the user to enter what he's thinking without interruption, then edit it until 
it fits. "Banging into the end" and not being able to enter more, going back 
and deleting a few characters, then going to the end and typing a few more, and 
repeating until you figure out an abbreviated form that fits is much more 
tedious.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice

___

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: How to blink with a focus ring of the text box?

2011-10-06 Thread Lee Ann Rucker

On Oct 6, 2011, at 9:12 AM, Scott Ribe wrote:

> On Oct 6, 2011, at 9:54 AM, Gary L. Wade wrote:
> 
>> I'm guessing you're wanting this for invalid characters as well as exceeded 
>> number of characters? It sounds like an intriguing extension to the UI. It 
>> might be easier to flash a red translucent overlay on the field contents 
>> instead.
> 
> Or some little red arrow icon next to it, as on some web sites. 

NSImageNameInvalidDataFreestandingTemplate, with red applied to it. Has the 
advantage of not relying entirely on color to distinguish it; changing the blue 
focus ring to another color may not be something all users can detect.
___

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: NSArrayController Selection and Managed Object Context Undo

2011-10-06 Thread Quincey Morris

On Oct 6, 2011, at 07:40 , Keary Suska wrote:

> AFAIK you will need to manage selection restoration semantics yourself, and 
> it may not be easy and it may be fragile. Note also that the preserve and 
> avoid empty selection settings will also have an effect. That being said, the 
> approach would be--before adding/deleting outside the controller--to grab the 
> managed object context's undo manager, open an undo group, add selection 
> restoration operations, perform the operation, then close the group. This 
> should cause the undo to restore selection. Of course, this is theory, as I 
> haven't had to actually do it, and more experienced Core Data wranglers may 
> have more to add.

I think your approach is basically correct. I can't remember if I ever needed 
to do this in a Core Data app, so I'm speaking a bit theoretically too.

On Oct 6, 2011, at 1:14 AM, Richard Somers wrote:

> Take for example a NSArrayController with a managed object context for the 
> content. If one or more objects are added to managed object context as the 
> result of an undo, the controller's selection does not change or update.
> 
> Is there an easy way to set the controller's selection when an undo operation 
> adds objects back into a managed object context?

The most important thing to keep in mind here is that the array controller is a 
distraction, and not any part of the problem. Bind the array controller's 
"selectionIndexes" binding to a NSIndexSet property in your data model, and the 
array controller's selection behavior essentially becomes a proxy for the data 
model property -- provided that any changes you make directly to the property 
are done KVO-compliantly. By moving the selection into the data model (so to 
speak), you remove the array controller from the problem, and that's a good 
thing.

By "data model" I don't necessarily mean "Core Data model". I think it's 
perfectly fine to keep the selectionIndexes property as a custom non-Core-Data 
property of some object (for example, your NSPersistentDocument subclass or 
your document window controller subclass, if that's the kind of app we're 
talking about). You would have to modify every the action method of *every* 
undoable action to create an undo action [sorry, that's 3 semantically 
different uses of "action" in one sentence, but blame Cocoa, not me] that 
captures the selectionIndexes property value, if the action changes the 
selection.

I don't think you need to create any explicit undo groups. The event-level 
implicit group is probably all you need.

I also don't think this is fragile, though it may be. Because Core Data defers 
some processing (such as delete rule propagation) until it "needs" to do it, 
you may find the sequence of activities being more or less re-ordered, and that 
*might* mean trouble when you come to apply the undo actions.

So, as Keary says, "it may not be easy and it may be fragile". However, there 
is a possible alternative that should be easy and non-fragile, if feasible. You 
should be able to put the selectionIndexes property into your Core Data model, 
though you might need to introduce an object of a new entity type into your 
Core Data model to hold the property. (Note: you can make the property 
transient, so that although the object will get saved in the persistent store, 
the property value won't, and selection changes shouldn't "dirty" your model. 
Or you can intervene at save time to prevent the object being saved. Or you can 
really save the selection status in the persistent store, if that makes sense 
for your app.)

Under these circumstances, I think you'll get your selection undone and redone 
for free, simply by binding the array controller to the relevant Core Data 
property. There might be a fatal flaw in my reasoning here, and there may still 
be some difficulty about when the selection change happens relative to the 
insertion/deletion, but this is the approach I'd try if I had to solve your 
problem.

___

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

Why doesn't UIViewController retain its UISearchDisplayController

2011-10-06 Thread Heath Borders

In the UIViewController documentation about the
searchDisplayController property [1] it says:

If you create your search display controller programmatically, this
property is set automatically by the search display controller when it
is initialized.

And when I create my UISearchDisplayController thusly:

[[[UISearchDisplayController alloc] initWithSearchBar:searchBar
contentsController:self] autorelease];

-[UIViewController searchDisplayController] is not nil. However, it is
nilled out after the event loop finishes, which causes the search
display controller not to show when I touch inside the search bar.
Nothing crashes. This is very weird. If I omit the call to
autorelease, everything works:

[[UISearchDisplayController alloc] initWithSearchBar:searchBar
contentsController:self];

However, leaks the UISearchDisplayController (I verified this with
Instruments). Since the searchDisplayController property is marked as
(nonatomic, retain, readonly) I expect that it would retain the
UISearchDisplayController after it is set.

This stackoverflow article [2] is related.  I cross-posted this
question on stackoverflow. [3]

[1] 
http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIViewController_Class/Reference/Reference.html#//apple_ref/occ/instp/UIViewController/searchDisplayController
[2] http://stackoverflow.com/q/2395272/9636
[3]


-Heath Borders
heath.bord...@gmail.com
Twitter: heathborders
http://heath-tech.blogspot.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: adding something to a setter

2011-10-06 Thread Quincey Morris

On Oct 6, 2011, at 04:28 , Torsten Curdt wrote:

> Now you also want to setNeedsDisplay: when a new value is set. So one
> can override the setter.
> 
> - (void)setValue:(NSString*)theValue
> {
>   ...
>   [self setNeedsDisplay:YES];
> }
> 
> but - you would have to implement the setter yourself. No big deal -
> but... it sucks.

I think it really doesn't suck. You've just been lucky enough so far to be able 
to ride around on synthesized setters, so an override feels bad. Get over it 
already!

The only part of a setter override that perhaps hurts (other than having to 
type a few extra keystrokes) is that you lose access to the lightweight 
implementation of the "atomic" attribute. It's easy to obsess about that too, 
but the class of thread synchronization problems that atomicity actually 
solves, compared to the class of synchronization problems that need a 
higher-level strategy, is so small that it's not worth avoiding setters only 
for this reason.

By all means use self-observation if that solves your problem. There's 
absolutely nothing wrong with it, so any negative feelings you might have are 
just another perceptual problem. Note, however, that because the observer 
mechanism is so clunky, you're going to write *more* lines of code this way 
than in overriding the setter, yet all it buys you is the unwanted/unnecessary 
"atomic" implementation.

FWIW.

___

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: Strange mystery with Core Animation

2011-10-06 Thread Seth Willits

On Oct 4, 2011, at 10:20 PM, Seth Willits wrote:

>> Can anyone offer any explanation for this? 
> 
> Hmm. That would be an interesting one to play with if you can replicate it in 
> a new project. The weirdest one I've come across is the CALayer convertPoint 
> methods actually break CATransactions (sometimes).

Which I've just confirmed is fixed in 10.7 btw. It was broken in 10.6 and my 
test project was still linking against the 10.6 SDK so it continued to be 
broken on 10.7 when I tested it. Oops. 

Not that this has anything to with what you asked, but I thought I'd mention it 
incase someone reads this in the archives.

--
Seth Willits

___

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: Codesign non-AppStore build with AppStore signing identity

2011-10-06 Thread Charles Srstka

On Oct 5, 2011, at 1:15 PM, Trygve Inda wrote:

> One of our apps (distributed via our website) is not signed. It seems that
> Parental Controls signs our app behind our back to do what it does.
> 
> This obviously alters our app and breaks some integrity checks.
> 
> A Tech Note says that simply signing it will fix this.
> 
> Can we just sign it the same way we do the version built for the App Store,
> using the same digital signature?

Passing an App Store certificate as an argument to the codesign tool seems to 
work over here.

Perhaps an Apple employee will chime in as to whether or not this is something 
endorsed by Apple, but I don’t see why it wouldn’t be, as the purpose of code 
signing is to prove that the app came from you and not an imposter, and this 
obviously works better if the cert comes from an official source (like Apple).

Charles___

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: How to blink with a focus ring of the text box?

2011-10-06 Thread Quincey Morris

On Oct 6, 2011, at 08:33 , Nick wrote:

> Is there a way to change the color of the NSTextField's focus ring to red
> (to highlight that this is an error)?

I think this sounds like a *terrible* idea. Not because it's a terrible idea, 
but because introducing yet another subtle[-ish] sound/flash/color behavior 
whose meaning isn't obvious into the UI is a terrible idea.

Apart from the problem of foisting yet another arbitrary UI convention on the 
user, the use of color alone to indicate status is not a great idea, and the 
use of red to signal an error is culturally specific and so possible 
off-putting in some parts of the world (though the boat may have already sailed 
on that last issue).

I think the 'NSImageNameInvalidDataFreestandingTemplate' solution, associated 
with label text that explains why the icon is there, is an excellent way to 
show the error, without introducing any new UI behaviors.

> I am wondering if there's a way to do this, notifying the user that he can't
> enter any more text into NSTextField edit box?

I think you're making a mistake in assuming it's a good idea to prevent the 
user from entering the excess text. In many scenarios, it's probably better to 
go ahead and let the user enter any amount of text, and complain afterwards. 
You can show an error condition as described above, or (if, say, your window 
doesn't have room for the entire error description), you can put up an alert 
sheet (when enter is pressed) that says what's wrong and what the limits are.

OTOH, if this is something where the user is very aware of the length 
limitation (for example, the 4-digit passcode used to unlock an iPhone), I'd be 
inclined to just reject the excess text and beep (perhaps with a temporary 
error status message if there's room for it in the UI, perhaps changing the 
color of something in the UI, though not necessarily the text field). 

FWIW.

___

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: Strange mystery with Core Animation

2011-10-06 Thread Kyle Sluder

On Thu, Oct 6, 2011 at 12:47 PM, Seth Willits  wrote:
>> Hmm. That would be an interesting one to play with if you can replicate it 
>> in a new project. The weirdest one I've come across is the CALayer 
>> convertPoint methods actually break CATransactions (sometimes).
>
>
> Which I've just confirmed is fixed in 10.7 btw. It was broken in 10.6 and my 
> test project was still linking against the 10.6 SDK so it continued to be 
> broken on 10.7 when I tested it. Oops.

Mind elaborating on this? We have at least one application out right
now that relies heavily on Core Animation and supports 10.6.

--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: adding something to a setter

2011-10-06 Thread Kyle Sluder

On Thu, Oct 6, 2011 at 12:33 PM, Quincey Morris
 wrote:
> By all means use self-observation if that solves your problem. There's 
> absolutely nothing wrong with it, so any negative feelings you might have are 
> just another perceptual problem. Note, however, that because the observer 
> mechanism is so clunky, you're going to write *more* lines of code this way 
> than in overriding the setter, yet all it buys you is the 
> unwanted/unnecessary "atomic" implementation.

Not necessarily. If you expect subclasses to add properties that
require poking -setNeedsDisplay:, or you just have a lot of them, it's
probably worth adding a class method like +keyPathsRequiringRedisplay,
register as self-observers for all these keypaths, and provide a
really simple implementation of -observeValueForKeyPath:… that calls
[self setNeedsDisplay].

As far as "unwanted/unnecessary 'atomic'" is concerned, don't get me
started. That design mistake is going to haunt us forever.

--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: Strange mystery with Core Animation

2011-10-06 Thread Seth Willits

On Oct 6, 2011, at 1:06 PM, Kyle Sluder wrote:

> On Thu, Oct 6, 2011 at 12:47 PM, Seth Willits  wrote:
>>> Hmm. That would be an interesting one to play with if you can replicate it 
>>> in a new project. The weirdest one I've come across is the CALayer 
>>> convertPoint methods actually break CATransactions (sometimes).
>> 
>> 
>> Which I've just confirmed is fixed in 10.7 btw. It was broken in 10.6 and my 
>> test project was still linking against the 10.6 SDK so it continued to be 
>> broken on 10.7 when I tested it. Oops.
> 
> Mind elaborating on this? We have at least one application out right
> now that relies heavily on Core Animation and supports 10.6.



Bug report along with project and demo movie:

http://www.sethwillits.com/temp/CAConvertPointBug.zip


--
Seth Willits



___

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

Adding "Import" to a document based application

2011-10-06 Thread Jeff Smith



Hi,

I want to add "Import" to a document based application but wasn't quite sure if 
I was going about it right.

I was going to override runModalOpenPanel:forTypes to set forTypes to the 
import types and invoke URLsFromRunningOpenPanel.  A flag would be set so 
runModalOpenPanel:forTypes would know if it was being called from 
openDocument:sender or my Import command.

Does that sound right or is there a better way?

thanks
Jeff




 
___

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: adding something to a setter

2011-10-06 Thread Andy Lee

On Oct 6, 2011, at 4:12 PM, Kyle Sluder wrote:
> On Thu, Oct 6, 2011 at 12:33 PM, Quincey Morris
>  wrote:
[...]
>> Note, however, that because the observer mechanism is so clunky, you're 
>> going to write *more* lines of code this way than in overriding the setter, 
>> yet all it buys you is the unwanted/unnecessary "atomic" implementation.
> 
> Not necessarily. If you expect subclasses to add properties that
> require poking -setNeedsDisplay:, or you just have a lot of them, it's
> probably worth adding a class method like +keyPathsRequiringRedisplay,
> register as self-observers for all these keypaths, and provide a
> really simple implementation of -observeValueForKeyPath:… that calls
> [self setNeedsDisplay].

This is what the code I dashed off this morning does (or at least intends to 
do), except it puts the clunky KVO code into a separate convenience class that 
you can drop into any project.

I just now cleaned up some silly mistakes and stole Kyle's 
"keyPathsRequiringRedisplay" name, though it still isn't perfect (see the 
description) and totally untested.

--Andy

___

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: adding something to a setter

2011-10-06 Thread Torsten Curdt

> I think it really doesn't suck. You've just been lucky enough so far to be
> able to ride around on synthesized setters, so an override feels bad. Get
> over it already!

Just because I can now synthesize setters doesn't make it suck less.
Over it or under it ;)

The intend of this mail was not to bitch though, instead to see if
there was something I have missed. Looks like I didn't...

> The only part of a setter override that perhaps hurts (other than having to
> type a few extra keystrokes) is that you lose access to the lightweight
> implementation of the "atomic" attribute. It's easy to obsess about that
> too, but the class of thread synchronization problems that atomicity
> actually solves, compared to the class of synchronization problems that need
> a higher-level strategy, is so small that it's not worth avoiding setters
> only for this reason.

While I agree that this is not a big deal in practice, I am sure you'd
agree that it would be indeed nice if we could somehow call out to the
synthesized setters. I don't have so deep insights into the Obj-C
runtime but I was wondering if there is some magic one can pull off to
get to the original setters.

cheers,
Torsten
___

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: adding something to a setter

2011-10-06 Thread Charles Srstka

On Oct 6, 2011, at 5:34 PM, Torsten Curdt wrote:

> While I agree that this is not a big deal in practice, I am sure you'd
> agree that it would be indeed nice if we could somehow call out to the
> synthesized setters. I don't have so deep insights into the Obj-C
> runtime but I was wondering if there is some magic one can pull off to
> get to the original setters.

You could probably do that via method swizzling, but either using a private 
property or using KVO would probably be a lot less clunky.

Charles___

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: adding something to a setter

2011-10-06 Thread Quincey Morris

On Oct 6, 2011, at 15:34 , Torsten Curdt wrote:

> While I agree that this is not a big deal in practice, I am sure you'd
> agree that it would be indeed nice if we could somehow call out to the
> synthesized setters. I don't have so deep insights into the Obj-C
> runtime but I was wondering if there is some magic one can pull off to
> get to the original setters.

In fact, I was just about to post on this.

As an alternative to the observer approach, it certainly is possible to switch 
a method of your own choosing in to replace the synthesized setter. Getting the 
coding-time usability right seems like the main issue.

It occurs to me that there may be a lower-tech solution. If you created an 
abstract superclass of the class whose setters you wanted to override, you 
could synthesize the properties in the superclass, override them normally, and 
call super in the subclass. There's still a bit of ugliness in this approach 
(e.g. you have to expose the private superclass in the subclass's public .h 
file), though not much perhaps. Also, since the compilers have been getting 
pickier in their recent versions regarding the way property methods are 
defined, there may turn out to be a compile-time obstacle, but in principle I 
think this approach should work -- you'd basically be getting the compiler to 
delve into the runtime for you.

Again, though, I remain unconvinced that going to all this trouble is worth it, 
just to eliminate a lingering sense of unease. Perhaps a short course of 
therapy instead?

Regarding the observer approach…

I have no great technical, moral or psychological objections to this approach, 
but a couple of small things still worry me:

-- The source code for a simple custom setter is kind of … obvious … to read. 
It's an instantly recognizable pattern. I've always found observations somewhat 
difficult to come back to and understand, after the code has already been 
written, perhaps because the 'observe…' method exists at some random, 
disconnected place, and decoding the execution flow through it can be 
mind-bending in all but the simplest cases. Quite often this approach leads to 
nested observations, with the add/remove observers needing to get done inside 
an 'observe…' method also. OTOH, maybe a short course of therapy would cure me 
of the feeling.

-- Adding an observer creates a not-insignificant amount of internal machinery 
per observed object. For observing a few views, this isn't significant in 
practice. As a design principle for a generally useful mechanism, the prospect 
of unwittingly creating observations for maybe hundreds of thousands of objects 
seems like a drawback.

-- There's an actual semantic difference between the two approaches. If you 
write custom setters in a class hierarchy, you get to control on a 
class-by-class basis whether the behavior added at one level (such as the 
'setNeedsDisplay:') is also inherited. If you add an observer, even an explicit 
custom setter override at a lower level (for example, one that wants to do 
'setNeedsDisplayInRect:' instead) can't turn off the observer behavior.

In other words, encapsulation is violated. That's fine if that's what you want, 
but it isn't really a drop-in replacement for the semantics of custom setters.

___

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: adding something to a setter

2011-10-06 Thread Torsten Curdt

The superclass approach is sneaky ...didn't think about that.

> Again, though, I remain unconvinced that going to all this trouble is worth
> it, just to eliminate a lingering sense of unease. Perhaps a short course of
> therapy instead?

LOL - maybe :)

Well, TBH this is less of "I want to use this" but more a "is it possible".
It's the curious child in me that wants to know :)



> In other words, encapsulation is violated. That's fine if that's what you
> want, but it isn't really a drop-in replacement for the semantics of custom
> setters.

That's actually a good point.

cheers,
Torsten
___

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: adding something to a setter

2011-10-06 Thread Charles Srstka

On Oct 6, 2011, at 6:22 PM, Quincey Morris wrote:

> It occurs to me that there may be a lower-tech solution. If you created an 
> abstract superclass of the class whose setters you wanted to override, you 
> could synthesize the properties in the superclass, override them normally, 
> and call super in the subclass. There's still a bit of ugliness in this 
> approach (e.g. you have to expose the private superclass in the subclass's 
> public .h file), though not much perhaps. Also, since the compilers have been 
> getting pickier in their recent versions regarding the way property methods 
> are defined, there may turn out to be a compile-time obstacle, but in 
> principle I think this approach should work -- you'd basically be getting the 
> compiler to delve into the runtime for you.

But isn't creating a whole abstract superclass for this a lot more of a hassle 
than just making a private property? What would you get from that approach that 
you wouldn’t get from just having the getters and setters for a property “foo” 
call through to the synthesized accessors for a private property “privateFoo”?

Charles___

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: adding something to a setter

2011-10-06 Thread Quincey Morris

On Oct 6, 2011, at 17:12 , Charles Srstka wrote:

> But isn't creating a whole abstract superclass for this a lot more of a 
> hassle than just making a private property?

*Some* more. I'm not sure about a *lot* more.

> What would you get from that approach that you wouldn’t get from just having 
> the getters and setters for a property “foo” call through to the synthesized 
> accessors for a private property “privateFoo”?

Functionally, they're pretty similar, I guess -- one property uses another in 
both cases.

The only real experience I have with a dual-property approach is via Core Data 
(foo vs primitiveFoo -- imagine we're trying to put a 'setNeedsDisplay:' in a 
Core Data property override, so that we need to call through to primitiveFoo). 
It seems straightforward enough conceptually, but when you try to use it, 
things get hard.

Now if you find other functionality to add to the property, you have to ask 
yourself whether you're modifying the primitive property or the public 
property. Often, the answer is "Duh, I dunno." KVO can get tricky, because the 
notifications start to go round in circles or just break, and it's not clear 
how to fix the problem. You start having to guess how having two more or less 
identical properties interact with (say) undo. If you start subclassing, you 
again may have puzzling decisions about how and where to add overriding 
behavior.

I don't say it can't be done. I'm just saying when I've tried it for real I've 
found myself in a classic Houdini bind (that is, handcuffed, chained and locked 
in a steamer trunk at the bottom of a river) without actual Houdini skills to 
get me out.

But maybe that's just me.

___

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

-[NSURLCredentialStorage removeCredential:forProtectionSpace:] broken?

2011-10-06 Thread Jim Correia

Is there a known problem with -[NSURLCredentialStorage 
removeCredential:forProtectionSpace:], or are my expectations wrong?
 
I iterate all the credials in the storage looking for the one I wish to remove, 
then send -removeCredential:forProtectionSpace: to the instance, and it doesn't 
actually remove the item from the keychain.
 
Is this supposed to work?
 
(Yes, I know I can, and probably will have to, drop down to the keychain APIs 
directly.)
 
—Jim


___

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: adding something to a setter

2011-10-06 Thread Jim Correia

Do not use self as your observation context.

Your observation context has to be unique for all observers of the object.  
“self” is a bad choice.

Also, you should only do your own work in the case that the observer is your 
observer. In the code below, you are also doing your work in the case where you 
should only be calling through to super.

—Jim

On Oct 6, 2011, at 5:47 AM, Stephan Michels wrote:

> I use KVO to execute custom code if a property has changed.
> 
> [self addObserver:self forKeyPath:@"graphics" 
> options:(NSKeyValueObservingOptionNew|NSKeyValueObservingOptionOld) 
> context:self];
> 
> - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object 
> change:(NSDictionary *)change context:(void *)context {
>if (context != self) {
>[super observeValueForKeyPath:keyPath ofObject:object change:change 
> context:context];
>}
> 
>if ([keyPath isEqualToString:@"graphics"]) {
>[self setNeedsDisplay:YES];
>}
> }
> 
> AFAIK the observe method will not be executed instantaneously, but on the 
> other side setNeedsDisplay has also a
> deferred execution.
> 
> Stephan.
___

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: NSPrintInfo and NSPageLayout

2011-10-06 Thread Ken Thomases

On Oct 6, 2011, at 8:46 AM, Torsten Curdt wrote:

> 1) Currently I set the width of the view to the page size width minus
> the left and right margin. Frankly speaking I have no clue if that is
> the right thing to do. Or is imageablePageBounds the one to use?

I'm not sure.  I know that you can get the PMPageFormat object from the 
NSPrintInfo and then call PMGetAdjustedPageRect() on it, if that helps.  
Hopefully others can provide a better answer.

> 2) When I configure the page layout with [[NSPageLayout pageLayout]
> runModal] the layout settings don't make it over to my print dialog.
> For example I tried to change the orientation but when I get the print
> dialog it's still in portrait. It's not that surprising as I don't see
> the connection between the two yet - but how do I make the connection?

The -runModal method uses the shared print info object, which can be obtained 
with +[NSPrintInfo sharedPrintInfo].  You can change the shared print info with 
+[NSPrintInfo setSharedPrintInfo:], if you have reason to.  Alternatively, you 
can use -[NSPageLayout runModalWithPrintInfo:] to use a different print info 
for the page layout dialog.

In any case, you need to use the same print info object for the 
NSPrintOperation so that it can use that for the NSPrintPanel.  That's how 
changes made in the page setup dialog get communicated to the print dialog.  
So, you can have both dialogs use the shared print info object (using the 
methods which don't take an explicit print info object) or you can specify your 
own print info object to both (passing the same object to the methods which do 
take an explicit print info object).

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

Missing header files/folders?

2011-10-06 Thread Shane Stanley

I've just bought a new Mac, and after migrating and updating I notice that 
inside the frameworks in /System/Library/Frameworks/, the Headers link and 
Headers folder that appear on my old Mac are not to be found on my old one. 
Should they be there, or are the ones on my old Mac a relic of systems past?


-- 
Shane Stanley 
'AppleScriptObjC Explored' 

___

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: adding something to a setter

2011-10-06 Thread Yi Lin

It's perhaps helpful to remember that property was introduce to remove the
annoyance with having to define boilerplate accessor for 90% of your
properties. People are now writing 90% less accessor code, so writing one
more for your case below seems tolerable. After all, it's just a few lines
of code.

Yi

On Thu, Oct 6, 2011 at 4:28 AM, Torsten Curdt  wrote:

> The property syntax is great until you need one more thing.
>
> Think of a NSView and that view displays a value.
>
>  @synthesize value;
>
> Now you also want to setNeedsDisplay: when a new value is set. So one
> can override the setter.
>
>  - (void)setValue:(NSString*)theValue
>  {
>   ...
>   [self setNeedsDisplay:YES];
>  }
>
> but - you would have to implement the setter yourself. No big deal -
> but... it sucks.
> Is there a way to forward the setting to the originally synthesized
> setter? Super cannot be it.
>
> Of course one could add another selector that to the interface
>
>  - (void) setValueAndUpdateDisplay:(NSString*)theValue
>  {
>self.value = theValue;
>   [self setNeedsDisplay:YES];
>  }
>
> ...but that sucks, too.
>
> There gotta be a better way!
> How do you deal with this?
>
> cheers,
> Torsten
> ___
>
> 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/yioncocoa%40gmail.com
>
> This email sent to yionco...@gmail.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: How to blink with a focus ring of the text box?

2011-10-06 Thread Yi Lin

Another way is to make the cursor stop at the end of the limit, and if the
user keeps banging on the keyboard, show an alert message stating the
character limit on the field.

On Thu, Oct 6, 2011 at 8:33 AM, Nick  wrote:

> Hello
> I am wondering if there's a way to do this, notifying the user that he
> can't
> enter any more text into NSTextField edit box?
> Is there a way to change the color of the NSTextField's focus ring to red
> (to highlight that this is an error)?
> How difficult would that be to implement?
> 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/yioncocoa%40gmail.com
>
> This email sent to yionco...@gmail.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: Missing header files/folders?

2011-10-06 Thread Jens Alfke

On Oct 6, 2011, at 9:09 PM, Shane Stanley wrote:

> I've just bought a new Mac, and after migrating and updating I notice that 
> inside the frameworks in /System/Library/Frameworks/, the Headers link and 
> Headers folder that appear on my old Mac are not to be found on my old one. 
> Should they be there, or are the ones on my old Mac a relic of systems past?

I have them, and I just reinstalled my OS recently. Did you install Xcode yet? 
They might not be part of the base OS install.

—Jens___

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: Missing header files/folders?

2011-10-06 Thread Joar Wingfors


On 6 okt 2011, at 22:38, Jens Alfke wrote:

> On Oct 6, 2011, at 9:09 PM, Shane Stanley wrote:
> 
>> I've just bought a new Mac, and after migrating and updating I notice that 
>> inside the frameworks in /System/Library/Frameworks/, the Headers link and 
>> Headers folder that appear on my old Mac are not to be found on my old one. 
>> Should they be there, or are the ones on my old Mac a relic of systems past?
> 
> I have them, and I just reinstalled my OS recently. Did you install Xcode 
> yet? They might not be part of the base OS install.


All the bits and pieces of an Xcode install doesn't survive a migration. You 
have to reinstall Xcode.

j o a r


___

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

[Moderator] Again - Mourning the loss of Steve

2011-10-06 Thread Scott Anguish

I don’t want to write about this again, but there is something I can offer that 
might help some of you. I’ve gotten some personal emails that were truly 
touching.

There is an address you can send your emails of condolence, memories, thanks, 
etc.

rememberingst...@apple.com

This is a tough time for everyone at Apple and for many of you. Many of us 
hurt. But he’d expect us to go on and do better.

I’ve only made this second posting so that people know where to write. The 
respect you, the list members, have shown in not swamping the list is much 
appreciated.



—
Scott [Moderator]
Think of what Steve would do and then try and do better. For him.

___

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: Missing header files/folders?

2011-10-06 Thread Shane Stanley

On 07/10/2011, at 4:42 PM, Joar Wingfors wrote:

> All the bits and pieces of an Xcode install doesn't survive a migration. You 
> have to reinstall Xcode.

That did the trick. I'd assumed Xcode was only responsible for the ones in 
/Developer/.

Many thanks.

-- 
Shane Stanley 
'AppleScriptObjC Explored' 

___

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

55 matches

Mail list logo