Are you overriding NSOpenSavePanelDelegate -panel:shouldEnableURL:? If so,
make sure your code isn’t inadvertently disabling the folder for some reason.
Doing those steps in TextEdit works fine for me. Maybe ask the user to try the
same steps with TextEdit Open dialog and see if the behavior
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
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
>
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
NSDistributedNotificationCenter is a way to send a notification out across the
system. Only processes that are listening for the notification will receive it
and have a chance to do something with it. It’s like yelling out in a crowded
room to tell a single person something. Everyone will hear
Yeah, you might be able to send out a distributed notification and have the
menuling listen for it. When it receives it it can kill itself or go through
the normal teardown/quit procedure.
—Rob
> On Jul 25, 2023, at 6:15 AM, Alex Zavatone via Cocoa-dev
> wrote:
>
> What if you called a
The order of the screens can change under various user scenarios. One easy one
is simply re-arranging the displays, or even moving the menu bar thing from one
display to another in the Arrange UI Displays prefs pane. Obviously plugging &
unplugging displays or closing a laptop with an external
> On May 1, 2023, at 5:04 AM, Gabriel Zachmann wrote:
>
> Thanks so much again!
>
> I tried, and it didn't give me a good clue, though.
> What I got as output is:
> All zones: 1466 nodes malloced - Sizes: 117040KB[25] 96KB[25] 8KB[2] 5.5KB[1]
> 5KB[1] 4KB[2] 3KB[3] 2.5KB[2] 2KB[4] 1.5KB[4]
number of objects. That
might narrow down what object(s) are eating your memory. Good luck.
—Rob
> On Apr 30, 2023, at 12:31 PM, Rob Petrovec via Cocoa-dev
> wrote:
>
> Hey,
> Since you have unbounded memory growth, you will likely have one or
> more object types with
pointer to it.
>>
>> If you want, we could do a video meeting and I could guide you through it.
>>
>> Will reply with the memory querying function.
>>
>> Cheers,
>> Alex Zavatone
>>
>> Sent from my iPhone
>>
>>&
Hey,
Since you have unbounded memory growth, you will likely have one or
more object types with a TON of instances in the list on the left. They are
likely the source, or part of a chain of objects eating your memory.
MallocStackLogging doesn’t show more info about a possible cause.
This sounds like Abandoned Memory, not a leak. Abandoned memory is a retain
cycle somewhere. Best/easiest way to find those is with a memgraph. Click the
little sideways V icon in Xcode’s debugger when the problem is reproducing.
Or run ‘leaks MyApp --outputGraph ~’ in Terminal when the
NSCollectionView, like NSTableView/NSOutlineView, will reuse existing views
instead of recreating them when it can to speed up the UI. This is most
commonly used during scrolling where views that scroll out of view will be
reused with new data and scrolled into view. It will call
Yes, this is a bug that started in 11.7 that doesn’t appear to have been fixed
yet in 11.7.2.
Have you tried the arguably more robust and less error prone runtime checks of:
Swift
if #available(macOS 10.16, *) {
// macOS 10.16 or later code path
} else {
// code for earlier than
Is it always going to be the same search? If so, you could create a Saved
Search in the Finder and include it with your app. Then when you want to bring
up the search you can open the Saved Search bundle and it will open in the
Finder. Hope that helps.
—Rob
> On Dec 13, 2022, at 1:10 PM,
> On Apr 19, 2022, at 5:26 PM, Sean McBride via Cocoa-dev
> wrote:
>
> On 19 Apr 2022, at 18:47, Saagar Jha wrote:
>
>> If Thread Sanitizer says your code has a race, it almost certainly has a
>> race.
>
> Yeah, that's been my general experience until now.
>
>> Your simple code seems OK
> On Mar 20, 2022, at 11:41 AM, Quincey Morris
> wrote:
>
> (Resending because I forgot to cc the list)
>
> On Mar 20, 2022, at 08:09, Gabriel Zachmann via Cocoa-dev
> wrote:
>>
>> Apparently, this caused it:
>>
>> Symbol not found: _AVAudioSessionInterruptionNotification
>>
>> Yes, I am
> On Mar 20, 2022, at 9:09 AM, Gabriel Zachmann wrote:
>
> I have now the crash report.
>
> Apparently, this caused it:
>
> Symbol not found: _AVAudioSessionInterruptionNotification
>
> Yes, I am using that function, and yes, it seems to be available only on
> macOS 11 and higher.
>
> My
> On Mar 18, 2022, at 1:11 PM, Gabriel Zachmann wrote:
>
>>> I am trying to build my app for macOS 10.12 (Sierra).
>>>
>>> First of all, is it correct that I need to build it for "My Mac" , not do a
>>> niversal build (Any Mac)?
>> If you are only building to debug it then My Mac is
> On Mar 18, 2022, at 8:47 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> I am trying to build my app for macOS 10.12 (Sierra).
>
> First of all, is it correct that I need to build it for "My Mac" , not do a
> niversal build (Any Mac)?
If you are only building to debug it then My
Accessibility for NSControls is handled by the NSCell inside it, not the
NSControl. Good luck.
—Rob
> On Mar 13, 2022, at 7:55 AM, Eyal Redler via Cocoa-dev
> wrote:
>
> Hi,
>
> I'm having trouble getting a custom NSControl subclass properly visible with
> regards to accessibility.
>
>
Quit Xcode, delete the DerivedData directory for your project and re-open your
project. That should trigger a re-index and a full rebuild of your product.
The default location for the DerivedData directory is in
~/Library/Developer/Xcode/DerivedData/-. You can also configure it to be in your
The text in an error dialog is typically a washed down version of the actual
error. See if you can get the user to give you a sysdiagnose log, taken just
after reproducing the problem, so you can check out the .logarchive to see what
the actual error was from the system. It should provide
> On Jun 25, 2021, at 2:40 PM, Andreas Falkenhahn via Cocoa-dev
> wrote:
>
> On 25.06.2021 at 18:54 Carl Hoefs wrote:
>
>> So I think it's safe to say that something has changed, and you're not
>> fighting fantoms...
>
> Do you think this should be reported to Apple or will nobody care
You are using deprecated cell based table views/API. I would advise switching
to view based API (available in macOS 10.7 and newer). Cell based was
deprecated in 10.10 back in 2014.
With that said, I would create an NSTextFieldCell subclass (if you haven’t
already) and stuff it into the text
> (It goes without saying that on my system everything runs fine, both on macOS
> 10.15.4 and macOS 11.3.1.)
Since the problem appears to happen on 10.15.0, but not 10.15.4 and
newer, I would just chalk it up to a bug in the OS and ask your customer to
update to at least 10.15.4. I’m
To trigger a sysdiagnose:
- reproduce the problem
- Hold down Shift-Control-Option-Command-‘.’ (period) for a few seconds
- After a couple minutes a Finder window will appear with a
“sysdiagnose….tar.gz" archive pre-selected. You want that archive.
- Once you have the archive, uncompress it and
AppKit is pretty good at logging failures like this. I would look for messages
in the system.logs (or better yet from a sysdiagnose archive) from your process
as well as com.apple.appkit.xpc.openAndSavePanelService (the process that
actually shows the open/save panel). See if there are any
Don’t forget to include a sample app that demonstrates the problem.
—Rob
> On Mar 26, 2021, at 12:02 PM, Gary L. Wade via Cocoa-dev
> wrote:
>
> Try surrounding the call with beginEditing and endEditing on the text
> storage. If it still happens, submit a feedback to Apple with the full
That error message is less than helpful. Does the current user have
permissions to write to that directory, let alone to the file being replaced?
if not, no amount of entitlements will let you do what you want.
—Rob
> On Mar 14, 2021, at 3:43 AM, Allan Odgaard via Cocoa-dev
> wrote:
>
>
Yes, Ben is correct. One thing to note, when you report the bug if you can
supply a test project showing the behavior in Obj-C and another project showing
the behavior in Swift that would likely give this bug a lot more traction.
Good luck.
—Rob
> On Nov 22, 2020, at 2:08 PM, Ben Kennedy
No problem. Looks like a bug about to clarify the documentation is in order.
—Rob
> On Nov 5, 2020, at 2:35 PM, Dragan Milić via Cocoa-dev
> wrote:
>
>> čet 05.11.2020., at 20:57, Rob Petrovec wrote:
>>
>> Check out NSTableViewStylePlain
>
> Yes Rob, that was it, thanks a lot!! And now I
Check out NSTableViewStylePlain
—Rob
> On Nov 5, 2020, at 12:28 PM, Dragan Milić via Cocoa-dev
> wrote:
>
> Hi all,
>
> What would be the best approach to set custom insets of the contentView
> (NSClipView) of a NSScrollView? I’ll try to describe the problem in more
> details…
>
> I’m
PLEASE PLEASE PLEASE don’t put up a modal dialog in the middle of a drag. All
drags are done on the main thread. This includes calls to NSDraggingSource,
NSDraggingDestination, NSFilePromiseProvider, NSFilePromiseReceiver methods and
drag methods from NSTableView/NSOutlineVIew &
> On Oct 26, 2020, at 10:00 PM, Steven Mills via Cocoa-dev
> wrote:
>
>
>> On Oct 26, 2020, at 17:49:59, James Walker via Cocoa-dev
>> wrote:
>>
>> I don't see any "Download Debug Symbols" in the Organizer. I don't think it
>> exists for macOS apps.
>>
>> However, one can right-click
As was pointed out by an earlier reply, even if you use -layout or
setAutoresizingMask you are still using auto layout. The frame changes get
converted to auto layout constraints under the hood. If you said “without
using Autolayout API” that would be more correct.
—Rob
> On Oct 17, 2020,
I don’t know the answer to your question. However,I would move your time table
up significantly on testing your app with Big Sur if I were you. There are a
lot of changes in Big Sur that will definitely effect your app. Most notably
drastic UI changes, not to mention the API & behavior
You want LSCopyApplicationURLsForBundleIdentifier
—Rob
> On Jul 16, 2020, at 6:24 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> Is there a way to find the paths/URLs to all app bundles that have the same
> bundle ID?
>
> I have a user who likes to make duplicates of my app (it does make
I don’t have an answer to your question, but to add some clarity Points are
scale factor independent unit of measurement. On a retina display there are 2
pixels per point. On a non-retina display there is 1 pixel per point. Say
Apple comes out with a display with a scale factor of 17. That
> On May 27, 2020, at 2:37 PM, Martin Wierschin wrote:
>
>> Auto layout (not auto-resizing) is independent of localization. You don’t
>> need to switch to auto layout to support Base localization
>
> It's true that autolayout has many benefits aside from localization. But I'd
> say it's
Auto layout (not auto-resizing) is independent of localization. You don’t need
to switch to auto layout to support Base localization. So you can convert your
nibs over to Base Localization with a couple clicks in Xcode, and then you just
need .strings and .stringdict files in your .lprojs
> On May 27, 2020, at 1:08 PM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
>>>
>>> I've just had a crash in
>>> CGImageSourceCreateThumbnailAtIndex( new_image, 0, imageOpts );
>>
>> We went through this quite a while ago in private emails.
>> CGImageSourceCreateThumbnailAtIndex is fine to
I have never used AppleGlot. However, I’m curious why you don’t set up a
.lproj for each localization you support containing .strings files with your
translated strings inside?
—Rob
> On May 27, 2020, at 10:04 AM, Eyal Redler via Cocoa-dev
> wrote:
>
> Hi,
>
> It looks like Apple has
> On May 22, 2020, at 8:42 AM, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 23 Apr 2020, at 21:15, Rob Petrovec wrote:
>
>> If what you say is correct then everyone would be seeing a delay since most
>> people don’t have blazing fast internet connections. I do not think this is
>> the
Yes, there is more than one way to skin a cat. Use whatever methods work for
you. But keep in mind that your experiences may not be the same as others
because your code base is obviously going to be different. So I would not
recommend avoiding one tool over another just because it didn’t
I’ve had a lot of success with Instruments leaks traces. In the retain/release
world we live in, knowing the backtrace to where the object was created isn’t
enough. Instruments gives a nice UI to walk the retain/release history of an
object, and the backtrace of each
> On May 8, 2020, at 12:19 PM, Jens Alfke via Cocoa-dev
> wrote:
>
>
>
>> On May 8, 2020, at 9:53 AM, Gabriel Zachmann via Cocoa-dev
>> wrote:
>>
>> So, I was thinking, maybe it helps to load the next image concurrently,
>> while the current one is still being displayed.
>
> Sure. Just
Have you considered using a workspace to handle building all of your individual
projects? That should solve your file path & linking problem.
btw, the 28 character string is a UUID. I’m not sure about its lifetime.
—Rob
> On May 7, 2020, at 9:57 PM, Richard Charles via Cocoa-dev
> wrote:
I thought when everything goes wonky you zap the PRAM and rebuild the Desktop?
—Rob
> On Apr 29, 2020, at 3:45 PM, Carl Hoefs via Cocoa-dev
> wrote:
>
> When everything goes wonky... it's time to reinstall all of Xcode...!
>
> *sigh*
> -Carl
>
>
>
> On Apr 23, 2020, at 8:35 PM, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 24 Apr 2020, at 2:28, Gabriel Zachmann via Cocoa-dev wrote:
>
>>> I believe that is why you are supposed to staple notarization tickets to
>>> your apps.
>> Then, why would it "phone home" in case there is an
> On Apr 23, 2020, at 7:30 PM, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 24 Apr 2020, at 2:18, Rob Petrovec wrote:
>
>> I get a 1 second time for the first run and then a much quicker time for the
>> second. I did some sampling and the longer time due to is Apple’s check for
>> malware
> On Apr 23, 2020, at 9:10 AM, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 23 Apr 2020, at 21:15, Rob Petrovec wrote:
>
>> If what you say is correct then everyone would be seeing a delay since most
>> people don’t have blazing fast internet connections. I do not think this is
>> the
If what you say is correct then everyone would be seeing a delay since most
people don’t have blazing fast internet connections. I do not think this is
the normal behavior. I think it is specific to your system, otherwise there
would be TONS of people complaining about slowness. A couple
>> I think you are right about this being a permission / “sandbox” issue,
>> because the 3 folders in question are all folders that macOS 10.15 now
>> require special permission to read (even though in my case, I just request
>> their display name).
Yes, this is because of iCloud. Log
I assume you have iCloud enabled. If so, these three folders are ’special’.
Try logging out of iCloud & rebooting and see if the problem persists.
I would also recommend filing a bug with Apple and include a sysdiagnose taken
while the problem was reproducing (sudo sysdiagnose). Or at least
> On Mar 23, 2020, at 8:01 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
I would not do this. It is widely documented that AppKit API that produce
UI elements, like NSOpenPanel, are _not_ thread safe.
>>>
>>> Right, and that is why I have to execute any UI code in the main
I would not do this. It is widely documented that AppKit API that produce UI
elements, like NSOpenPanel, are _not_ thread safe. So you may find your app
hitting some memory stomping issues or strange crashes/exceptions due to this.
Specifically what problems you will hit are anyones guess,
No you can’t one an NSOpenPanel on a secondary thread. UI elements must be on
the main thread.
—Rob
> On Mar 21, 2020, at 1:05 PM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> Is it possible to open an NSOpenPanel in a secondary thread?
>
> I create the thread like this:
>
>
> On Jan 10, 2020, at 6:36 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> Steve, thanks a lot for your response!
>
>>>
>>> In my screensaver, I try to search the Pictures directory in the user's
>>> home.
>>> It is OK - for now - if my app cannot access any .photoslibrary, but I'd
>>>
.
—Rob
> On Dec 31, 2019, at 1:34 AM, Eyal Redler wrote:
>
>>
>> On 30 Dec 2019, at 2:09, Rob Petrovec via Cocoa-dev
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>>
>> I honestly think this is fall out from copiesOnScroll being deprecated and
&g
I honestly think this is fall out from copiesOnScroll being deprecated and the
clip view always behaving as if it was set to true. My guess is you will see
the same problems in your apps if you ran them on Mojave with copiesOnScroll
set to true. In which case you need to update your app to
From
https://developer.apple.com/documentation/appkit/nsclipview/1532142-copiesonscroll?language=objc
copiesOnScroll
A Boolean value that indicates if the clip view copies rendered images while
scrolling.
Discussion
When the value of this property is YES, the clip view copies its existing
> On Nov 20, 2019, at 9:28 AM, Pier Bover wrote:
>
> > Its not Apples fault if you were not aware. They were both highly talked
> > about during their respective WWDC events.
>
> The vast majority of developers do not go to the WWDC and do not have time to
> watch the dozens (hundreds?) of
> On Nov 19, 2019, at 6:24 PM, Pier Bover wrote:
>
> > When/if Apple decides to deprecate Cocoa they will announce it many years
> > ahead of time
>
> Like they did with 32 bits and OpenGL deprecation?
Yes, exactly. 32Bit was deprecated in 2012 and officially killed in
2019.
The sky is not falling. When/if Apple decides to deprecate Cocoa they will
announce it many years ahead of time, like they did for Carbon back in 2012
(which was only officially killed in 2019). They typically make announcements
like that at a WWDC. They aren’t going to stop supporting it
+1
Also, the reference docs can be toggled between Obj-C & Swift via the
“Language” popup at the top of the page.
—Rob
> On Nov 19, 2019, at 9:48 AM, Steve Mills via Cocoa-dev
> wrote:
>
> You should use an external poll site for this rather than filling the list
> with yet another thread
> On Nov 14, 2019, at 1:13 PM, Pier Bover wrote:
>
> > I wouldn’t be so pessimistic about macOS or even iOS update rates.
>
> According to StatCounter Mojave never went above 52% or market share, which
> means at its peak 48% of users were still on previous versions.
>
>
I wouldn’t be so pessimistic about macOS or even iOS update rates. Its
considerably quicker than you think. IMS, they announce upgrade rates during
public earnings report conference calls typically to brag about how well a new
OS is being received by the public over previous releases or
> On Oct 24, 2019, at 5:16 PM, James Walker via Cocoa-dev
> wrote:
>
> On 10/24/19 3:57 PM, Rob Petrovec via Cocoa-dev wrote:
>>> On Oct 24, 2019, at 4:50 PM, Stephane Sudre wrote:
>>>
>>> On Fri, Oct 25, 2019 at 12:38 AM Rob Petrovec via Cocoa-dev
>
> On Oct 24, 2019, at 4:50 PM, Stephane Sudre wrote:
>
> On Fri, Oct 25, 2019 at 12:38 AM Rob Petrovec via Cocoa-dev
> wrote:
>> If its a ranty bug report, which apparently happens a lot, it goes into a
>> black-hole never to see the light of day if it doesn’t just
> On Oct 24, 2019, at 4:01 PM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
>>>
>>>
>>>
>>> https://developer.apple.com/account/#/feedback-assistant
>>>
>>> https://developer.apple.com/account/#/forums
>>
>>
>> Good luck with that. I've been using OSX/macOS since the Panther days and
>>
> On Sep 26, 2019, at 5:43 PM, James Walker via Cocoa-dev
> wrote:
>
> On 9/26/19 4:20 PM, Gabriel Zachmann via Cocoa-dev wrote:
>>> The issue in the below code to my eye is that you allocate a path with
>>> CGPathCreateWithRect (+1) but then don't release it.
>>>
>>> In that case, I am
> On Sep 26, 2019, at 5:20 PM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
>> The issue in the below code to my eye is that you allocate a path with
>> CGPathCreateWithRect (+1) but then don't release it.
>>
>> In that case, I am wondering:
>> doesn't ownership pass to the textlayer ?
>> If
> On Sep 25, 2019, at 2:52 PM, Rob Petrovec via Cocoa-dev
> wrote:
>
>> Is it safe to do it after assigning the nsimage to the layer, but before
>> deleting the layer?
> I would think so, but it is hard to say without knowing what
> convertToNSImage:withOrie
> Is it safe to do it after assigning the nsimage to the layer, but before
> deleting the layer?
I would think so, but it is hard to say without knowing what
convertToNSImage:withOrientation actually does under the hood. It likely
either retains or copies it. In either case, your
> On Aug 10, 2019, at 3:38 PM, Uli Kusterer
> wrote:
>
>> On 10. Aug 2019, at 19:03, Rob Petrovec via Cocoa-dev
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>>
>>> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev
>>> mailto:coc
> On Aug 10, 2019, at 3:12 PM, Kurt Bigler wrote:
>
> On 8/10/19 10:03:00 AM, Rob Petrovec wrote:
>>> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev
>>> wrote:
>>>
>>> The NSView subclasses involved are receiving drawRect: messages but are not
>>> receiving mouseDown:.
>
>>
> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev
> wrote:
>
> The NSView subclasses involved are receiving drawRect: messages but are not
> receiving mouseDown:.
You need to implement NSView -hitTest: to get mouseDown events.
—Rob
I would not recommend using those deprecated API. They are not long for this
world. With that said, I don’t have a better solution.
—Rob
> On Jul 25, 2019, at 7:03 PM, Dragan Milić via Cocoa-dev
> wrote:
>
>> On pet 26.10.2019,. at 02.37, Steve Mills via Cocoa-dev wrote:
>>
>> Use the
79 matches
Mail list logo
