On Jul 27, 2012, at 10:36 AM, Curt Clifton wrote:
> On Jul 27, 2012, at 8:55 AM, Nick Zitzmann wrote:
>
>> But I need to be able to see **all** invocations of the method from **all**
>> NSViews to catch the culprit, because I have a rather complicated view
>> hierarchy, including some views
On Fri, Jul 27, 2012, at 08:55 AM, Nick Zitzmann wrote:
> But I need to be able to see **all** invocations of the method from
> **all** NSViews to catch the culprit, because I have a rather complicated
> view hierarchy, including some views for which I don't have the source,
> and I don't know exac
On Jul 27, 2012, at 8:55 AM, Nick Zitzmann wrote:
> But I need to be able to see **all** invocations of the method from **all**
> NSViews to catch the culprit, because I have a rather complicated view
> hierarchy, including some views for which I don't have the source, and I
> don't know exact
On Jul 27, 2012, at 2:35 AM, Markus Spoettl wrote:
> On 7/27/12 5:10 AM, Nick Zitzmann wrote:
>> I've got a view that, according to Quartz Debug, is invalidating a large and
>> unnecessary portion of the view when certain user events happen.
>>
>> The problem is, I have no idea what is causing
On 7/27/12 5:10 AM, Nick Zitzmann wrote:
I've got a view that, according to Quartz Debug, is invalidating a large and
unnecessary portion of the view when certain user events happen.
The problem is, I have no idea what is causing this to happen. What
strategies are best for debugging the -setNee
I've got a view that, according to Quartz Debug, is invalidating a large and
unnecessary portion of the view when certain user events happen.
The problem is, I have no idea what is causing this to happen. What strategies
are best for debugging the -setNeedsDisplayInRect: method to find out
spec
