Re: Understanding layer-backed views

[Scott Anguish]

> Yep, I'm aware of the setWantsLayer/setLayer order making a difference.
> 
> In my case I want a layer-hosting view, not a layer-backed view.
> 
> However, my question isn't really about that, but about what is done when you 
> check the box next to the layer in Interface Builder, in the 'setWantsLayer' 
> panel. Does this provide layer backing or layer hosting? My thoughts were 
> that is provides layer hosting, but I'm not 100% sure. Proceeding on the 
> basis that this is the case, it seems to work.
> 

layer-backed.




> 
>> Again this is not in line with my expectations, which is that the frame of a 
>> sublayer is expressed in the coordinate system of its superlayer, not the 
>> underlying window.
> 
> I found the cause of this issue, which was that in my layer delegate, I was 
> not saving, setting and restoring the context passed to drawLayer:inContext:. 
> I was assuming that the context was set, but having found a code snippet in 
> the docs that indicated it wasn't, I added these calls and my graphics are 
> drawing in the right place now.
> 

great!___

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: Synthesised properties and additional actions

[Ken Tozier]

Hi all

I just started using @properties this week, so probably don't understand the 
nuances, but after looking at Matt's sample code, reading the property related 
docs and doing some experimentation, I'm not sure I understand what problem 
he's trying to solve. Is he talking about overriding inherited getters/setters?

With my own very limited experience with properties, it seems to be really easy 
to add functionality. Just write the getter/setter yourself. When you go to use 
them, they behave exactly like the auto generated ones re dot syntax, and do 
whatever cool thing you added.

What am I missing?


On Jun 19, 2011, at 2:02 PM, Dave DeLong wrote:

> 
> On Jun 19, 2011, at 11:01 AM, Matt Neuburg wrote:
> 
>> I provide a good (I think) technique for doing this in my book (p. 275, 
>> example 12-5 "Overriding synthesized accessors"). You can also download 
>> sample code here:
>> 
>> https://github.com/mattneub/Programming-iOS-4-Book-Examples/tree/master/p275b_overrideSynthesizedAccessors
> 
> Ha, that's quite clever.  I like it.  :)
> 
> Dave
> ___
> 
> 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/kentozier%40comcast.net
> 
> This email sent to kentoz...@comcast.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

tooltips not firing on first try

[Rick C.]

Hi again,

I have used the delegate method 
tableView:toolTipForCell:rect:tableColumn:row:mouseLocation: and it's working 
fine except on first try.  So for example I click a button which launches a 
panel with my tableview and I move my mouse to hover over a cell and no 
tooltip.  Now if I scroll down a bit inside my tableview and try again it 
works.  Even if I go back to the original cell it works.  Just not on first 
try.  What could be causing this issue any thoughts?  Thanks!

rc___

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: Synthesised properties and additional actions

[Joanna Carter]

Hi folks

Le 22 juin 2011 à 08:58, Ken Tozier a écrit :

> I just started using @properties this week, so probably don't understand the 
> nuances, but after looking at Matt's sample code, reading the property 
> related docs and doing some experimentation, I'm not sure I understand what 
> problem he's trying to solve. Is he talking about overriding inherited 
> getters/setters?
> 
> With my own very limited experience with properties, it seems to be really 
> easy to add functionality. Just write the getter/setter yourself. When you go 
> to use them, they behave exactly like the auto generated ones re dot syntax, 
> and do whatever cool thing you added.
> 
> What am I missing?

Yes, I would also like to know what Matt is trying to achieve with all those 
machinations that you can't do with a simple ivar in the class and not 
bothering to @synthesize. The only time I declare @synthesize and write 
getters/setters is when I want either a complex getter or setter but not have 
to bother writing the other.

Joanna

--
Joanna Carter
Carter Consulting

___

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: Synthesised properties and additional actions

[Charles Srstka]

On Jun 22, 2011, at 3:23 AM, Joanna Carter wrote:

