To be clear, CGImageForProposedRect doesn’t have ‘Create’ in the name. So the
'Create Rule' doesn’t apply. But it is an easy thing to overlook.
—Rob
> On Aug 24, 2023, at 2:35 AM, JPH wrote:
>
> Thanks to all of you
> The CFRelease(imageRef); was the problem and the CFRelease(subImageRef);
ARC only affects Objective-C objects. It has no effect on CF objects like
CGImageRefs, CFArrayRefs, CFDictionaryRefs etc. If you play with CF objects in
an ARC app you still need to release them. You don’t need to release Obj-C
objects and the compiler will warn you if you try to.
—Rob
> On
Thanks to all of you
The CFRelease(imageRef); was the problem and the CFRelease(subImageRef); is OK
My fault was then to apply the old days « Create rule » , bypassing ARC !
I was misled by Instruments/Leaks which reports a leak, which meant to me that
I had to look for a missing release, no
You mention ARC… aren’t you not supposed to explicitly release objects under
ARC? Am I misunderstanding?
Sandor
> On Aug 23, 2023, at 18:48, JPH via Cocoa-dev
> wrote:
>
> Hello friends,
>
> The enclosed procedure is producing a NSImage from another NSImage, by
> cropping in a NSRect.
>
Got a small sample we could play with? I would expect the crash on explicit
release as it would cause a double release.
I tend to ignore I strums to with leaks and use the Memory Graph debugger
religiously.
If you have a little sample showing this, I would be happy to test a bit with
it.
Che
CGImageForProposedRect returns an autoreleased CGImageRef, so your
CFRelease(imageRef) is an overrelease and likely the cause of your problem.
The rest of the code looks fine, including the release of subImageRef (if it
was uncommented).
—Rob
> On Aug 23, 2023, at 4:47 PM, JPH via Cocoa-dev
Hello friends,
The enclosed procedure is producing a NSImage from another NSImage, by
cropping in a NSRect.
The resulting sub-Image feeds an imageView in the APP Interface and the may
change frequently, then being hopefully disposed by ARC
The last line of the procedure :
NSImage *subImage
