Re: First Responder

[Motti Shneor]

On 11 במאי 2012, at 03:11, koko wrote:
> I have a menu item connected to an action in First Responder;
> The action exists in an NSView subclass.
> The subclass implements acceptsFirstResonder and return YES.
> The subclass implements validateMenuItem and return YES;
> When the menu displays the menu item is disabled (set to enabled in IB).
> Is this not the proper implementation?

Hello.

Your implementation is complete and you understood it right. But I'm afraid you 
missed the architectural level...

An NSResponder (such as your view) is given a chance to respond only when it is 
in the responder chain, and no one down the responder chain responds earlier.

Practically - just click on your view to select it/focus on it/make it the 
first-responder  then try again your menu item. You'll have a nice surprise.

The whole responder-chain thing is about context and focus. Many objects can 
implement the same action, and depending on user focus, they will become the 
first to get a chance to handle the action.

If you want the action to be handled even when the view is out-of-focus (not in 
focus, and not containing the currently focused element, not in the current 
responder chain) than you must move the action implementation (and 
menu-validation) to some other view or controller up the chain, that is always 
"there" - in the responder chain - when the user wishes to perform the action.

For example you'd always want the "Save..." to be available, regardless of the 
current user focus on this view or another within the window. But you still 
want to have different "Save..." handlers act, for different windows. right? 

So you'll put your -(IBAction)save:(id)sender; implementation in your 
WindowController. It is high enough in the view hierarchy, and in the responder 
chain to be always available (when some window is active), but when user 
switched between windows --- he'll have different responder-chains that lead 
(up the chain) to different window controllers!

I hope this explanation helps.

Motti Shneor, Mac OS X Software Architect & Team Leader
Spectrum Reflections Ltd.




___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: mutableBytes Creates Autoreleased Objects

[Ken Thomases]

On May 12, 2012, at 2:31 PM, Quincey Morris wrote:

> On May 12, 2012, at 10:17 , Ken Thomases wrote:
> 
>> That's not necessarily so.  And/or requesting the mutableBytes may do the 
>> equivalent of retain+autorelease on the NSMutableData.
>> 
>> Consider an inexact analog.  The -[NSString UTF8String] method seems to 
>> create an autoreleased NSData (or similar object) to hold the UTF-8-encoded 
>> C string that it returns.  It's not returning the NSData object, obviously, 
>> it's just using the autoreleased lifetime to manage the lifetime of the C 
>> string.
> 
> I think the difference is that for UTF8String, there is an API contract that 
> promises the result will be an object (and it has the lifetime behavior of 
> any returned object that is returned with +0 retain semantics, as the 
> documentation warns).
> 
> For mutableBytes, there's no API contract that it's an object at all, or that 
> it has any particular lifetime semantics if it is.

Well, you're the one who asserted something very concrete about when the 
interior pointer was deallocated.  You were claiming that Andreas couldn't have 
seen what he said he saw.  My point is that in the absence of a contract you 
can't be sure.

> If it was an object of some kind in Andrea's testing, that should be regarded 
> as luck.

Right, but Andreas wasn't looking to take advantage of the extended lifetime.  
The extended lifetime was a problem for him.  He was asking if it made sense 
that he needed to use an autorelease pool to ensure the data's lifetime was 
*not* extended.  You asserted that it could not make sense.  I asserted that it 
might.

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: multi-window document best practices?

[mlist0...@gmail.com]

On May 12, 2012, at 5:55 PM, Kyle Sluder wrote:

> You are correct that nothing in the docs prohibits passing the document as 
> the file's owner argument for window controllers you construct yourself. And 
> in the case of a single window controller, it might work—though this is not 
> guaranteed.

Huh. In NSDocument.h, it is written "The default implementation of 
(makeWindowControllers) ... creates a new window controller ..., specifying 
this document as the nib file's owner..."

Presumably, Apple is telling us this so we know how to do it ourselves. If this 
is a pattern we ought not emulate, this would be an ideal place to mention that.

> But if you have two or more window controllers, and you need to set the 
> window for each of them, then clearly the document's window property is not 
> the appropriate place for this.

It's not at all clear. 


> And it will result in multiple -awakeFomNib: messages being sent to your 
> NSDocument.

Heh, assuming awakeFromNib will only ever be called once is a newbie mistake 
I've made more than once ;)

I presume you meant windowControllerDidLoadNib: not awakeFromNib. I would 
*expect* multiple windowControllerDidLoadNib: calls, once for each nib loaded. 
That's perhaps why windowControllerDidLoadNib: has a windowController arg; so 
you can know which nib is being loaded and act appropriately. 

> The document-loads-nib pattern is explicitly documented as a convenience 
> wrapper around creating your own NSWindowController instance.

Yes, it is convenient.

> The window outlet on NSDocument exists solely for the purpose of supporting 
> this convenience.

I don't think so. I think it's there to support the convenience of having the 
nib's file's owner be the document, just like it is in the single window case.

If it were important that nibs should be built differently for single and 
multiple window cases, I'd think the docs would mention it someplace, but they 
don't.

_murat


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: multi-window document best practices?

[Kyle Sluder]

On May 12, 2012, at 5:42 PM, "mlist0...@gmail.com"  wrote:

> On May 12, 2012, at 4:45 PM, Kyle Sluder wrote:
> 
>> Document-as-File's-Owner only makes sense if you aren't overriding 
>> -makeWindowControllers.
> 
> I don't think that's the case. Certainly nothing in the docs suggest it. 

You are correct that nothing in the docs prohibits passing the document as the 
file's owner argument for window controllers you construct yourself. And in the 
case of a single window controller, it might work—though this is not guaranteed.

But if you have two or more window controllers, and you need to set the window 
for each of them, then clearly the document's window property is not the 
appropriate place for this. And it will result in multiple -awakeFomNib: 
messages being sent to your NSDocument.

The document-loads-nib pattern is explicitly documented as a convenience 
wrapper around creating your own NSWindowController instance. The window outlet 
on NSDocument exists solely for the purpose of supporting this convenience. I 
wouldn't be surprised if Apple's only anticipated use of the 'owner' argument 
of NSWindowController's initializer is also to support this convenience.

If you were to remove NSDocument from this equation entirely, it wouldn't make 
sense to pass anything other than the window controller as the File's Owner. 
Since you're not taking advantage of NSDocument's default NSWindowController 
instance, you probably shouldn't rely on pieces of that functionality to 
support your app.

(The rest of your post seems to imply you have come to the same understanding.)

--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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: multi-window document best practices?

[mlist0...@gmail.com]

On May 12, 2012, at 4:45 PM, Kyle Sluder wrote:

> Document-as-File's-Owner only makes sense if you aren't overriding 
> -makeWindowControllers.

I don't think that's the case. Certainly nothing in the docs suggest it. 

Went for a drive and reflected on this a bit. I think the fact that there's a 
setter for NSDocument's 'window' member but not a getter, and that the 
underlying _window member is private should have been clues. Furthermore, the 
documentation for setWindow: suggests that it has a role in the nib loading 
mechanism.

So I think my mistake was setting the window outlet in one nib but not the 
other. My approach was thwarting the very mechanism on which I was depending.

