Re: Profound UITableView rendering-performance problem, but only at certain positions?

Thanks for that suggestion. I'm only reloading visible cells, so I would expect them to already be instantiated and readily available in memory. However, if cellForRow... is called, I guess there is an attempt to dequeue. I'd have to take a look at how much time is spent in that method. At any

Re: Forcing Core Data to save attribute changed behind its back?

On Mon, Jul 23, 2012 at 3:03 PM, Sean McBride wrote: > when I change it, instead of the usual setAttribute:newValue I mutate the > object directly. > - will/didChangeValueForKeyPath: but that's not a sufficient 'kick' Out of random curiousity, does this big mutable object you're updating change

Re: Forcing Core Data to save attribute changed behind its back?

What do you try to win by changing the attribute bind CD's back? If you want to take it out of undo you might switch it off temporarily (e.g. [undoManager disableUndoRegistration], or store the undo manager in a local, set the context's undo to nil, and restore it - which may or may not cause t

Re: Profound UITableView rendering-performance problem, but only at certain positions?

On Jul 24, 2012, at 2:48 AM, Gavin Stokes wrote: > And performance isn't the only issue; the rendering is defective, with > elements (like simple text labels) being rendered slightly out of position > and cell images flying up from the bottom of the screen and settling into > place. Typically i

Re: Forcing Core Data to save attribute changed behind its back?

On Tue, 24 Jul 2012 15:15:16 +0200, Peter Hartmann said: >What do you try to win by changing the attribute bind CD's back? Run time performance. The data is large and changes frequently. >If you want to take it out of undo you might switch it off temporarily >(e.g. [undoManager disableUndoRegis

Re: How to get a Service into the "Search" group?

Answered my own question (which it turns out was asked three years ago, more than once): I've filed rdar://11945677. --Andy On Jul 17, 2012, at 4:49 PM, Andy Lee wrote: > I've added a system service to my app. I'd like it

Is it 'normal' that scrolling in a UIScrollView leaks some bytes?

I can answer it myself: no, it should not be considered normal that an app leaks memory, and that is why it makes me quite nervous. What happens is this: In an iPad / iPhone project I present a few UIImageViews on-screen. They are contained within their own UIScrollViews as I want to zoom in an

Re: Is it 'normal' that scrolling in a UIScrollView leaks some bytes?

I believe this is a known bug in UIScrollview (search for "strdup leak in UIScrollview"). Wouldn't hurt to file a bug with Apple (which will probably be marked a duplicate). Aaron On Jul 24, 2012, at 10:28 AM, Richard Altenburg (Brainchild) wrote: > I can answer it myself: no, it should not be

Re: Is it 'normal' that scrolling in a UIScrollView leaks some bytes?

Op 24 jul. 2012, om 19:28 heeft Richard Altenburg (Brainchild) het volgende geschreven: > Leaked Object: Malloc 48 Bytes Here is a deep copy of the call stack inside which this leak happened: Bytes Used # Leaks Symbol Name 48 Bytes 100.0% 1 main 48 Bytes

Re: NSDocument -canCloseDocumentWithDelegate::: not called when terminating

On 7/23/12 6:27 PM, Markus Spoettl wrote: On 7/23/12 5:42 PM, Fritz Anderson wrote: Perhaps I'm missing something — is writing the preferences file very time-consuming? If not, why not write it whether you need to or not? Or whenever a preferences value changes, which is what you'd do with NSUse

Why is NSDocument reverting so rudimentary?

Hello, more out of curiosity, I wonder why document reverting does not provide the same level of abstraction loading and writing does? There's only -revertToContentsOfURL:::. By contrast I can load and write documents by using abstract -readFromData::: and -dataOfType:: or -readFromFileWra

Re: Forcing Core Data to save attribute changed behind its back?

On Tue, 24 Jul 2012 05:31:22 -0700, Sixten Otto said: >> when I change it, instead of the usual setAttribute:newValue I mutate >the object directly. >> - will/didChangeValueForKeyPath: but that's not a sufficient 'kick' > >Out of random curiousity, does this big mutable object you're updating >ch

Re: Why is NSDocument reverting so rudimentary?

Reverting a document calls through to -readFromURL:… internally. The read and write methods are primitive, and not intended to be called directly. The save, init, and revert methods are the higher level API designed for calling directly. On 24 Jul 2012, at 19:13, Markus Spoettl wrote: > Hello

Re: Why is NSDocument reverting so rudimentary?

OK, thanks for setting me straight and sorry for the noise. I could have sworn it didn't work yesterday. It does. Regards Markus On 7/24/12 8:30 PM, Mike Abdullah wrote: Reverting a document calls through to -readFromURL:… internally. The read and write methods are primitive, and not intended

Re: Forcing Core Data to save attribute changed behind its back?

On Tue, Jul 24, 2012 at 11:27 AM, Sean McBride wrote: > Yes. My object is a subclass of NSObject and I don't override isEqual:. As > I test, I overrode it and always return NO. At first, I thought this did the > trick, since Core Data passed through this and saved properly; but alas, it > on

-mouseDragged: sent to view when dragging window

Hello, when I drag my window around by clicking into the toolbar area and drag from there, and I do very rapid up-down movements across the entire screen, sometimes AppKit - mistakenly - sends a -mouseDragged: to my view situated below the toolbar. The call stack looks like this: #1 0

Re: Forcing Core Data to save attribute changed behind its back?

On Jul 23, 2012, at 15:03 , Sean McBride wrote: > I have a managed object where one of the attributes is quite large and so > when I change it, instead of the usual setAttribute:newValue I mutate the > object directly. Of course, Core Data does not know that I've done this. > I'm looking for

Re: -mouseDragged: sent to view when dragging window

On Jul 24, 2012, at 13:36 , Markus Spoettl wrote: > My view reacts to -mouseDragged: but doesn't check if there's been a > -mouseDown: first because that's implicit. Did that change? The Cocoa Event Handling Guide says "Mouse events are dispatched by an NSWindow object to the NSView object over

Re: Is it 'normal' that scrolling in a UIScrollView leaks some bytes?

Thank you Aaron and Julius for pointing out it is a known bug. I can not check the developer forums as I am not on a developer program just yet. I should have checked by searching on the web, sorry that this time I poured my problem right into the mailing list. As this is a known bug, Apple won

CGDisplayRegisterReconfigurationCallback not called when view in fullscreen

Anyone familiar with CGDisplayRegisterReconfigurationCallback callback and fullscreen when connecting and disconnecting an external monitor? I have written an application that places a custom NSView into fullscreen (using enterfullscreenmode with options) on an external monitor while the main w

Re: CGDisplayRegisterReconfigurationCallback not called when view in fullscreen

On Jul 24, 2012, at 7:47 PM, Tom Hohensee wrote: > Anyone familiar with CGDisplayRegisterReconfigurationCallback callback and > fullscreen when connecting and disconnecting an external monitor? > I have written an application that places a custom NSView into fullscreen > (using enterfullscreenmo

Re: CGDisplayRegisterReconfigurationCallback not called when view in fullscreen

Ken You are right. I was capturing the screen. Setting the presentation options in the options dictionary for enterFullScreenMode with options: did the trick. However, with the presentation options set, I am only getting one view to show the other is blacked out (ie the view on the external mo