On 21 Apr 2014, at 6:23 am, Quincey Morris
wrote:
> More generally, though, you might reconsider using a NSToolbar at all. I
> guess the geometry of NSToolbar has always been "neither fish nor fowl" (that
> is, sort of part of the window frame, yet sort of part of the window content)
The to
On Apr 20, 2014, at 22:26 , Kyle Sluder wrote:
>> In a Save the dirty mark is not cleared until the file is written, thus it
>> asks before quitting about saving the document.
> Come to think of it, does your app adopt Lion Autosave?
The implication of “dirty mark” — if taken literally — is tha
On Apr 20, 2014, at 10:11 PM, Trygve Inda wrote:
>> On Apr 20, 2014, at 6:58 PM, Trygve Inda wrote:
>>
> On Apr 20, 2014, at 4:29 PM, Trygve Inda wrote:
>
> A small correction... This seems to only happen when I do a "Save As". If
> the file is dirty and I do a "Save", the "fi
> On Apr 20, 2014, at 6:58 PM, Trygve Inda wrote:
>
>>> On Apr 20, 2014, at 4:29 PM, Trygve Inda wrote:
>>>
A small correction... This seems to only happen when I do a "Save As". If
the file is dirty and I do a "Save", the "file is dirty warning" catches
the
quit.
>>>
>>> D
On Apr 20, 2014, at 2:54 PM, Eric Shepherd wrote:
> On Sat, Apr 19, 2014 at 4:35 AM, Ken Thomases wrote:
>
>> * You already suggested that this will work: try toggling the toolbar to
>> hidden and then showing again.
>
> Now this is crazy: this doesn't work either. What the heck?
I'm starting
Eric Shepherd
Gmail: the.she...@gmail.com
Twitter: sheppy
On Sun, Apr 20, 2014 at 4:23 PM, Quincey Morris <
quinceymor...@rivergatesoftware.com> wrote:
> On Apr 20, 2014, at 12:54 , Eric Shepherd wrote:
>
> Nope. :(
>
>
> The only *technical* suggestion I can add — beyond Ken’s excellent
> sugg
On Apr 20, 2014, at 6:58 PM, Trygve Inda wrote:
>> On Apr 20, 2014, at 4:29 PM, Trygve Inda wrote:
>>
>>> A small correction... This seems to only happen when I do a "Save As". If
>>> the file is dirty and I do a "Save", the "file is dirty warning" catches the
>>> quit.
>>
>> Does the bad beha
> On Apr 20, 2014, at 4:29 PM, Trygve Inda wrote:
>
>> A small correction... This seems to only happen when I do a "Save As". If
>> the file is dirty and I do a "Save", the "file is dirty warning" catches the
>> quit.
>
> Does the bad behavior also apply to Save if you turn off the “Close all
>
I’m using NSAppleScript to sent a message to another app using "tell
application”. It works twice then the third time my app gets stuck in the call
to executeAndReturnError: and doesn’t return.
The code is as follows, with sample AppleScript:
NSAppleScript *script = [[NSAppleScript all
On Apr 20, 2014, at 4:29 PM, Trygve Inda wrote:
> A small correction... This seems to only happen when I do a "Save As". If
> the file is dirty and I do a "Save", the "file is dirty warning" catches the
> quit.
Does the bad behavior also apply to Save if you turn off the “Close all windows
when
> Do you override any other NSDocument saving methods? I believe NSDocument’s
> internal use of -performAsynchronousFileAccess… should cause it to delay
> NSApplication termination.
>
> --Kyle Sluder
>
> On Apr 20, 2014, at 1:01 PM, Trygve Inda wrote:
>
>>>
On 20 Apr 2014, at 19:58, Trygv
> Do you override any other NSDocument saving methods? I believe NSDocument’s
> internal use of -performAsynchronousFileAccess… should cause it to delay
> NSApplication termination.
>
> --Kyle Sluder
>
My Document class contains:
//Read File Package
-(BOOL)readFromFileWrapper:(NSFileWrapper
On 21 Apr, 2014, at 3:51 am, Jens Alfke wrote:
>
> On Apr 20, 2014, at 11:58 AM, Cody Garvin wrote:
>
>> Second, while using instruments use the “mark heap” tool. Get your app up
>> and running. Mark the heap. Then start your image downloads, while that is
>> transpiring, mark the heap agai
On Apr 20, 2014, at 13:34 , Kyle Sluder wrote:
> Do you override any other NSDocument saving methods?
Also, there *may* be a relevant interaction between ‘terminate:’, sudden
termination and automatic termination, even though technically they’re separate
things. Opting in to the latter two, if
Do you override any other NSDocument saving methods? I believe NSDocument’s
internal use of -performAsynchronousFileAccess… should cause it to delay
NSApplication termination.
--Kyle Sluder
On Apr 20, 2014, at 1:01 PM, Trygve Inda wrote:
>>
>>> On 20 Apr 2014, at 19:58, Trygve Inda wrote:
>
On Apr 20, 2014, at 13:22 , Dave wrote:
> This App was an iOS application and previously it handled manual memory
> management - mostly using autorelease. I converted it by hand (didn’t use the
> ARC coversion process).
Ah, then ignore everything I said. :)
> if ([prop1 class] == [NSDictiona
On Apr 20, 2014, at 12:54 , Eric Shepherd wrote:
> Nope. :(
The only *technical* suggestion I can add — beyond Ken’s excellent suggestions
— is to move the OpenGL view down a level. That is, assuming it’s a subview of
the window’s content view, make it a subview of a custom view that is a subv
Hi,
This App was an iOS application and previously it handled manual memory
management - mostly using autorelease. I converted it by hand (didn’t use the
ARC coversion process).
As for running the Static Analyser, I did run this and it showed no leaks, but
some dead stores. I have just run it
On Apr 20, 2014, at 11:58 , Cody Garvin wrote:
> Second, while using instruments use the “mark heap” tool.
> Third, keep in mind that blocks keep strong references to self (especially
> callbacks).
While these are important debugging steps, I’d suggest that this isn’t the
place to start *in t
>
> On 20 Apr 2014, at 19:58, Trygve Inda wrote:
>
>> I return YES from
>>
>> canAsynchronouslyWriteToURL:ofType:forSaveOperation:
>>
>> Which works fine, but the user is able to quit the app while the save is in
>> progress. Is there way way to know when the save is complete so that I can
>>
On Sat, Apr 19, 2014 at 4:35 AM, Ken Thomases wrote:
> * Try calling -frameRectForContentRect: to see if that forces the window
> to recompute how its frame is affected by the toolbar.
>
Nope. :(
>
> * Try setting the window's style mask with -setStyleMask:. I know from
> past experience that
On Apr 20, 2014, at 11:58 AM, Cody Garvin wrote:
> Second, while using instruments use the “mark heap” tool. Get your app up and
> running. Mark the heap. Then start your image downloads, while that is
> transpiring, mark the heap again. This will help narrow down the code that
> could possib
On 20 Apr 2014, at 19:58, Trygve Inda wrote:
> I return YES from
>
> canAsynchronouslyWriteToURL:ofType:forSaveOperation:
>
> Which works fine, but the user is able to quit the app while the save is in
> progress. Is there way way to know when the save is complete so that I can
> prevent quit
Hi Dave!
First, check to make sure zombies are disabled. I made the mistake of trying to
track down leaks via instruments, and totally forgot they were enabled: wild
goose chase.
Second, while using instruments use the “mark heap” tool. Get your app up and
running. Mark the heap. Then start yo
I return YES from
canAsynchronouslyWriteToURL:ofType:forSaveOperation:
Which works fine, but the user is able to quit the app while the save is in
progress. Is there way way to know when the save is complete so that I can
prevent quit before the save ends?
Thanks,
Trygve
Hi,
I have a inheriated an Application that I converted to use ARC. When I run it
now, I see that memory is being allocated and not released. At least, when I
run the App with the debugger view active, I see the memory growing and growing
when I do some intensive Image Downloads as a test for t
I have an NSTextView which is being populated using RTF:
if ([self getContent:@"RTF"]&&useformatting)
{
[attributedContent appendAttributedString:[[NSAttributedString alloc]
initWithRTF:[self getContent:@"RTF"] documentAttributes:NULL]];
}
This works beautifully except that t
27 matches
Mail list logo