_murat
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: multi-window document best practices?

[Kyle Sluder]

On May 12, 2012, at 3:39 PM, "mlist0...@gmail.com"  wrote:

> I've have come across some surprising behavior when trying to implement a 
> document with two windows, each loaded from its own nib. 
> 
> In my NSDocument subclass, I have 
> 
> - (void) makeWindowControllers
> {
>NSWindowController* wc1 = [[[NSWindowController alloc] 
> initWithWindowNibName:@"MNKDocument" owner:self]autorelease];
>[self addWindowController:wc1];
>[wc1 window]; // loads nib the first time it's called.
> 
>NSLog(@"wc1->window = %@", [wc1 window]);
> 
> 
>NSWindowController* wc2 = [[[NSWindowController alloc] 
> initWithWindowNibName:@"MNKDocumentSecondWindow" owner:self] autorelease];
>[self addWindowController:wc2];
>[wc2 window]; // loads nib the first time it's called.
> 
>NSLog(@"wc2->window = %@", [wc2 window]);
> }
> 
> 
> wc1 is loading the default nib provided by Xcode's document-based app 
> template. wc2 is loading a nib I made by simply duplicating the default nib.
> 
> The "File's Owner" in both nibs is my document subclass. In the first nib 
> file, the "File's Owner" has its "window" outlet connected to the window in 
> the nib. Pretty vanilla.
> 
> In the second nib, the File Owner's "window" outlet is disconnected. The 
> window in the second nib is connected to the file owner's "secondWindow" 
> outlet.
> 
> After the nibs are loaded, I can see in the debugger that wc1->window points 
> to the correct window, but wc2->window is nil. WTF?

Document-as-File's-Owner only makes sense if you aren't overriding 
-makeWindowControllers.

Just make the window controllers themselves the File's Owner of the nib by 
passing 'nil' for the owner argument to the initializer in your override of 
-makeWindowControllers. Yes, that means a bit more refactoring might be 
necessary in your nibs.

--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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

multi-window document best practices?

[mlist0...@gmail.com]

I've have come across some surprising behavior when trying to implement a 
document with two windows, each loaded from its own nib. 

In my NSDocument subclass, I have 

- (void) makeWindowControllers
{
NSWindowController* wc1 = [[[NSWindowController alloc] 
initWithWindowNibName:@"MNKDocument" owner:self]autorelease];
[self addWindowController:wc1];
[wc1 window]; // loads nib the first time it's called.

NSLog(@"wc1->window = %@", [wc1 window]);


NSWindowController* wc2 = [[[NSWindowController alloc] 
initWithWindowNibName:@"MNKDocumentSecondWindow" owner:self] autorelease];
[self addWindowController:wc2];
[wc2 window]; // loads nib the first time it's called.

NSLog(@"wc2->window = %@", [wc2 window]);
}


wc1 is loading the default nib provided by Xcode's document-based app template. 
wc2 is loading a nib I made by simply duplicating the default nib.

The "File's Owner" in both nibs is my document subclass. In the first nib file, 
the "File's Owner" has its "window" outlet connected to the window in the nib. 
Pretty vanilla.

In the second nib, the File Owner's "window" outlet is disconnected. The window 
in the second nib is connected to the file owner's "secondWindow" outlet.

After the nibs are loaded, I can see in the debugger that wc1->window points to 
the correct window, but wc2->window is nil. WTF?

By experimenting, I have discovered that inside -[NSWindowController window], 
there is some magic happening. If owner->window is pointing at the window being 
loaded, the window controller's window member gets properly set. Otherwise, it 
does not.

That seems wrong, or at least very unexpected. And undocumented. 

Can anyone explain what's going on and why? And what the "right" way to do 
multiple windowed docs is?

_murat 
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: AwakeFromNib called twice for sheet

[Koen van der Drift]

On May 12, 2012, at 3:53 PM, Kyle Sluder wrote:

> t would be good for you to understand why this is happening.
> 
> When building a view-based table in IB, the NSTableCellView instances you see 
> are actually contained within embedded nibs. This makes sense, because nibs 
> are the standard mechanism by which Cocoa archives and instantiates view 
> instances.

Yes, I discovered that as well by putting a NSLog() inside awakeFromNib, it 
fired about eight times, which is the number of views that are visible in the 
tableview.

Glad I choose wisely to solve it.  I also found the WWDC 2011 video on View 
based tableviews, which has a lot of info. I am still struggling a bit with the 
layout and appearance of all the textviews inside the NSTableCellView, but I'm 
sure I'll get that figured out.

- Koen.
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: mutableBytes Creates Autoreleased Objects

[Quincey Morris]

On May 12, 2012, at 13:55 , Dave Fernandes wrote:

> So when a method is declared __attribute__ ((objc_returns_inner_pointer)), 
> then LLVM tracks regular pointers like it would NSObject pointers to see when 
> the owning object can be dealloced? Just want to make sure I understand.

… to see when the owning object's variable's compile time scope ends. Other 
retain/release optimizations aside, that would be the point where its retain 
count is decremented, and that might in turn trigger deallocation.

But, yes, basically that's how I understand the documentation. It seems *way* 
too convenient to be true. ;)


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: mutableBytes Creates Autoreleased Objects

[Dave Fernandes]

Cool! That would eliminate some of the gymnastics I have been going through to 
make sure I reference the NSData object some time after I use the internal 
bytes.

On 2012-05-12, at 5:05 PM, Quincey Morris wrote:

> On May 12, 2012, at 13:55 , Dave Fernandes wrote:
> 
>> So when a method is declared __attribute__ ((objc_returns_inner_pointer)), 
>> then LLVM tracks regular pointers like it would NSObject pointers to see 
>> when the owning object can be dealloced? Just want to make sure I understand.
> 
> … to see when the owning object's variable's compile time scope ends. Other 
> retain/release optimizations aside, that would be the point where its retain 
> count is decremented, and that might in turn trigger deallocation.
> 
> But, yes, basically that's how I understand the documentation. It seems *way* 
> too convenient to be true. ;)
> 
> 


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: mutableBytes Creates Autoreleased Objects

[Dave Fernandes]

On 2012-05-12, at 12:37 PM, Quincey Morris wrote:

> P.S. I think there's also another, better solution, but it involves adding a 
> method to NSData/NSMutableData via a category:
> 
>   - (void*) interiorBytes __attribute__ ((objc_returns_inner_pointer)) {
>   return self.bytes;
>   }
> 
>   - (void*) mutableInteriorBytes __attribute__ 
> ((objc_returns_inner_pointer)) {
>   return self.mutableBytes;
>   }
> 
> and never using bytes/mutableBytes directly ever again. Perhaps one day 
> bytes/mutableBytes will themselves be marked this way.

So when a method is declared __attribute__ ((objc_returns_inner_pointer)), then 
LLVM tracks regular pointers like it would NSObject pointers to see when the 
owning object can be dealloced? Just want to make sure I understand.

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: mutableBytes Creates Autoreleased Objects

[Quincey Morris]

On May 12, 2012, at 12:56 , Jens Alfke wrote:

> No; -[NSString UTF8String] returns a char*, not an object.