> Hi folks
> 
> Le 22 juin 2011 à 08:58, Ken Tozier a écrit :
> 
>> I just started using @properties this week, so probably don't understand the 
>> nuances, but after looking at Matt's sample code, reading the property 
>> related docs and doing some experimentation, I'm not sure I understand what 
>> problem he's trying to solve. Is he talking about overriding inherited 
>> getters/setters?
>> 
>> With my own very limited experience with properties, it seems to be really 
>> easy to add functionality. Just write the getter/setter yourself. When you 
>> go to use them, they behave exactly like the auto generated ones re dot 
>> syntax, and do whatever cool thing you added.
>> 
>> What am I missing?
> 
> Yes, I would also like to know what Matt is trying to achieve with all those 
> machinations that you can't do with a simple ivar in the class and not 
> bothering to @synthesize. The only time I declare @synthesize and write 
> getters/setters is when I want either a complex getter or setter but not have 
> to bother writing the other.
> 
> Joanna

It’s possible that he wants to inherit the atomic behavior of Apple’s automatic 
synthesized properties. It’s been implied before on the list that the 
synthesized properties use a more efficient implementation of atomicity than 
the typical @synthesized or lock-based approaches.

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: tooltips not firing on first try

[Lee Ann Rucker]

Possibly Radar 5847161 - Tooltip on NSTableView does not appear on newly 
selected cell

Summary: 
If an NSTableView has a delegate that implements 
tableView:toolTipForCell:rect:tableColumn:row:mouseLocation:, tooltips will not 
appear when a cell is selected and the mouse is not moved.

Apple's response:
NSTableView doesn't know it should update anything, since the mouse has not 
moved outside of the area it was tracking. 
Calling updateTrackingAreas should solve the problem.

It didn't, because the tracking areas hadn't changed. The bug's still open.

- Original Message -
From: "Rick C." 
To: "Cocoa-Dev User list" 
Sent: Wednesday, June 22, 2011 1:07:35 AM
Subject: tooltips not firing on first try

Hi again,

I have used the delegate method 
tableView:toolTipForCell:rect:tableColumn:row:mouseLocation: and it's working 
fine except on first try.  So for example I click a button which launches a 
panel with my tableview and I move my mouse to hover over a cell and no 
tooltip.  Now if I scroll down a bit inside my tableview and try again it 
works.  Even if I go back to the original cell it works.  Just not on first 
try.  What could be causing this issue any thoughts?  Thanks!

rc___

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/lrucker%40vmware.com

This email sent to lruc...@vmware.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: Synthesised properties and additional actions

[Mikkel Islay]

It's a variation on this pattern, from the "The Objective-C Programming 
Language":
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW1

Mikkel___

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: Synthesised properties and additional actions

[Charles Srstka]

On Jun 22, 2011, at 4:28 AM, Mikkel Islay wrote:

> It's a variation on this pattern, from the "The Objective-C Programming 
> Language":
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW1

I was going by this, which states that the implementation is lightweight and 
purposefully undocumented.

http://www.cocoabuilder.com/archive/cocoa/229741-synchronized-in-thread-safe-accessors.html?q=synthesized+properties+atomic+lock#229767

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

How to log arguments in runtime?

[Guillermo Moral]

I created a new function to log every method from a class in runtime.


The problem that I have is in this line :


id value = va_arg(stackFrame, id);


