Now I feel stupid.
For efficiency, my code was caching the values for the second column,
but I never cleared that cache before trying to refresh that column.
The browser was refreshing the (now incorrect) cached values - clearing
my cache out so that it was rebuilt fixed my issue.
Sorry fo
Is there a way to disabled the Apple crash reporter dialog?
I want to use PLCrashReporter and show my UI instead.
I don't want to confuse the user by having to fill out two crash reports.
So far I only found a ways to turn if off completely:
sudo launchctl unload -w
/System/Library/LaunchDaemo
Sorry, yes I see now!! Will try that out and let you know!
Sent from my iPhone
> On 07 Mar 2015, at 13:43, Ken Thomases wrote:
>
> On Mar 7, 2015, at 6:34 AM, Diederik Meijer wrote:
>
>>> On 07 Mar 2015, at 12:36, Ken Thomases wrote:
>>>
On Mar 7, 2015, at 5:02 AM, Diederik Meijer w
On Mar 7, 2015, at 6:34 AM, Diederik Meijer wrote:
>> On 07 Mar 2015, at 12:36, Ken Thomases wrote:
>>
>>> On Mar 7, 2015, at 5:02 AM, Diederik Meijer wrote:
>>>
>>> This is part of XML parsing with NSXMLParser, is there any way to avoid
>>> this type of staircasing by constructing a keyPath
Thanks Ken, but this does not seem to traverse down into n nested levels,
correct? The loop goes through the nodeTree's first level children only (pardon
the bad semantics here)
The aim is to add text sections to the appropriate items array, which can
either be a chapter, a chapter's section or
On Mar 7, 2015, at 5:02 AM, Diederik Meijer wrote:
> This is part of XML parsing with NSXMLParser, is there any way to avoid this
> type of staircasing by constructing a keyPath dynamically?
>
>if (self.nestingLevel == 1) { [[[self.rootparser nodeTree]
> lastObject][@"items"] addObject:dic
Hi all,
This is part of XML parsing with NSXMLParser, is there any way to avoid this
type of staircasing by constructing a keyPath dynamically?
if (self.nestingLevel == 1) { [[[self.rootparser nodeTree]
lastObject][@"items"] addObject:dict]; }
if (self.nestingLevel == 2) { self.root