I meant "object" in the more general sense of a block of allocated memory whose 
lifetime is managed by a memory model. That includes (at least):

1. Obj-C objects.

2. CF…Ref objects.

3. A few special cases such as UTF8String, where the block is (apparently) 
autoreleased to keep it from deallocating instantly.

(In the GC case, these "objects" are blocks managed by the collector.)


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Accessibility issues with NSPopover

[Motti Shneor]

Thanks Curt, of course I tried that.  it is hard to tell when exactly nspopover 
creates and manipulates its opaque window. 

The real problem is, this call can only (hopefully) set the first responder of 
the popover. It can't make the whole popover active. For that you'd need 
something like makeKeyAndOrderFront which doesn't work either.

Motti shneor 
Senior software engineer & Team leader
Spectrum Reflections Ltd.
Sent from my iPhone


ב-11 במאי 2012, בשעה 19:22, Curt Clifton  כתב/ה:

> On May 10, 2012, at 2:06 AM, Motti Shneor wrote:
> 
>> does anybody know how to regain focus on an NSPopover after it lost user 
>> focus? (after another window becomes key and main) I could not do it. The 
>> only way I found was to close/delete the NSPopover and recreate it. Seems 
>> bad solution to me.
> 
> Just a guess here, but what happens if you call -[NSWindow 
> makeFirstResponder:] on the window containing the view to which the popover 
> is attached, passing one of the NSResponders from your popover as the 
> argument?
> 
> Although NSPopover has its own hidden window, it seems to hide some fairly 
> intimate connections to its host window.
> 
> Cheers,
> 
> Curt
> -
> Curt Clifton, PhD
> Software Engineer
> The Omni Group
> www.curtclifton.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: mutableBytes Creates Autoreleased Objects

[Charles Srstka]

On May 12, 2012, at 2:31 PM, Quincey Morris wrote:

> On May 12, 2012, at 10:18 , Charles Srstka wrote:
> 
>> Ugh, so you’re saying that ARC isn’t actually as deterministic as we’ve been 
>> led to believe?
> 
> Indeterminism isn't the problem. Unmarked interior pointers *are*.

But if the behavior is deterministic, you can predict where the NSMutableData 
will get dealloced, and so you’ll know for sure how long the interior pointer 
will be valid.

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: mutableBytes Creates Autoreleased Objects

[Jens Alfke]

On May 12, 2012, at 12:31 PM, Quincey Morris wrote:

> I think the difference is that for UTF8String, there is an API contract that 
> promises the result will be an object (and it has the lifetime behavior of 
> any returned object that is returned with +0 retain semantics, as the 
> documentation warns).

No; -[NSString UTF8String] returns a char*, not an object.

The difference is that -UTF8String has to allocate new memory to hold the 
result, because it's not in the same format as the internal string data (which 
is either UTF-16 or MacRoman and not null-terminated.) I believe internally it 
creates an autoreleased NSData and returns a pointer to its -bytes.

-mutableBytes doesn't (and shouldn't!) allocate anything; it just hands back a 
raw pointer to the NSData's bytes. But what it look like (as Ken said) is that 
the implementation of -mutableBytes calls [[self retain] autorelease] to avoid 
a situation where the caller releases the NSMutableData but still wants to use 
the bytes. The retain+autorelease ensures that the object and its bytes hang on 
until the inner autorelease pool is drained. In other words, I don't believe 
-mutableBytes allocates any data, but it does prolong the lifespan of its 
receiver.

—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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: AwakeFromNib called twice for sheet

[Kyle Sluder]

On May 12, 2012, at 6:26 AM, Koen van der Drift  
wrote:

> I solved it by using windowDidLoad instead of awakeFromNib.

It would be good for you to understand why this is happening.

When building a view-based table in IB, the NSTableCellView instances you see 
are actually contained within embedded nibs. This makes sense, because nibs are 
the standard mechanism by which Cocoa archives and instantiates view instances.

The standard -tableView:viewForTableColumn:row: boilerplate delegate method 
just calls -makeViewWithIdentifier:owner: on the table view to unarchive the 
desired table cell view from the table view's embedded nib. When you use 
bindings with a view-based table view, *and* you use the same identifier for 
the table cell view as you do for an NSTableColumn, NSTableView can save you 
from having to implement this method, and just passes the table column's 
identifier and the delegate as the File's Owner.

But the key is the 'owner' argument. All nibs need a File's Owner, and on Mac 
OS X this object is sent -awakeFromNib as part of the nib loading. This is 
different from iOS, which does not send -awakeFromNib to File's Owner.

Since NSTableView's convenience implementation needs to pass an owner, it 
passes the delegate. This is what most boilerplate implementations do as well. 
But the delegate object itself almost certainly lives in or owns the nib that 
the table view lives in. It will have already received -awakeFromNib during the 
instantiation of this master nib. The commonality of this pattern is why the 
NSTableView documentation specifically warns about this scenario.

Your solution of moving your "master nib did load" code to -windowDidLoad is a 
wise one. In general, I've started to favor moving all code out of 
NSWindowController -awakeFromNib into -windowDidLoad, and only using 
-awakeFromNib for initializing objects that themselves live in nibs. It would 
be very nice if NSViewController had a matching -viewDidLoad (as it does on 
iOS), since unlike window controllers, view controllers are quite likely to 
live inside a nib themselves and this be ripe for *triple* invocations of 
-awakeFromNib (once when their containing nib loads, once when the nib they own 
loads, and once for each table cell view nib is instantiated).

--Kyle Sluder

> 
> - Koen.
> 
> 
> On May 12, 2012, at 8:01 AM, Koen van der Drift wrote:
> 
>> Hi,
>> 
>> My app (OSX) has a sheet to obtain data from a server and display them in an 
>> NSTableView. So far I was using a Cell based table and it worked fine. 
>> Yesterday I decided to make the table view based, following the instruction 
>> by Apple 
>> 
>>   The only difference with that code is that I don't bind the 
>> arraycontroller to the appdelegate, but to the viewcontroller of the sheet 
>> (the file's owner).  The objects in my search array are dictionaries, so in 
>> the Attributes panel for the array controller, I added the keys of the dict 
>> I want to bind my table to. This works fine, and the retrieved data is 
>> displayed in the table. 
>> 
>> But after the search when the table is displayed, awakeFromNib is called 
>> again for the sheet, and all my data is gone.  I did some debugging, and the 
>> first time it is called as follows:
>> 
>> #00x00014cff in -[SheetController awakeFromNib]
>> #10x7fff8ce18a41 in -[NSIBObjectData 
>> nibInstantiateWithOwner:topLevelObjects:] ()
>> #20x7fff8ce0ef73 in loadNib ()
>> #30x7fff8ce0e470 in +[NSBundle(NSNibLoading) 
>> _loadNibFile:nameTable:withZone:ownerBundle:] ()
>> #40x7fff8ce0e38b in +[NSBundle(NSNibLoading) 
>> loadNibFile:externalNameTable:withZone:] ()
>> #50x7fff8cffac34 in -[NSWindowController loadWindow] ()
>> #60x7fff8cffa9ef in -[NSWindowController window] ()
>> #70x00012ad0 in -[AppDelegate showSheet:] 
>> 
>> 
>> 
>> The second time this happens:
>> 
>> #00x00014cff in -[SheetController awakeFromNib]
>> #10x7fff8ce18a41 in -[NSIBObjectData 
>> nibInstantiateWithOwner:topLevelObjects:] ()
>> #20x7fff8cf3851b in -[NSNib instantiateNibWithExternalNameTable:] ()
>> #30x7fff8cf4b301 in -[NSTableRowData 
>> _unarchiveViewWithIdentifier:owner:] ()
>> #40x7fff8cf4b0b7 in -[NSTableRowData makeViewWithIdentifier:owner:] 
>> ()
>> #50x7fff8cf4afc9 in -[NSTableView makeViewWithIdentifier:owner:] ()
>> #60x7fff8cf4ae11 in -[NSTableView(NSTableViewViewBased) 
>> makeViewForTableColumn:row:] ()
>> #70x7fff8cf4aa95 in -[NSTableRowData 
>> _addViewToRowView:atColumn:row:] ()
>> #80x7fff8cf4a8b0 in -[NSTableRowData _addViewsToRowView:atRow:] ()
>> #90x7fff8cf49543 in -[NSTableRowData 
>> _addRowViewForVisibleRow:withPriorView:] ()
>> #100x7fff8cf49342