Doesn`t convert the type of object inside the arguments.


Any idea on what I'm doing wrong? Is there another way to do this?


   void InitDebug ( id self, SEL _cmd, ...)

{

 id receiver = self;

SEL receiverSelector = _cmd;

 va_list stackFrame;

 va_start(stackFrame, _cmd);

 NSString* threadString = [NSString stringWithFormat:@"%@", [NSThread
currentThread]];

 NSMutableString* logString = [NSMutableString string];

 [logString appendString:[NSString stringWithFormat: @"After - Thread:%@ -
Class:%@ - Method:%@",

  threadString,

  NSStringFromClass([receiver class]),

  NSStringFromSelector(receiverSelector)]];

 NSMethodSignature *signature

= [receiver methodSignatureForSelector:receiverSelector];



NSUInteger count = [signature numberOfArguments];

 if (count == 2)

{

 [logString appendString:[NSString stringWithFormat:@" None"]];

}

 NSUInteger index = 2;

 for (; index < count; index++)

{

const char *argType = [signature getArgumentTypeAtIndex:index];



if ((strlen(argType) > 1)

 && (strchr("{^", argType[0]) == NULL)

 && (strcmp("@?", argType) != 0))

{

[NSException raise:NSInvalidArgumentException

format:@"Cannot handle argument type '%s'.",
argType];

}

#define IS_EQUAL 0

if (strcmp(argType, @encode(id)) == IS_EQUAL)

{

id value = va_arg(stackFrame, id);

if (!value)

{



}

}

}

 NSLog(@"%@",logString);

 va_end(stackFrame);

 }


-- 
Guillermo Moral
___

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: Help Book question

[Matt Neuburg]

On Tue, 21 Jun 2011 22:24:07 -0400, Eric Gorr  said:
>This should be an easy question for someone to answer.

Even easier, though, if you were to ask this instead on the 
apple-help-authoring list. Addressing your question to the right group is 
always a good idea, and in this case, that is certainly where the people with 
long and deep experience of Apple Help hang out.

>I've got a sample application demonstrating the problem at:
>
>http://ericgorr.net/cocoadev/helpbooktest.zip
>
>After launching the application, bring up the help book from the help menu.
>
>The first about link is anchor based and should link to the about page, but 
>clicking it causes a dialog to appear which states that the help application 
>cannot display the content.
>
>The second about link is simply a path to the about page and does work.
>
>I would like to understand why the anchor based link isn't working. I'm sure 
>I'm doing something obviously wrong

Not necessarily; this feature *could* just be broken... m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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: UIScrolview in only one direction at time

[Matt Neuburg]

On Mon, 20 Jun 2011 21:29:55 -0300, Tales Pinheiro de Andrade  
said:
>Hello

Hello.

>is it possible to temporally disable the scroll in one direction?

Yes.

> For example, if the user start scrolling in horizontal, so it's only possible 
> to scroll in that direction, until the scroll end. After that, if the user 
> starts scrolling in vertical, it's temporally (until the scrolls end) not 
> possible to scroll in horizontal.

Fine.

>How can I check this scroll?

In the delegate. You know the content offset as the scroll starts (in the 
delegate), and you can change the content offset as the user scrolls (in the 
delegate), so you can counteract any change in the x- or y-component of the 
content offset during the drag. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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: Synthesised properties and additional actions

[Matt Neuburg]

On Wed, 22 Jun 2011 09:23:54 +0100, Joanna Carter 
 said:
>Hi folks
>
>Le 22 juin 2011 à 08:58, Ken Tozier a écrit :
>
>> I just started using @properties this week, so probably don't understand the 
>> nuances, but after looking at Matt's sample code, reading the property 
>> related docs and doing some experimentation, I'm not sure I understand what 
>> problem he's trying to solve. Is he talking about overriding inherited 
>> getters/setters?
>> 
>> With my own very limited experience with properties, it seems to be really 
>> easy to add functionality. Just write the getter/setter yourself. When you 
>> go to use them, they behave exactly like the auto generated ones re dot 
>> syntax, and do whatever cool thing you added.
>> 
>> What am I missing?
>
>Yes, I would also like to know what Matt is trying to achieve with all those 
>machinations that you can't do with a simple ivar in the class and not 
>bothering to @synthesize.

Well, if you really want to know that, just read the discussion in the book:

http://www.apeth.com/iOSBook/ch12.html

My thought was (putting myself in the shoes of the student), hey, I have no 
idea exactly what code @synthesize generates, but whatever it is, it surely 
constitutes a correct getter and (especially) setter, whereas if I write those 
things myself (and especially the setter) the chances that I'll do something 
wrong are quite high. So the question is simply, how can I add my own 
functionality while at the same time inheriting all the synthesized accessors' 
yummy goodness, whatever it may be? m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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: Help Book question

[Eric Gorr]

On Jun 22, 2011, at 11:19 AM, Matt Neuburg  wrote:

> Even easier, though, if you were to ask this instead on the 
> apple-help-authoring list. 

Thanks.

>> I would like to understand why the anchor based link isn't working. I'm sure 
>> I'm doing something obviously wrong
> 
> Not necessarily; this feature *could* just be broken... m.

Considering that nearly every help
book on the OS is anchor based and work, I believe the problem is on
my end.
> 
___

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 log arguments in runtime?

[Jens Alfke]

On Jun 22, 2011, at 7:40 AM, Guillermo Moral wrote:

> The problem that I have is in this line :
> id value = va_arg(stackFrame, id);
> Doesn`t convert the type of object inside the arguments.