Re: AwakeFromNib called twice for sheet

[Jens Alfke]

On May 12, 2012, at 5:01 AM, Koen van der Drift wrote:

> But after the search when the table is displayed, awakeFromNib is called 
> again for the sheet, and all my data is gone.

-awakeFromNib is called for each object in a loaded nib … including the nib 
'owner' object. That means it's possible for it to be called multiple times. It 
looks like what happens in your case is that the first call comes when the 
window nib is loaded, and the second when the nib containing the view for the 
table loads (probably because your controller is its owner?)

> I solved it by using windowDidLoad instead of awakeFromNib.

That's the best solution, since the meaning of -windowDidLoad is more specific.

—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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: mutableBytes Creates Autoreleased Objects

[Quincey Morris]

On May 12, 2012, at 10:17 , Ken Thomases wrote:

> That's not necessarily so.  And/or requesting the mutableBytes may do the 
> equivalent of retain+autorelease on the NSMutableData.
> 
> Consider an inexact analog.  The -[NSString UTF8String] method seems to 
> create an autoreleased NSData (or similar object) to hold the UTF-8-encoded C 
> string that it returns.  It's not returning the NSData object, obviously, 
> it's just using the autoreleased lifetime to manage the lifetime of the C 
> string.

I think the difference is that for UTF8String, there is an API contract that 
promises the result will be an object (and it has the lifetime behavior of any 
returned object that is returned with +0 retain semantics, as the documentation 
warns).

For mutableBytes, there's no API contract that it's an object at all, or that 
it has any particular lifetime semantics if it is. If it was an object of some 
kind in Andrea's testing, that should be regarded as luck. Note that the 
documentation for mutable bytes *explicitly* warns that it may point to 
different things in different frameworks releases.

On May 12, 2012, at 10:18 , Charles Srstka wrote:

> Ugh, so you’re saying that ARC isn’t actually as deterministic as we’ve been 
> led to believe?

Indeterminism isn't the problem. Unmarked interior pointers *are*.

> On the headers on my system, bytes and mutableBytes *are* marked that way.


Yes, they're marked on my OS X 10.7 SDK. They're not marked on my iOS 5.1 SDK, 
which was the one I happened to look at.

This means that the time of deallocation of any private memory object that 
mutableBytes might refer to is affected by at least the following factors:

1. The optimization level. (Might shorten the compile-time scope of the 
NSMutableData object by varying amounts.)

2. The SDK in use. (Might keep the compile-time scope of the NSMutableData 
object longer based on interior pointers, or not.)

3. Whether the internals of NSMutableData use autorelease. (May vary in 
different frameworks versions, or for NSMutableData objects created with 
different initializer and/or parameters.)

4. Whether the NSMutableData is autoreleased for any other reason.

There's no free lunch here, unless the interior-pointer-returning methods are 
known to be marked as such. Then ARC hands out very free lunches indeed. :)


P.S. Hmm. The scope extension from marked interior pointers doesn't really seem 
to be memory-model specific. I wonder if clang also hands out free lunches to 
GC code using marked interior pointers. That would be nice.


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: mutableBytes Creates Autoreleased Objects

[Charles Srstka]

On May 12, 2012, at 12:17 PM, Ken Thomases wrote:

> That's not necessarily so.  And/or requesting the mutableBytes may do the 
> equivalent of retain+autorelease on the NSMutableData.
> 
> Consider an inexact analog.  The -[NSString UTF8String] method seems to 
> create an autoreleased NSData (or similar object) to hold the UTF-8-encoded C 
> string that it returns. It's not returning the NSData object, obviously, it's 
> just using the autoreleased lifetime to manage the lifetime of the C string.
> 
> Anyway, NSMutableData *could* be doing something similar.  I don't know if it 
> is or isn't.  I believe that Andreas is saying that his testing shows that it 
> is.  If it is, Apple may have done this specifically to avoid a problem with 
> internal pointers in ARC.

It looks like that’s indeed what it’s doing. I put a category on NSData to 
swizzle out its dealloc to something that would log that it was getting 
dealloced, and then ran a few test cases. Here’s where the data object got 
dealloced each time:

int main(int argc, const char * argv[]) {
@autoreleasepool {
const char *bytes = "abcd";

{
NSMutableData *data = [[NSMutableData alloc] initWithBytes:bytes 
length:4];

NSLog(@"leaving block");
} // data gets dealloced here
NSLog(@"left block");
}
return 0;
}

int main(int argc, const char * argv[]) {
@autoreleasepool {
const char *bytes = "abcd";
char *mutableBytes;

{
NSMutableData *data = [[NSMutableData alloc] initWithBytes:bytes 
length:4];
mutableBytes = [data mutableBytes];

NSLog(@"leaving block");
}
NSLog(@"left block");
} // data gets dealloced here
return 0;
}

int main(int argc, const char * argv[]) {
@autoreleasepool {
const char *bytes = "abcd";
char *mutableBytes;

@autoreleasepool {
NSMutableData *data = [[NSMutableData alloc] initWithBytes:bytes 
length:4];
mutableBytes = [data mutableBytes];

NSLog(@"leaving autoreleasepool block");
} // data gets dealloced here
NSLog(@"left autoreleasepool block");
}
return 0;
}

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: mutableBytes Creates Autoreleased Objects

[Charles Srstka]

On May 12, 2012, at 11:37 AM, Quincey Morris wrote:

> No, the pointer returned by 'mutableBytes' is an interior pointer. It *isn't* 
> an object pointer. (Well, as an implementation detail, it may happen to point 
> to an object's memory, but it often doesn't.)
> 
> As soon as the NSMutableData's lifetime ends -- when it reaches its dealloc 
> -- the 'mutableBytes' pointer becomes instantly invalid.
> 
> Interestingly, this appears to mean that NSData/NSMutableData has become as 
> dangerous in ARC as it is in GC. The compiler may shorten the lifetime of an 
> object variable so that the interior pointer is catastrophically invalidated. 
> This is documented in section 6.1 of the clang ARC spec:
> 
>   http://clang.llvm.org/docs/AutomaticReferenceCounting.html#optimization