That line looks OK. What does “doesn’t convert the type of object” mean, 
exactly? It’s hard to answer the question when you’re not being specific about 
what happens (and what you expected to happen.)

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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: UIScrolview in only one direction at time

[talesp]

Alright, thank you!

I was trying to do this in my class, that is a subclass of UIScrollview. But it 
was looking strange and not really working.

I'll try this.

Thank you again.

On 22 Jun, 2011,at 12:37 PM, Matt Neuburg  wrote:

On Mon, 20 Jun 2011 21:29:55 -0300, Tales Pinheiro de Andrade  
said:

Hello


Hello.


is it possible to temporally disable the scroll in one direction?


Yes.


For example, if the user start scrolling in horizontal, so it's only possible 
to scroll in that direction, until the scroll end. After that, if the user 
starts scrolling in vertical, it's temporally (until the scrolls end) not 
possible to scroll in horizontal.


Fine.


How can I check this scroll?


In the delegate. You know the content offset as the scroll starts (in the 
delegate), and you can change the content offset as the user scrolls (in the 
delegate), so you can counteract any change in the x- or y-component of the 
content offset during the drag. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook
___

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: Synthesised properties and additional actions

[Joanna Carter]

Hi Matt

> Well, if you really want to know that, just read the discussion in the book:
> 
> http://www.apeth.com/iOSBook/ch12.html
> 
> My thought was (putting myself in the shoes of the student), hey, I have no 
> idea exactly what code @synthesize generates, but whatever it is, it surely 
> constitutes a correct getter and (especially) setter, whereas if I write 
> those things myself (and especially the setter) the chances that I'll do 
> something wrong are quite high. So the question is simply, how can I add my 
> own functionality while at the same time inheriting all the synthesized 
> accessors' yummy goodness, whatever it may be? m.

Ah, now I get it!!!  - at least I think I do ;-)

AFAICT, you are talking about making "non-GC" accessors less prone to reference 
counting errors? If I'm using GC, then this, presumably, becomes less relevant?

Joanna

--
Joanna Carter
Carter Consulting

___

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

acceptsFirstMouse doesn't work

[Leonardo]

Hi,
I have a xib file with a MyButton nested that way

MyWindow
MyContentView
MySplitView
MyRightView
MyScrollerView
MyDocumentView
MyButton

I have properly subclassed all of these classes and overrided
- (BOOL)acceptsFirstMouse:(NSEvent *)theEvent { return YES; }
but I can't get the first click activate the button's action. The first
clicks activate justthe window, then I have to click on the button again to
call it's action.

When MyButton is nested
MyWindow
MyContentView
MyButton
it works very well, so I suppose that the problem comes from
MyDocumentView's clipView. Right? If so, should I override the
acceptsFirstMouse in the MyDocumentView's clipView too? If yes, how to
subclass the clipView and replace the one already present within
MyScrollerView?

Also, I can't select a tableView's row with the firstClick too.


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: Synthesised properties and additional actions

[Matt Neuburg]

On Jun 22, 2011, at 10:41 AM, Joanna Carter wrote:

> AFAICT, you are talking about making "non-GC" accessors less prone to 
> reference counting errors? If I'm using GC, then this, presumably, becomes 
> less relevant?

My book is about iOS 4; there is no GC in that world! :)

m.___

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: Synthesised properties and additional actions

[Joanna Carter]

Hi Matt

> My book is about iOS 4; there is no GC in that world! ☺

Aha! Missed that bit 

But was I finally right?

Joanna

--
Joanna Carter
Carter Consulting

___

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: Synthesised properties and additional actions

[Chris Parker]

On 22 Jun 2011, at 11:10 AM, Joanna Carter wrote:

>> My book is about iOS 4; there is no GC in that world! ☺
> 
> Aha! Missed that bit 
> 
> But was I finally right?

Consider the multi-threaded case where you want property access to be atomic 
(and remember, properties might not always be objects).

You still would like to take advantage of the locking behavior the @synthesized 
getter/setter pair offers you rather than writing it yourself.

The accessor synthesis doesn't just get you retain counting. Labeling and 
@property with the 'atomic' specifier can help in writing thread-safe accessors 
as well.

.chris


___

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

Proper removal of a NSStatusItem?

[Mac QA]

Hi,

When my app quits it leave a gap on the Finder's menu bar where the
NSStatusItem was. This gap gets cleaned up the next time a user
"switches" apps. But if you quit my app, see the gap in the Finder
bar, then just leave the Finder as the frontmost app for awhile that
gap just remains onscreen looking like a terrible eyesore. :-) Is
there something I should do differently when my app terminates to
remove the NSStatusItem so that the Finder's UI cleans up immediately
rather than at the next app switch. Suggestions appreciated. Thanks.

MacQAGuy
___

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

acceptsFirstMouse doesn't work SOLVED

[Leonardo]

My mistake.
The MyButton was placed "under" another view.
Now I have put it over the view and it feels the firstClick.
Fine.

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: Synthesised properties and additional actions

[Ken Tozier]

For those of us new to @synthesize, would it be possible to get concrete 
examples of exactly what it does to create "thread safety? What is Apple doing, 
under the hood, to provide this?

For example: Say I have 3 properties, a float, a struct and an NSObject 
subclass. Written by hand they might look like

- (void) setScalar:(float) inValue
{
floatProp   = inValue;
}

- (void) setStruct:(MyStruct) inValue
{
structProp  = inValue;
}

- (void) setObject(id) inValue
{
objectProp  = inValue;
}

If for some reason, we have to write accessors for some properties, what might 
those three look like if we could look into the source of properties created by 
synthesize? 


On Jun 22, 2011, at 2:18 PM, Chris Parker wrote:

> 
> On 22 Jun 2011, at 11:10 AM, Joanna Carter wrote:
> 
>>> My book is about iOS 4; there is no GC in that world! ☺
>> 
>> Aha! Missed that bit 
>> 
>> But was I finally right?
> 
> Consider the multi-threaded case where you want property access to be atomic 
> (and remember, properties might not always be objects).
> 
> You still would like to take advantage of the locking behavior the 
> @synthesized getter/setter pair offers you rather than writing it yourself.
> 
> The accessor synthesis doesn't just get you retain counting. Labeling and 
> @property with the 'atomic' specifier can help in writing thread-safe 
> accessors as well.
> 
> .chris
> 
> 
> ___
> 
> 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/kentozier%40comcast.net
> 
> This email sent to kentoz...@comcast.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: Synthesised properties and additional actions

[Ken Thomases]

On Jun 22, 2011, at 1:49 PM, Ken Tozier wrote:

> For those of us new to @synthesize, would it be possible to get concrete 
> examples of exactly what it does to create "thread safety? What is Apple 
> doing, under the hood, to provide this?

Well, obviously, that's an implementation detail.  Any explanation has to be 
caveated out the wazoo that we don't really know and, if we did, it could 
change at any time.  Consider yourself caveated.


> For example: Say I have 3 properties, a float, a struct and an NSObject 
> subclass. Written by hand they might look like
> 
> - (void) setScalar:(float) inValue
> {
>   floatProp   = inValue;
> }
>> 

> - (void) setObject(id) inValue
> {
>   objectProp  = inValue;
> }

For the above two, if you're using managed memory and the object property is 
merely "assign", nothing would be necessary on any likely CPU architecture.  
(I'm not really familiar with ARM, but I'd be surprised if the above weren't 
atomic.)  If you're using GC, what's apparently a simple assignment in the 
object case isn't any longer.  The compiler emits a write barrier.  I'm not 
sure what the atomicity implications of that are.

> - (void) setStruct:(MyStruct) inValue
> {
>   structProp  = inValue;
> }