Ugh, so you’re saying that ARC isn’t actually as deterministic as we’ve been 
led to believe?

> but it also give an answer:
> 
>   NSMutableData* data __attribute__ ((objc_precise_lifetime)) = …
> 
> P.S. I think there's also another, better solution, but it involves adding a 
> method to NSData/NSMutableData via a category:
> 
>   - (void*) interiorBytes __attribute__ ((objc_returns_inner_pointer)) {
>   return self.bytes;
>   }
> 
>   - (void*) mutableInteriorBytes __attribute__ 
> ((objc_returns_inner_pointer)) {
>   return self.mutableBytes;
>   }
> 
> and never using bytes/mutableBytes directly ever again. Perhaps one day 
> bytes/mutableBytes will themselves be marked this way.

On the headers on my system, bytes and mutableBytes *are* marked that way.

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: mutableBytes Creates Autoreleased Objects

[Ken Thomases]

On May 12, 2012, at 11:37 AM, Quincey Morris wrote:

> No, the pointer returned by 'mutableBytes' is an interior pointer. It *isn't* 
> an object pointer. (Well, as an implementation detail, it may happen to point 
> to an object's memory, but it often doesn't.)
> 
> As soon as the NSMutableData's lifetime ends -- when it reaches its dealloc 
> -- the 'mutableBytes' pointer becomes instantly invalid.

That's not necessarily so.  And/or requesting the mutableBytes may do the 
equivalent of retain+autorelease on the NSMutableData.

Consider an inexact analog.  The -[NSString UTF8String] method seems to create 
an autoreleased NSData (or similar object) to hold the UTF-8-encoded C string 
that it returns.  It's not returning the NSData object, obviously, it's just 
using the autoreleased lifetime to manage the lifetime of the C string.

Anyway, NSMutableData *could* be doing something similar.  I don't know if it 
is or isn't.  I believe that Andreas is saying that his testing shows that it 
is.  If it is, Apple may have done this specifically to avoid a problem with 
internal pointers in ARC.

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: mutableBytes Creates Autoreleased Objects

[Quincey Morris]

On May 12, 2012, at 08:27 , Andreas Grosam wrote:

> It seems, sending mutableBytes creates autoreleased objects (currently, 
> tested with ARC only).
> Anybody experienced this, too?
> 
> In code as below this may severely impact performance and tie up lots of 
> memory, which are apparently dependent on the size of the mutable data:
> 
> for (int i = 0; i < BigValue; ++i) {
>NSMutableData* data = [[NSMutableData alloc] initWithCapacity:bigSize];
>char* p = [data mutableBytes];
>...
> 
>// data released by ARC
> }
> 
> I could alleviate the problem by wrapping around an autorelease pool:
> 
> 
> for (int i = 0; i < BigValue; ++i) 
> {
>NSMutableData* data = [[NSMutableData alloc] initWithCapacity:bigSize];
>char* p;
>@autoreleasepool {
>   char* p = [data mutableBytes];
> }
>...
> }

No, the pointer returned by 'mutableBytes' is an interior pointer. It *isn't* 
an object pointer. (Well, as an implementation detail, it may happen to point 
to an object's memory, but it often doesn't.)

As soon as the NSMutableData's lifetime ends -- when it reaches its dealloc -- 
the 'mutableBytes' pointer becomes instantly invalid.

Interestingly, this appears to mean that NSData/NSMutableData has become as 
dangerous in ARC as it is in GC. The compiler may shorten the lifetime of an 
object variable so that the interior pointer is catastrophically invalidated. 
This is documented in section 6.1 of the clang ARC spec:

http://clang.llvm.org/docs/AutomaticReferenceCounting.html#optimization

but it also give an answer:

NSMutableData* data __attribute__ ((objc_precise_lifetime)) = …

P.S. I think there's also another, better solution, but it involves adding a 
method to NSData/NSMutableData via a category:

- (void*) interiorBytes __attribute__ ((objc_returns_inner_pointer)) {
return self.bytes;
}

- (void*) mutableInteriorBytes __attribute__ 
((objc_returns_inner_pointer)) {
return self.mutableBytes;
}

and never using bytes/mutableBytes directly ever again. Perhaps one day 
bytes/mutableBytes will themselves be marked this 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

mutableBytes Creates Autoreleased Objects

[Andreas Grosam]

It seems, sending mutableBytes creates autoreleased objects (currently, tested 
with ARC only).
Anybody experienced this, too?

In code as below this may severely impact performance and tie up lots of 
memory, which are apparently dependent on the size of the mutable data:

for (int i = 0; i < BigValue; ++i) {
NSMutableData* data = [[NSMutableData alloc] initWithCapacity:bigSize];
char* p = [data mutableBytes];
...

// data released by ARC
}

I could alleviate the problem by wrapping around an autorelease pool:


for (int i = 0; i < BigValue; ++i) 
{
NSMutableData* data = [[NSMutableData alloc] initWithCapacity:bigSize];
char* p;
@autoreleasepool {
char* p = [data mutableBytes];
 }
...
}

(In practice, it would probably be more kosher to wrap the whole block within 
the loop. I did it so just to illustrate where the autoreleased objects will be 
created.)


Honestly, that seems quite strange.
I also would expect this to be mentioned in the docs.


Regards
Andreas
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Accelerate framework

[Roland King]

Grr .. again with the moderation for size .. can you not use rich text or 
something, it just makes a 6k message into a 50k one and this list has a really 
small max message size. Sending the mail yet again .. 

 original mail follows with the rich text turned into plain --


I said CGImageCreate, I think that's what you want, you certainly don't have a 
PNG, you have a bitmap of data, a raw buffer. I think you probably have the 
right data provider, that or use CGCreateDataProviderDirect() which looks the 
same for raw data but works directly with the buffer, but just plain 
CGImageCreate() looks like the function which takes raw bytes in an expressed 
format and makes the image. Definitely the PNGDataProvider is wrong, you don't 
have one of those. 

> 
>  On May12, 2012, at 9:27 PM, Luca Ciciriello wrote:
> 
> Now I've used the code: where 
> 
> CGDataProviderRef provider = CGDataProviderCreateWithData(NULL, outData, 
> (768 * 768 * 4), NULL);
> CGImageRef test = CGImageCreateWithPNGDataProvider(provider, nil, true, 
> kCGRenderingIntentDefault); 
> 
> where outData is the output of my EmbossEffect function.
> 
> Here "provider" is valorized, but "test" is 0x0. 
> My suspect is that vImageConvolve_ARGB is working with bitmap and a 
> CGImageCreateWithPNGDataProvider is working with PNG, but I haven't found an 
> equivalent function for Bitmap.
> 
> Luca.
> 
> 


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: AwakeFromNib called twice for sheet

[Koen van der Drift]

I solved it by using windowDidLoad instead of awakeFromNib.

- Koen.


On May 12, 2012, at 8:01 AM, Koen van der Drift wrote:

> Hi,
> 
> My app (OSX) has a sheet to obtain data from a server and display them in an 
> NSTableView. So far I was using a Cell based table and it worked fine. 
> Yesterday I decided to make the table view based, following the instruction 
> by Apple 
> 
>   The only difference with that code is that I don't bind the arraycontroller 
> to the appdelegate, but to the viewcontroller of the sheet (the file's 
> owner).  The objects in my search array are dictionaries, so in the 
> Attributes panel for the array controller, I added the keys of the dict I 
> want to bind my table to. This works fine, and the retrieved data is 
> displayed in the table. 
> 
> But after the search when the table is displayed, awakeFromNib is called 
> again for the sheet, and all my data is gone.  I did some debugging, and the 
> first time it is called as follows:
> 
> #00x00014cff in -[SheetController awakeFromNib]
> #10x7fff8ce18a41 in -[NSIBObjectData 
> nibInstantiateWithOwner:topLevelObjects:] ()
> #20x7fff8ce0ef73 in loadNib ()
> #30x7fff8ce0e470 in +[NSBundle(NSNibLoading) 
> _loadNibFile:nameTable:withZone:ownerBundle:] ()
> #40x7fff8ce0e38b in +[NSBundle(NSNibLoading) 
> loadNibFile:externalNameTable:withZone:] ()
> #50x7fff8cffac34 in -[NSWindowController loadWindow] ()
> #60x7fff8cffa9ef in -[NSWindowController window] ()
> #70x00012ad0 in -[AppDelegate showSheet:] 
> 
> 
> 
> The second time this happens:
> 
> #00x00014cff in -[SheetController awakeFromNib]
> #10x7fff8ce18a41 in -[NSIBObjectData 
> nibInstantiateWithOwner:topLevelObjects:] ()
> #20x7fff8cf3851b in -[NSNib instantiateNibWithExternalNameTable:] ()
> #30x7fff8cf4b301 in -[NSTableRowData 
> _unarchiveViewWithIdentifier:owner:] ()
> #40x7fff8cf4b0b7 in -[NSTableRowData makeViewWithIdentifier:owner:] ()
> #50x7fff8cf4afc9 in -[NSTableView makeViewWithIdentifier:owner:] ()
> #60x7fff8cf4ae11 in -[NSTableView(NSTableViewViewBased) 
> makeViewForTableColumn:row:] ()
> #70x7fff8cf4aa95 in -[NSTableRowData _addViewToRowView:atColumn:row:] 
> ()
> #80x7fff8cf4a8b0 in -[NSTableRowData _addViewsToRowView:atRow:] ()
> #90x7fff8cf49543 in -[NSTableRowData 
> _addRowViewForVisibleRow:withPriorView:] ()
> #10   0x7fff8cf49342 in -[NSTableRowData 
> _addRowViewForVisibleRow:withPriorRowIndex:inDictionary:withRowAnimation:] ()
> #11   0x7fff8cf49288 in -[NSTableRowData _addRowViewForVisibleRow:] ()
> #12   0x7fff8cf489cc in -[NSTableRowData _unsafeUpdateVisibleRowEntries] 
> ()
> #13   0x7fff8cf487e7 in -[NSTableRowData updateVisibleRowViews] ()
> #14   0x7fff8cee0f04 in -[NSTableView viewWillDraw] ()
> #15   0x7fff8ce455bc in -[NSView viewWillDraw] ()
> #16   0x7fff8ce455bc in -[NSView viewWillDraw] ()
> #17   0x7fff8ce45e4a in -[NSScrollView viewWillDraw] ()
> #18   0x7fff8ce455bc in -[NSView viewWillDraw] ()
> #19   0x7fff8ce455bc in -[NSView viewWillDraw] ()
> #20   0x7fff8ce44301 in -[NSView 
> _sendViewWillDrawInRect:clipRootView:suppressRecursion:] ()
> #21   0x7fff8ce43070 in -[NSView displayIfNeeded] ()
> #22   0x7fff8ce42a2d in 
> _handleWindowNeedsDisplayOrLayoutOrUpdateConstraints ()
> #23   0x7fff93176f40 in __NSFireTimer ()
> #24   0x7fff917f4934 in 
> __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ ()
> #25   0x7fff917f4486 in __CFRunLoopDoTimer ()
> #26   0x7fff917d4e11 in __CFRunLoopRun ()
> #27   0x7fff917d4486 in CFRunLoopRunSpecific ()
> #28   0x7fff95d794d3 in RunCurrentEventLoopInMode ()
> #29   0x7fff95d80781 in ReceiveNextEventCommon ()
> #30   0x7fff95d8060e in BlockUntilNextEventMatchingListInMode ()
> #31   0x7fff8ce06e31 in _DPSNextEvent ()
> #32   0x7fff8ce06735 in -[NSApplication 
> nextEventMatchingMask:untilDate:inMode:dequeue:] ()
> #33   0x7fff8ce03071 in -[NSApplication run] ()
> #34   0x7fff8d07f244 in NSApplicationMain ()
> #35   0x00012472 in main
> 
> I can see there that the table view somehow triggers an additional nib 
> instantiation (lines #5 -> #1). So obviously I messed up somewhere when 
> changing from a cell to a view based table. What change could I have done 
> (accidentally) when changing to a view based table that could cause this? Any 
> tips for debugging this?
> 
> Thanks,
> 
> - Koen.
> 
> 


___

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/Un

Re: Accelerate framework

[Roland King]

.. got moderated for size .. so I'll send again .. I think perhaps the 
formatted code in your mail was on the ragged edge for the list ... Scott feel 
free to axe the original version of this message if you see it when doing the 
moderation queue ... 

 original message --`

I'm guessing from my quick read of a few pages of the documentation whilst 
watching formula1 but I don't think you can do that. You went through a 
CGImageRef,  I would expect you have to go back through it. I don't think 
UIImage will take what looks like a pretty raw buffer, it's only for a limited 
set of formats. I, were I trying this, would be looking at CGImageCreate with a 
CGDataProviderRef which just rips right out of your data buffer and then make a 
UIImage with that.  

This is me guessing but it's what I'd try if I were doing this. I don't know if 
there is a better way to get the initial bytes by the way, there may be, slow 
drawing into a bitmap context but quite possibly right. Will be interested to 
see other replies here. 

> Me to, first time I use the accelerate framework and I haven't found any 
> sample code in order to help me in my first step.
> 
> Here the code I use: 
> 
> CGImageRef inImage = [[UIImage imageNamed:@"estate3.jpg"] CGImage];
> CGContextRef cgctx = CreateARGBBitmapContext(inImage);
> 
> // Get image width, height. We'll use the entire image.
> size_t w = CGImageGetWidth(inImage);
> size_t h = CGImageGetHeight(inImage);
> CGRect rect = {{0,0},{w,h}};
> 
> // Draw the image to the bitmap context. Once we draw, the memory 
> // allocated for the context for rendering will then contain the 
> // raw image data in the specified color space.
> CGContextDrawImage(cgctx, rect, inImage);
> 
> void *inData = CGBitmapContextGetData (cgctx);
> void *outData = malloc(768 * 768 * 4);
> unsigned int inRowBytes= 768 * 4;
> unsigned int outRowBytes   = 768 * 4;
> unsigned int height= 768;
> unsigned int width = 768;
> unsigned int kernel_height = 3;
> unsigned int kernel_width  = 3;
> int divisor = 2;
> vImage_Flags flags = kvImageLeaveAlphaUnchanged;
> 
> 
> int res = EmbossEffect(inData, inRowBytes, outData, outRowBytes, height, 
> width, kernel_height, kernel_width, divisor, flags);
> if(res != kvImageNoError)
> {
> NSLog(@"Manipulation Error");
> }
> 
>No exit error here. Then … Here
> 
>   NSData *imgData = [[NSData alloc] initWithBytes:outData length:(768 * 
> 768 * 4)];
> 
>UIImage *retrivedImage = [UIImage imageWithData:imgData];  /// 1)
>[imageView setImage:retrivedImage];
>   
>Here in 1) the "retrievedImage" is 0x0.
> 
> The function EmbosEffect is:
> 
> int EmbossEffect(void *inData,
>  unsigned int inRowBytes,
>  void *outData,
>  unsigned int outRowBytes,
>  unsigned int height,
>  unsigned int width,
>  unsigned int kernel_height,
>  unsigned int kernel_width,
>  int  divisor,
>  vImage_Flags flags)
> {
> 
> int16_t kernel[]   = {-2, -2, 0, -2, 6, 0, 0, 0, 0};
> vImage_Buffer src  = { inData, height, width, inRowBytes };
> vImage_Buffer dest = { outData, height, width, outRowBytes };
> unsigned char bgColor[4] = { 0, 0, 0, 0 };
> vImage_Error  err = 0;
> 
> err = vImageConvolve_ARGB(&src,  //const 
> vImage_Buffer *src
>   &dest, //const 
> vImage_Buffer *dest,
>   NULL,
>   0, 
> //unsigned int srcOffsetToROI_X,
>   0, 
> //unsigned int srcOffsetToROI_Y,
>   kernel,//const 
> signed int *kernel,
>   kernel_height, 
> //unsigned int
>   kernel_width,  
> //unsigned int
>   divisor,   //int
>   bgColor,
>   flags | kvImageBackgroundColorFill 
> //vImage_Flags flags 
>   );
> 
> return err;
> }
> 
> Luca.

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Accelerate framework

[Roland King]

Never used the framework but my first thought would be to create a CGImageRef 
which can take directly formatted data (I'm assuming that vImages are just a 
byte buffer) and then make a UIImage from there. 

What did you do to get a vImage from your UIImage in the first place? 

On May 12, 2012, at 8:26 PM, Luca Ciciriello wrote:

> Now my problem is:
> How can I rebuild an UIImage from the output of the vImageConvolve_ARGB 
> elaboration?
> I can't find any code sample on this.
> 
> L.
> On May 12, 2012, at 11:16 AM, Luca Ciciriello wrote:
> 
>> Yes You are right. It was a my stupid syntax error.
>> 
>> L.
>> 
>> On May 12, 2012, at 10:34 AM, Ken Thomases wrote:
>> 
>>> On May 12, 2012, at 3:25 AM, Luca Ciciriello wrote:
>>> 
 Using the accelerate framework in iOS 5.1 I've imported the header 
 Accelerate/Accelerate.h and in my code I'm using the line:
 
 uint_8 kernel = {-2, -2, 0, -2, 6, 0, 0, 0, 0};
 
 My problem is that I've got the error:
 
 "Use of undeclared identifier uint_8".
 
 Which is the header I've to use for uint_8?
>>> 
>>> Do you perhaps mean uint8_t?  Certainly, the Accelerate framework won't 
>>> require you to use any type which it hasn't included the definition for.
>>> 
>>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/luca_ciciriello%40hotmail.com
>> 
>> This email sent to luca_cicirie...@hotmail.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:
> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
> 
> This email sent to r...@rols.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Accelerate framework

[Luca Ciciriello]

Now my problem is:
How can I rebuild an UIImage from the output of the vImageConvolve_ARGB 
elaboration?
I can't find any code sample on this.

L.
On May 12, 2012, at 11:16 AM, Luca Ciciriello wrote:

> Yes You are right. It was a my stupid syntax error.
> 
> L.
> 
> On May 12, 2012, at 10:34 AM, Ken Thomases wrote:
> 
>> On May 12, 2012, at 3:25 AM, Luca Ciciriello wrote:
>> 
>>> Using the accelerate framework in iOS 5.1 I've imported the header 
>>> Accelerate/Accelerate.h and in my code I'm using the line:
>>> 
>>> uint_8 kernel = {-2, -2, 0, -2, 6, 0, 0, 0, 0};
>>> 
>>> My problem is that I've got the error:
>>> 
>>> "Use of undeclared identifier uint_8".
>>> 
>>> Which is the header I've to use for uint_8?
>> 
>> Do you perhaps mean uint8_t?  Certainly, the Accelerate framework won't 
>> require you to use any type which it hasn't included the definition for.
>> 
>> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/luca_ciciriello%40hotmail.com
> 
> This email sent to luca_cicirie...@hotmail.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

AwakeFromNib called twice for sheet

[Koen van der Drift]

Hi,

My app (OSX) has a sheet to obtain data from a server and display them in an 
NSTableView. So far I was using a Cell based table and it worked fine. 
Yesterday I decided to make the table view based, following the instruction by 
Apple 

  The only difference with that code is that I don't bind the arraycontroller 
to the appdelegate, but to the viewcontroller of the sheet (the file's owner).  
The objects in my search array are dictionaries, so in the Attributes panel for 
the array controller, I added the keys of the dict I want to bind my table to. 
This works fine, and the retrieved data is displayed in the table. 

But after the search when the table is displayed, awakeFromNib is called again 
for the sheet, and all my data is gone.  I did some debugging, and the first 
time it is called as follows:

#0  0x00014cff in -[SheetController awakeFromNib]
#1  0x7fff8ce18a41 in -[NSIBObjectData 
nibInstantiateWithOwner:topLevelObjects:] ()
#2  0x7fff8ce0ef73 in loadNib ()
#3  0x7fff8ce0e470 in +[NSBundle(NSNibLoading) 
_loadNibFile:nameTable:withZone:ownerBundle:] ()
#4  0x7fff8ce0e38b in +[NSBundle(NSNibLoading) 
loadNibFile:externalNameTable:withZone:] ()
#5  0x7fff8cffac34 in -[NSWindowController loadWindow] ()
#6  0x7fff8cffa9ef in -[NSWindowController window] ()
#7  0x00012ad0 in -[AppDelegate showSheet:] 



The second time this happens:

#0  0x00014cff in -[SheetController awakeFromNib]
#1  0x7fff8ce18a41 in -[NSIBObjectData 
nibInstantiateWithOwner:topLevelObjects:] ()
#2  0x7fff8cf3851b in -[NSNib instantiateNibWithExternalNameTable:] ()
#3  0x7fff8cf4b301 in -[NSTableRowData 
_unarchiveViewWithIdentifier:owner:] ()
#4  0x7fff8cf4b0b7 in -[NSTableRowData makeViewWithIdentifier:owner:] ()
#5  0x7fff8cf4afc9 in -[NSTableView makeViewWithIdentifier:owner:] ()
#6  0x7fff8cf4ae11 in -[NSTableView(NSTableViewViewBased) 
makeViewForTableColumn:row:] ()
#7  0x7fff8cf4aa95 in -[NSTableRowData _addViewToRowView:atColumn:row:] 
()
#8  0x7fff8cf4a8b0 in -[NSTableRowData _addViewsToRowView:atRow:] ()
#9  0x7fff8cf49543 in -[NSTableRowData 
_addRowViewForVisibleRow:withPriorView:] ()
#10 0x7fff8cf49342 in -[NSTableRowData 
_addRowViewForVisibleRow:withPriorRowIndex:inDictionary:withRowAnimation:] ()
#11 0x7fff8cf49288 in -[NSTableRowData _addRowViewForVisibleRow:] ()
#12 0x7fff8cf489cc in -[NSTableRowData _unsafeUpdateVisibleRowEntries] 
()
#13 0x7fff8cf487e7 in -[NSTableRowData updateVisibleRowViews] ()
#14 0x7fff8cee0f04 in -[NSTableView viewWillDraw] ()
#15 0x7fff8ce455bc in -[NSView viewWillDraw] ()
#16 0x7fff8ce455bc in -[NSView viewWillDraw] ()
#17 0x7fff8ce45e4a in -[NSScrollView viewWillDraw] ()
#18 0x7fff8ce455bc in -[NSView viewWillDraw] ()
#19 0x7fff8ce455bc in -[NSView viewWillDraw] ()
#20 0x7fff8ce44301 in -[NSView 
_sendViewWillDrawInRect:clipRootView:suppressRecursion:] ()
#21 0x7fff8ce43070 in -[NSView displayIfNeeded] ()
#22 0x7fff8ce42a2d in 
_handleWindowNeedsDisplayOrLayoutOrUpdateConstraints ()
#23 0x7fff93176f40 in __NSFireTimer ()
#24 0x7fff917f4934 in 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ ()
#25 0x7fff917f4486 in __CFRunLoopDoTimer ()
#26 0x7fff917d4e11 in __CFRunLoopRun ()
#27 0x7fff917d4486 in CFRunLoopRunSpecific ()
#28 0x7fff95d794d3 in RunCurrentEventLoopInMode ()
#29 0x7fff95d80781 in ReceiveNextEventCommon ()
#30 0x7fff95d8060e in BlockUntilNextEventMatchingListInMode ()
#31 0x7fff8ce06e31 in _DPSNextEvent ()
#32 0x7fff8ce06735 in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#33 0x7fff8ce03071 in -[NSApplication run] ()
#34 0x7fff8d07f244 in NSApplicationMain ()
#35 0x00012472 in main

I can see there that the table view somehow triggers an additional nib 
instantiation (lines #5 -> #1). So obviously I messed up somewhere when 
changing from a cell to a view based table. What change could I have done 
(accidentally) when changing to a view based table that could cause this? Any 
tips for debugging this?

Thanks,

- Koen.



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

ARC and static functions, free functions and C++ member functions

[Andreas Grosam]

I would like to define a static function which returns a newly created object, 
for example:

static Foo* makeFoo(const char* arg) {
  return [[Foo alloc] initWithArg:arg];
}


Do I need to use __attribute__((ns_returns_retained)), or is the above 
definition already correct as it is?



Furthermore, are ARC rules fully applied within static functions and free 
functions? For example:

Foo*  makeFoo(const char* str) __attribute__((ns_returns_retained));
Foo*  makeFoo(const char* str) {
NSString* s = [[NSString alloc] initWithCString:str encoding:Encoding];
Foo* result = [[Foo alloc] initWithString:s];
return result;
}

Is local variable 's' released properly?




Furthermore is ARC fully applied within member functions of C++ classes? 
For example:

// Objective-C++
#import "Foo.h"

class foo {
public:
foo(const std::string& s = "default") : _s(s) {}

Foo* makeFoo() const {
NSString* s = [[NSString alloc] initWithCString:_s.c_str() 
encoding:Encoding];
Foo* result = [[Foo alloc] initWithString:s];
return result;
}

private:
std::string _s;
};

…

#include "foo.h"
@implementation Bar {
foo _foo;
}
- (Foo*) newFoo {
return _foo.makeFoo();
}
@end


If that works, how would I have to declare the C++ member function makeFoo(), 
considering two cases:
1) makeFoo is inlined and defined within the class definition 
2) makeFoo is defined out of line within a foo.cpp module



Thanks for help!


Regards
Andreas
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Accelerate framework

[Luca Ciciriello]

Yes You are right. It was a my stupid syntax error.

L.

On May 12, 2012, at 10:34 AM, Ken Thomases wrote:

> On May 12, 2012, at 3:25 AM, Luca Ciciriello wrote:
> 
>> Using the accelerate framework in iOS 5.1 I've imported the header 
>> Accelerate/Accelerate.h and in my code I'm using the line:
>> 
>> uint_8 kernel = {-2, -2, 0, -2, 6, 0, 0, 0, 0};
>> 
>> My problem is that I've got the error:
>> 
>> "Use of undeclared identifier uint_8".
>> 
>> Which is the header I've to use for uint_8?
> 
> Do you perhaps mean uint8_t?  Certainly, the Accelerate framework won't 
> require you to use any type which it hasn't included the definition for.
> 
> 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Accelerate framework

[Ken Thomases]

On May 12, 2012, at 3:25 AM, Luca Ciciriello wrote:

> Using the accelerate framework in iOS 5.1 I've imported the header 
> Accelerate/Accelerate.h and in my code I'm using the line:
> 
> uint_8 kernel = {-2, -2, 0, -2, 6, 0, 0, 0, 0};
> 
> My problem is that I've got the error:
> 
> "Use of undeclared identifier uint_8".
> 
> Which is the header I've to use for uint_8?

Do you perhaps mean uint8_t?  Certainly, the Accelerate framework won't require 
you to use any type which it hasn't included the definition for.

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Accelerate framework

[Roland King]

uint_8?

Do you mean uint8_t? 


On May 12, 2012, at 4:25 PM, Luca Ciciriello wrote:

> Hi All. A simple question.
> Using the accelerate framework in iOS 5.1 I've imported the header 
> Accelerate/Accelerate.h and in my code I'm using the line:
> 
> uint_8 kernel = {-2, -2, 0, -2, 6, 0, 0, 0, 0};
> 
> My problem is that I've got the error:
> 
> "Use of undeclared identifier uint_8".
> 
> Which is the header I've to use for uint_8?
> 
> Thanks in advance for any answer.
> 
> Luca.
> 
> 
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
> 
> This email sent to r...@rols.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Accelerate framework

[Luca Ciciriello]

Hi All. A simple question.
Using the accelerate framework in iOS 5.1 I've imported the header 
Accelerate/Accelerate.h and in my code I'm using the line:

uint_8 kernel = {-2, -2, 0, -2, 6, 0, 0, 0, 0};

My problem is that I've got the error:

"Use of undeclared identifier uint_8".

Which is the header I've to use for uint_8?

Thanks in advance for any answer.

Luca.


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com