The issue here is that two threads might simultaneous be running -setStruct:.  
Or, one thread might be running -struct (the getter) while -setStruct: is 
running in another.  Assuming a non-trivial struct, the CPU will be using 
multiple instructions to copy the fields of the struct.  The threads can be 
interrupted at any point.  So, a getter might get half of the old struct and 
half the new.  Or the two setters could overwrite each other -- the first 
thread writes part of the struct and is interrupted, the second thread writes 
over the entire struct, the first thread resumes and finishes writing what it 
didn't get to previously.  So, the instance variable contains a mishmash of 
values, some from the first thread's copy and some from the second thread's.

The above explanation is somewhat simplified.  There can be more than two 
threads.  Both the compiler and the CPU can do wholly non-intuitive things to 
your code and its effects.  Etc.


> If for some reason, we have to write accessors for some properties, what 
> might those three look like if we could look into the source of properties 
> created by synthesize? 

You would want the getter and the setter to use a shared lock to make sure that 
only one is running at a time and to counteract some of the non-intuitive stuff 
done by the compiler and CPU.

For example:

- (MyStruct)struct
{
@synchronized(self) {
return structProp;
}
}

- (void) setStruct:(MyStruct)inValue
{
@synchronized(self) {
structProp = inValue;
}
}

Now, @synchronized is fairly expensive.  You could use NSLock for some speed 
improvement.  Apparently, synthesized accessors use an even more efficient lock.

Also, I have synchronized on the object (self).  If the other atomic properties 
use the same mechanism, then they are all synchronized with each other, which 
is not strictly necessary for the atomicity of each property in isolation.  
That means there will be more contention around that shared lock than is 
necessary, which is also inefficient.  If you use NSLock, you could use a 
separate lock object for each atomic property, which is more efficient.  And, 
again, synthesized accessors do something like that.

All of that said, keep in mind Apple's advice that atomic properties are _not_ 
sufficient for general thread safety.  They only protect against a certain 
narrow thread safety issue.  There are many others, which almost always require 
synchronization mechanisms at a high level of the design of your classes.

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

constrained window resizing

[Ken Victor]

i’ve got a subclass of NSWindow (MagneticWindow) that provides:
- (NSSize) windowWillResize: (NSWindow*) sender toSize: (NSSize) 
frameSize;
i use this to provide constrained live resizing of the window, i.e., if the 
shift key is down, the window will only resize in the horizontal or vertical 
direction (based on the mouse’s position relative to where it was at mouse down 
time), and if the shift and control keys are both down, then the window will 
maintain its aspect ratio as it is resized.

this is all working fine except for one minor point: i don’t get called if any 
of the keys change their state (e.g., when the shift is let up) until the user 
moves the mouse. since the framework is running its own runloop for resizing, i 
don’t see how to “hook in”. and while this class has overridden sendEvent to 
provide its own runloop for dragging windows around (to provide similar 
constraining), i don’t really want to have to do this for resizing as i’m not 
sure of all the methods i would have to call to get live resizing drawing 
working properly.

can anyone suggest a way i can get informed when any of the modifier keys 
change their state while in the midst of live resizing (without requiring mouse 
movement)?

thanx,
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: Proper removal of a NSStatusItem?

[Gregory Weston]

Mac QA wrote:

> When my app quits it leave a gap on the Finder's menu bar where the
> NSStatusItem was. This gap gets cleaned up the next time a user
> "switches" apps. But if you quit my app, see the gap in the Finder
> bar, then just leave the Finder as the frontmost app for awhile that
> gap just remains onscreen looking like a terrible eyesore. :-) Is
> there something I should do differently when my app terminates to
> remove the NSStatusItem so that the Finder's UI cleans up immediately
> rather than at the next app switch. Suggestions appreciated. Thanks.

Have you tried sending removeStatusItem: to the status bar?
___

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: tooltips not firing on first try

[Corbin Dunn]

On Jun 22, 2011, at 2:15 AM, Lee Ann Rucker wrote:

> Possibly Radar 5847161 - Tooltip on NSTableView does not appear on newly 
> selected cell
> 
> Summary: 
> If an NSTableView has a delegate that implements 
> tableView:toolTipForCell:rect:tableColumn:row:mouseLocation:, tooltips will 
> not appear when a cell is selected and the mouse is not moved.
> 
> Apple's response:
> NSTableView doesn't know it should update anything, since the mouse has not 
> moved outside of the area it was tracking. 
> Calling updateTrackingAreas should solve the problem.

Yeah, that was from me. When did you call -updateTrackingAreas? It should work 
to reset tracking areas, but also -resetCursorRects might work too.

The problem is that there is no way for the table to know that you are 
returning a different value if you don't move out of the cell frame and back 
in; it is only called after we get a new tracking area entered message.

corbin




> 
> It didn't, because the tracking areas hadn't changed. The bug's still open.
> 
> - Original Message -
> From: "Rick C." 
> To: "Cocoa-Dev User list" 
> Sent: Wednesday, June 22, 2011 1:07:35 AM
> Subject: tooltips not firing on first try
> 
> Hi again,
> 
> I have used the delegate method 
> tableView:toolTipForCell:rect:tableColumn:row:mouseLocation: and it's working 
> fine except on first try.  So for example I click a button which launches a 
> panel with my tableview and I move my mouse to hover over a cell and no 
> tooltip.  Now if I scroll down a bit inside my tableview and try again it 
> works.  Even if I go back to the original cell it works.  Just not on first 
> try.  What could be causing this issue any thoughts?  Thanks!
> 
> rc___
> 
> 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/lrucker%40vmware.com
> 
> This email sent to lruc...@vmware.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/corbind%40apple.com
> 
> This email sent to corb...@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: tooltips not firing on first try

[Lee Ann Rucker]

On Jun 22, 2011, at 4:00 PM, Corbin Dunn wrote:

> 
> On Jun 22, 2011, at 2:15 AM, Lee Ann Rucker wrote:
> 
>> Possibly Radar 5847161 - Tooltip on NSTableView does not appear on newly 
>> selected cell
>> 
>> Summary: 
>> If an NSTableView has a delegate that implements 
>> tableView:toolTipForCell:rect:tableColumn:row:mouseLocation:, tooltips will 
>> not appear when a cell is selected and the mouse is not moved.
>> 
>> Apple's response:
>> NSTableView doesn't know it should update anything, since the mouse has not 
>> moved outside of the area it was tracking. 
>> Calling updateTrackingAreas should solve the problem.
> 
> Yeah, that was from me. When did you call -updateTrackingAreas? It should 
> work to reset tracking areas, but also -resetCursorRects might work too.
> 
> The problem is that there is no way for the table to know that you are 
> returning a different value if you don't move out of the cell frame and back 
> in; it is only called after we get a new tracking area entered message.

My reply 3 years ago was
---
14-Apr-2008 02:13 PM Lee Ann Rucker:
Not on Tiger, no, as it's a Leopard API, and when should it be called? ... I 
did try putting it in my tableViewSelectionDidChange: method but it had no 
effect.
---

Never got anything back from that, and that NSTableView has long since been 
replaced by an NSCollectionView (and I don't care about Tiger anymore either). 
The table views we are using don't have 
tooltips.___

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 NSTrackingArea doesn't work?

[Nick]

Hello
I need to watch when the mouse moved over the view (even when the app is not
'active'), and if this happens, to do something.

What I did:
in my custom subclassed view I defined:

-(id)initWithFrame:(NSRect)frameRect {

  self = [super initWithFrame:frameRect];

  NSLog(@"Init called!");


  NSTrackingArea* trackingArea = [[NSTrackingArea alloc] initWithRect:[self
frame] options: (NSTrackingMouseEnteredAndExited |   NSTrackingActiveAlways)
owner:self userInfo:nil];

[self addTrackingArea:trackingArea];

  return self;

}


-(void)mouseEntered:(NSEvent *)theEvent {

  NSLog(@"mouse entered");

}


-(void)mouseExited:(NSEvent *)theEvent {

  NSLog(@"mouse exited");

}



In terminal I get nothing - not even when the application is active and the
mouse is moved over it. The view is instantiated, and can be seen. The view
is added to the window's content view programmatically.
What could be wrong? Did I forget anything?
(Snow Leopard)

Thanks,
Nick
___

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: why NSTrackingArea doesn't work?

[Conrad Shultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/22/11 5:04 PM, Nick wrote:
>   NSTrackingArea* trackingArea = [[NSTrackingArea alloc] initWithRect:[self
> frame] options: (NSTrackingMouseEnteredAndExited |   NSTrackingActiveAlways)
> owner:self userInfo:nil];

Don't use [self frame]... that is in the superview's coordinate system,
not the tracking area's view's coordinate space (which is expected).

Use [self bounds] instead; depending on the absolute position of your
view this might make a HUGE difference.

(I reimplemented your code, with a slightly different object structure
[that is, not in a subview but in a view controller] and it worked fine
so long as I corrected the frame/bounds confusion.)

- -- 
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4Ci50ACgkQaOlrz5+0JdV7XACfcaI/Ki92koEOQWctxm7yEtua
e98AnRRtz971DquuMJFrU9JKZjkXs7bD
=QGrY
-END PGP SIGNATURE-
___

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: why NSTrackingArea doesn't work?

[Ken Thomases]

On Jun 22, 2011, at 7:41 PM, Conrad Shultz wrote:

> On 6/22/11 5:04 PM, Nick wrote:
>>  NSTrackingArea* trackingArea = [[NSTrackingArea alloc] initWithRect:[self
>> frame] options: (NSTrackingMouseEnteredAndExited |   NSTrackingActiveAlways)
>> owner:self userInfo:nil];
> 
> Don't use [self frame]... that is in the superview's coordinate system,
> not the tracking area's view's coordinate space (which is expected).
> 
> Use [self bounds] instead; depending on the absolute position of your
> view this might make a HUGE difference.

I strongly recommend considering use of NSTrackingInVisibleRect, too.  If your 
view changes windows or moves within its window, this will make things a lot 
simpler.  It can be the wrong thing in rare cases, but I'd be surprised if you 
need one of those.

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: why NSTrackingArea doesn't work?

[Nick]

Thanks a lot, It worked! :-)

I was creating a custom window, and wanted to make the "close/minimize/zoom"
buttons to behave naturally.
The only thing that isn't working in my custom window - is the
"click-through" on the [NSWindow standardWindowButton] button (I am using a
"fake" titlebar).
Whenever the window is not main/key and I click on the button, I get to
click twice -first to activate the window (make it main), second to actually
click on the, for example, "close" button.
Other "ordinary" cocoa buttons (NSPushButton) placed on this view allow
clicking on them directly when the view is not active.

These "close/minimize/zoom" buttons are placed on a view, that returns "YES"
in a -(BOOL)acceptsFirstMouse:(NSEvent *)theEvent
method.
Well this is ignored, and for some weird reason, by default, the  views,
returned by  [NSWindow standardWindowButton], return "NO" for
acceptsFirstMouse (since i need to click twice). And I can't even sublass
them to change what's happening.

Maybe you can suggest something? Should I build the buttons from scratch,
drawing all the icons by myself to make it behave real?
Thank you

2011/6/23 Ken Thomases 

> On Jun 22, 2011, at 7:41 PM, Conrad Shultz wrote:
>
> > On 6/22/11 5:04 PM, Nick wrote:
> >>  NSTrackingArea* trackingArea = [[NSTrackingArea alloc]
> initWithRect:[self
> >> frame] options: (NSTrackingMouseEnteredAndExited |
> NSTrackingActiveAlways)
> >> owner:self userInfo:nil];
> >
> > Don't use [self frame]... that is in the superview's coordinate system,
> > not the tracking area's view's coordinate space (which is expected).
> >
> > Use [self bounds] instead; depending on the absolute position of your
> > view this might make a HUGE difference.
>
> I strongly recommend considering use of NSTrackingInVisibleRect, too.  If
> your view changes windows or moves within its window, this will make things
> a lot simpler.  It can be the wrong thing in rare cases, but I'd be
> surprised if you need one of those.
>
> 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