Instruments won't symbolicate the call tree. What now?
Hi all. I'm looking for leaks in my iPhone app and apparently finding some. Unfortunately, Instruments will not show my app's symbols, making it pretty worthless. I've tried "Re-Symbolicate Document", but this does nothing. When I navigate to the location of the app and dSYM files (which do exist) and add their path in the re-symbolication dialog, it isn't stored. Is this normal? The next time I return to this dialog, there are no paths listed. On any entry in the Instruments call-tree that refers to my app, it just says the app name. Double-clicking on it brings up a giant "not available" message. I have build products going to their default location (...DerivedData/blah...), and stripping options set to their defaults (YES, except "deployment postprocessing" and "use separate strip", which are NO). There are no spaces in the name of my boot volume (where DerivedData/... resides). This is Xcode 4.2.1. Anybody know what might be going on here? Thanks! Gavin ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Animated NSSplitView headache
Hi, I'm really very close to having a working NSSplitView with animated "collapse" & "uncollapse" of the subviews, but there still is a problem when one of the subviews is first collapsed by dragging the divider over the subview's minimal size as controlled by the delegate. When I expand such a collapsed subview, the behavior I'm seeing is really unpredictable. The subview will be expanded and redrawn just fine for 10 or 20 consecutive times or so, but then all of a sudden the expand will fail. There *seems* to be a pattern that after the app is started, it either works fine, or it fails. When it works, it usually stays like that. But after a restart of the app, there's really no way I could predict the behavior. When it fails, it seems as if the autoresize mechanism in the expand view is not working correctly, and its subview extends beyond one side of the expanded view. After that, there's no way the layout 'restores' itself back to normal. When I close the app and restart, everything works fine again, or not… Because this is so unpredictable, I haven't been able to find the cause of the problem, and I'm hoping someone here has a suggestion on how to solve this problem. Maybe there's a problem with timing or synchronization, but I wouldn't know how to find out if there was. Maybe, I should somehow disable the layout mechanism during animation, and I've tried something in this area already, but so far without success. So, any suggestions would really be appreciated. As for my implementation: in general, prior to the animation, I'm disabling the split view delegate and the autoresizing of its subviews. I'm setting the target frames for both views, and then use the animator proxies. Afterwards, I'm restoring the delegate and the autoresizing behaviour back to their original values. Again, this all works if the subviews were not first collapsed by dragging the divider. -- Luc Van Bogaert. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Animated NSSplitView headache
Hi Luc, how are you? When the user drags the divider and collapses it, the split view retains the view's frames before the collapse and that's probably something that is giving you some problems. In this sense, there are two different behaviors going on when a collapse happen: 1) If the user drags the divider and collapses the subview, it's size will have the minimum allowed width/height and it's hidden property will become "TRUE"; 2) If an animated collapse happens, the subview's frame will have zero width/height and it's hidden property will be also "TRUE" because you are hiding it when the collapse animation finishes. To detect when the split view has manually collapsed one of it's subviews, watch via KVO the subview's "hidden" property. When it changes to "TRUE" and the subview's frame is not zero sized, it means the user collapsed by dragging the divider. If it becomes true and the subview's frame is zero sized, it means the collapse animation has finished. One probable cause of headache is the uncollapse algorithm: before doing the uncollapse, always make sure that the collapsed subview's frame has zero width/height. This may not be true if the user has manually dragged the divider and collapsed the subview. To finish it up, only reenable the autosize mechanisms when the subview has finished uncollapsing. This will prevent the autosize algorithms from calculating negative sized frames. Hope that helps! Abraços, Alvaro Costa Neto Em 10/02/2012, às 07:53, Luc Van Bogaert escreveu: > Hi, > > I'm really very close to having a working NSSplitView with animated > "collapse" & "uncollapse" of the subviews, but there still is a problem when > one of the subviews is first collapsed by dragging the divider over the > subview's minimal size as controlled by the delegate. > > When I expand such a collapsed subview, the behavior I'm seeing is really > unpredictable. The subview will be expanded and redrawn just fine for 10 or > 20 consecutive times or so, but then all of a sudden the expand will fail. > There *seems* to be a pattern that after the app is started, it either works > fine, or it fails. When it works, it usually stays like that. But after a > restart of the app, there's really no way I could predict the behavior. > > When it fails, it seems as if the autoresize mechanism in the expand view is > not working correctly, and its subview extends beyond one side of the > expanded view. After that, there's no way the layout 'restores' itself back > to normal. When I close the app and restart, everything works fine again, or > not… > > Because this is so unpredictable, I haven't been able to find the cause of > the problem, and I'm hoping someone here has a suggestion on how to solve > this problem. Maybe there's a problem with timing or synchronization, but I > wouldn't know how to find out if there was. Maybe, I should somehow disable > the layout mechanism during animation, and I've tried something in this area > already, but so far without success. So, any suggestions would really be > appreciated. > > As for my implementation: in general, prior to the animation, I'm disabling > the split view delegate and the autoresizing of its subviews. I'm setting the > target frames for both views, and then use the animator proxies. Afterwards, > I'm restoring the delegate and the autoresizing behaviour back to their > original values. Again, this all works if the subviews were not first > collapsed by dragging the divider. > > -- > Luc Van Bogaert. > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/nepheus.br%40gmail.com > > This email sent to nepheus...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to cancel a loading document in NSDocument's readFromURL:ofType:error method ?
Mike,
I'm not sure what you mean to set the cancel flag on the main thread.
I have done this so far, but I'm still stuck:
In my NSDocument readFromURL:ofType:error: method it init's a progressLoading
WindowController (which shows up the window with progress bar and Cancel
button).
In my progressLoadingWC I have a BOOL cancelLoadingFlag which is checked in
readFromURL method…however nothing seems to happen if I call NSError…the
document is still opened...
Also opening the file and trying to click the button is nearly impossible since
it slows down heavily. Here's an excerpt of my code
-(BOOL)readFromURL:(NSURL *)absoluteURL ofType:(NSString *)typeName
error:(NSError **)outError
{
asciiFileContents = [[NSString alloc] initWithContentsOfURL:absoluteURL
encoding:NSISOLatin1StringEncoding error:outError];
if (!progressLoadingWindowController)
{
progressLoadingWindowController = [[ProgressLoadingWindowController
alloc] init];
[[progressLoadingWindowController fileNameOutlet]
setStringValue:[absoluteURL lastPathComponent]];
[[progressLoadingWindowController loadProgressBar]
setUsesThreadedAnimation:YES];
[[progressLoadingWindowController loadProgressBar] startAnimation:self];
}
// Display the progressLoading window
[progressLoadingWindowController showWindow:self];
if ( [progressLoadingWindowController cancelLoadingFlag] )
{
NSLog(@"User cancelled opening...");
*outError = [NSError errorWithDomain:NSCocoaErrorDomain
code:NSUserCancelledError userInfo:nil];
}
myDocWindowController = [[TsoftViewerWindowController alloc]
initWithTsfFileString:asciiFileContents];
[self addWindowController:myDocWindowController];
[asciiFileContents release];
return YES;
}
I'm sure I'm doing something wrong here :-(
Any clues ?
Gilles
On Feb 9, 2012, at 11:53 PM, Mike Abdullah wrote:
>
> On 9 Feb 2012, at 20:23, Gilles Celli wrote:
>
>> Mike, Kyle,
>>
>> Thanks for the quick answers!
>>
>> Yes I'm targeting Mac OS X 10.6 and later so
>> canConcurrentlyReadDocumentsOfType: is a welcome addition, I completely
>> forgot that.
>>
>> Strangely if I put the method canConcurrentlyReadDocumentsOfType: inside my
>> NSDocument I get a warning when trying to open a document (It seems to be a
>> QuickLook error ?) on Mac OS X 10.7.3:
>>
>> [QL] QLError(): +[QLSeamlessDocumentOpener seamlessDocumentOpenerForURL:]
>> should only be called in the main thread
>
> Maybe try setting a breakpoint on QLError to see when it gets called?
>>
>> Now for the cancel question: If I take the more traditional approach to
>> cancel the operation inside readFromURL, should I fire up a new thread to
>> check the flag's status ?
>
> What would this gain you? You set the cancel flag on the main thread. And you
> have a worker thread for reading the document supplied by the system, so why
> add another thread to the mix?
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How to cancel a loading document in NSDocument's readFromURL:ofType:error method ?
> I'm sure I'm doing something wrong here :-(
>
> Any clues ?
Yep, here we go:
On 10 Feb 2012, at 15:28, Gilles Celli wrote:
> In my NSDocument readFromURL:ofType:error: method it init's a progressLoading
> WindowController (which shows up the window with progress bar and Cancel
> button).
> In my progressLoadingWC I have a BOOL cancelLoadingFlag which is checked in
> readFromURL method…however nothing seems to happen if I call NSError…the
> document is still opened...
>
> Also opening the file and trying to click the button is nearly impossible
> since it slows down heavily. Here's an excerpt of my code
>
> -(BOOL)readFromURL:(NSURL *)absoluteURL ofType:(NSString *)typeName
> error:(NSError **)outError
> {
> asciiFileContents = [[NSString alloc] initWithContentsOfURL:absoluteURL
>
> encoding:NSISOLatin1StringEncoding error:outError];
OK, good, you're grabbing file contents on the worker thread. How long does
this typically take? Why not show your progress display before this?
>if (!progressLoadingWindowController)
>{
>progressLoadingWindowController = [[ProgressLoadingWindowController
> alloc] init];
>[[progressLoadingWindowController fileNameOutlet]
> setStringValue:[absoluteURL lastPathComponent]];
>[[progressLoadingWindowController loadProgressBar]
> setUsesThreadedAnimation:YES];
>[[progressLoadingWindowController loadProgressBar]
> startAnimation:self];
>
>}
Don't do this. AppKit is not thread safe. Creating a window controller on a
secondary thread is not supported.
>
>// Display the progressLoading window
>[progressLoadingWindowController showWindow:self];
>
>if ( [progressLoadingWindowController cancelLoadingFlag] )
>{
>NSLog(@"User cancelled opening...");
>
>*outError = [NSError errorWithDomain:NSCocoaErrorDomain
>code:NSUserCancelledError
> userInfo:nil];
Never blindly assign to error pointers. Check the caller is actually interested
in receiving an error first.
>}
>
>myDocWindowController = [[TsoftViewerWindowController alloc]
> initWithTsfFileString:asciiFileContents];
Or is it this line of code that takes a long time to run? If so, what's it
doing?
>
> [self addWindowController:myDocWindowController];
Furthermore, it is not this method's job to create the UI. That should be done
in -makeWindowControllers instead.
>
> [asciiFileContents release];
>
>
>return YES;
>
> }
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: drawing 1 bit images, and image resolution
What I'm working with is a library that makes a QR code. It was built for iOS
but I need desktop OSX (which, on a side note, seems silly because when you
MAKE a qr code, you'd usually want to print it right? Otherwise phones would
just read them. Anyways...). It was easy enough to adjust the library to
product an NSImage instead of UIImage. It's giving me an RGBa image (which is
already BW, so I don't need to quantize... nor would I know how, that is way
out of my league of skills I think). I don't want to fiddle around with the
library so much because I'm afraid I will break it, and some of it's C++ and
straight C. It would be great if it could output an greyscale image at least,
instead of RBGa. But right now it doesn't so I will deal with the RGBa, and all
channels are equal so I could use any.
My C skills aren't so great, and I feel like if I can't make it all work
properly, I wouldn't know if I had -any- of it working properly.
After a while of studying and trying some things, here's what I've got so far.
I know it's not correct and doesn't work yet.
-(NSData *)oneBitData:(NSImage *)inputNSImage
{
NSData *testOnly = [NSData data];
//this will be somewhat akin to un-reading the qrEncoder +renderDataMatrix
method
//I need to get 1 channel of the RGBa only here
//or, change the library to return a greyscale image
//output a 1 bit image of NSData format from an NSImage given in RGB mode
//get an image rep from the current qrImage
NSBitmapImageRep*imgRep = [NSBitmapImageRepimageRepWithData:[inputNSImage
TIFFRepresentation]];
int
row, column,
widthInPixels = [imgRep pixelsWide],
heightInPixels = [imgRep pixelsHigh];
//make a buffer of bits, like 50px x 50px = 2500 chars
const int rawDataSize = widthInPixels * heightInPixels;
unsigned char *rawData = (unsigned char*)malloc(rawDataSize);
NSUInteger lePixel;
for (row = 0; row < heightInPixels; row++)
for (column = 0; column
To: Chris Paveglio
Cc: Cocoa Dev List
Sent: Thursday, February 9, 2012 5:43 PM
Subject: Re: drawing 1 bit images, and image resolution
On 10/02/2012, at 3:54 AM, Chris Paveglio wrote:
still looking for a way to convert to 1-bit.
So what have you tried?
There are a lot of different methods for deciding how to threshold an image -
in other words how to decide which colours end up as 1s and which as 0s. You
will probably find that a 50% cut based on brightness is too simplistic, and
the results will be very disappointing. For good results you will usually have
to quantize the colour image into a smaller set of colours using some
statistical method, for example popular 555, or octree. This is a whole art in
itself, and quite complex. You might get away with first converting to an 8-bit
greyscale image and thresholding that - at least you can do a greyscale
conversion easily. The old Mac OS used to have API for doing colour
quantization, but Cocoa does not.
But actually performing the thresholding isn't hard - just walk the bitmap,
look at the (quantized) pixel value and if its above the threshold, set a 1,
below set a 0. It's probably best to set the pixel in a second bitmap rather
than do it in place. I recommend designing your code so that you can experiment
with both the weighting of RGB values to determine brightness, and the
threshold level itself. If you don't the result is certain to disappoint, and
end up much blacker than you expected.
You can use NSBitmapImageRep's getPixel:atX:y: to read the source pixel and
setPixel:atX:y: to set the destination pixel in a x,y double loop. Note that
pixel values used by these methods are not colours.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: drawing 1 bit images, and image resolution
Let's work on this today and see what we get. I've got meetings for the next 3
hours, but am free to try and help after that.
Feel free to email me in 3 hours.
Cool?
- Alex Zavatone
On Feb 10, 2012, at 11:15 AM, Chris Paveglio wrote:
> What I'm working with is a library that makes a QR code. It was built for iOS
> but I need desktop OSX (which, on a side note, seems silly because when you
> MAKE a qr code, you'd usually want to print it right? Otherwise phones would
> just read them. Anyways...). It was easy enough to adjust the library to
> product an NSImage instead of UIImage. It's giving me an RGBa image (which is
> already BW, so I don't need to quantize... nor would I know how, that is way
> out of my league of skills I think). I don't want to fiddle around with the
> library so much because I'm afraid I will break it, and some of it's C++ and
> straight C. It would be great if it could output an greyscale image at least,
> instead of RBGa. But right now it doesn't so I will deal with the RGBa, and
> all channels are equal so I could use any.
> My C skills aren't so great, and I feel like if I can't make it all work
> properly, I wouldn't know if I had -any- of it working properly.
>
> After a while of studying and trying some things, here's what I've got so
> far. I know it's not correct and doesn't work yet.
>
> -(NSData *)oneBitData:(NSImage *)inputNSImage
> {
> NSData *testOnly = [NSData data];
> //this will be somewhat akin to un-reading the qrEncoder +renderDataMatrix
> method
> //I need to get 1 channel of the RGBa only here
> //or, change the library to return a greyscale image
> //output a 1 bit image of NSData format from an NSImage given in RGB mode
> //get an image rep from the current qrImage
> NSBitmapImageRep*imgRep = [NSBitmapImageRepimageRepWithData:[inputNSImage
> TIFFRepresentation]];
> int
> row, column,
> widthInPixels = [imgRep pixelsWide],
> heightInPixels = [imgRep pixelsHigh];
> //make a buffer of bits, like 50px x 50px = 2500 chars
> const int rawDataSize = widthInPixels * heightInPixels;
> unsigned char *rawData = (unsigned char*)malloc(rawDataSize);
> NSUInteger lePixel;
> for (row = 0; row < heightInPixels; row++)
> for (column = 0; column {
> [imgRep getPixel:&lePixel atX:row y:column];
> //copy the value from first memory area to the same
> //location in the raw data area, it'll be either B or W, no inbetween values
> NSLog(@"bit %d = %d", (row * column) , lePixel);
> rawData[row * column] = lePixel < 128 ? 0 : 255;
> }
> return testOnly;
> }
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: drawing 1 bit images, and image resolution
I have been able to change the library to output Greyscale images now. It required less work than I had thought. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: drawing 1 bit images, and image resolution
Hm I think this will work for me. I mean, at this point it'll make me a bitmap
and I can save it and when I open it in Photoshop it looks correct!
-(NSData *)oneBitData:(NSImage *)inputNSImage
{
//output a 1 bit image of NSData format from an NSImage given in gray mode
//get an image rep from the current qrImage
NSSize oldSize = [inputNSImage size];
NSBitmapImageRep *imgRep = [NSBitmapImageRep imageRepWithData:[inputNSImage
TIFFRepresentation]];
int
row, column,
widthInPixels = [imgRep pixelsWide],
heightInPixels = [imgRep pixelsHigh];
NSUInteger lePixel;
NSBitmapImageRep *newRep = [[NSBitmapImageRep alloc]
initWithBitmapDataPlanes:nil
pixelsWide:widthInPixels
pixelsHigh:heightInPixels
bitsPerSample:1
samplesPerPixel:1
hasAlpha:NO
isPlanar:YES
colorSpaceName:NSDeviceWhiteColorSpace
bytesPerRow:0
bitsPerPixel:1];
[newRep setSize:oldSize];
for (row = 0; row < heightInPixels; row++)
for (column = 0; column
To: Chris Paveglio
Cc: Cocoa Dev List
Sent: Thursday, February 9, 2012 5:43 PM
Subject: Re: drawing 1 bit images, and image resolution
On 10/02/2012, at 3:54 AM, Chris Paveglio wrote:
still looking for a way to convert to 1-bit.
So what have you tried?
There are a lot of different methods for deciding how to threshold an image -
in other words how to decide which colours end up as 1s and which as 0s. You
will probably find that a 50% cut based on brightness is too simplistic, and
the results will be very disappointing. For good results you will usually have
to quantize the colour image into a smaller set of colours using some
statistical method, for example popular 555, or octree. This is a whole art in
itself, and quite complex. You might get away with first converting to an 8-bit
greyscale image and thresholding that - at least you can do a greyscale
conversion easily. The old Mac OS used to have API for doing colour
quantization, but Cocoa does not.
But actually performing the thresholding isn't hard - just walk the bitmap,
look at the (quantized) pixel value and if its above the threshold, set a 1,
below set a 0. It's probably best to set the pixel in a second bitmap rather
than do it in place. I recommend designing your code so that you can experiment
with both the weighting of RGB values to determine brightness, and the
threshold level itself. If you don't the result is certain to disappoint, and
end up much blacker than you expected.
You can use NSBitmapImageRep's getPixel:atX:y: to read the source pixel and
setPixel:atX:y: to set the destination pixel in a x,y double loop. Note that
pixel values used by these methods are not colours.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How to cancel a loading document in NSDocument's readFromURL:ofType:error method ?
Opening the ASCII file can take up to 15-20 sec ( > 150MB), so I made some
changes as you suggested by moving the progressWindowController alloc/init
before the allocation of asciiFileContents...
And you're right I should have put addWindowController: in
makeWindowController
This makes the opening of the file a little more responsive (clicking the
button) but not really what I expect...
>Never blindly assign to error pointers. Check the caller is actually
>interested in receiving an error first.
Which caller do you mean ?
Maybe the way to go is to use a new detached thread only for the progress
window, or to use Kyle's approach by using NSOperationQueue..
Of course if you guys have any other suggestions they will be greatly
appreciated :-)
Gilles
On 10 févr. 2012, at 17:08, Mike Abdullah wrote:
>> I'm sure I'm doing something wrong here :-(
>>
>> Any clues ?
>
> Yep, here we go:
>
> On 10 Feb 2012, at 15:28, Gilles Celli wrote:
>
>> In my NSDocument readFromURL:ofType:error: method it init's a
>> progressLoading WindowController (which shows up the window with progress
>> bar and Cancel button).
>> In my progressLoadingWC I have a BOOL cancelLoadingFlag which is checked in
>> readFromURL method…however nothing seems to happen if I call NSError…the
>> document is still opened...
>>
>> Also opening the file and trying to click the button is nearly impossible
>> since it slows down heavily. Here's an excerpt of my code
>>
>> -(BOOL)readFromURL:(NSURL *)absoluteURL ofType:(NSString *)typeName
>> error:(NSError **)outError
>> {
>> asciiFileContents = [[NSString alloc] initWithContentsOfURL:absoluteURL
>>
>> encoding:NSISOLatin1StringEncoding error:outError];
>
> OK, good, you're grabbing file contents on the worker thread. How long does
> this typically take? Why not show your progress display before this?
>
>> if (!progressLoadingWindowController)
>> {
>> progressLoadingWindowController = [[ProgressLoadingWindowController
>> alloc] init];
>> [[progressLoadingWindowController fileNameOutlet]
>> setStringValue:[absoluteURL lastPathComponent]];
>> [[progressLoadingWindowController loadProgressBar]
>> setUsesThreadedAnimation:YES];
>> [[progressLoadingWindowController loadProgressBar]
>> startAnimation:self];
>>
>> }
>
> Don't do this. AppKit is not thread safe. Creating a window controller on a
> secondary thread is not supported.
>>
>> // Display the progressLoading window
>> [progressLoadingWindowController showWindow:self];
>>
>> if ( [progressLoadingWindowController cancelLoadingFlag] )
>> {
>> NSLog(@"User cancelled opening...");
>>
>> *outError = [NSError errorWithDomain:NSCocoaErrorDomain
>> code:NSUserCancelledError
>> userInfo:nil];
>
> Never blindly assign to error pointers. Check the caller is actually
> interested in receiving an error first.
>> }
>>
>> myDocWindowController = [[TsoftViewerWindowController alloc]
>> initWithTsfFileString:asciiFileContents];
>
> Or is it this line of code that takes a long time to run? If so, what's it
> doing?
>>
>> [self addWindowController:myDocWindowController];
>
> Furthermore, it is not this method's job to create the UI. That should be
> done in -makeWindowControllers instead.
>>
>> [asciiFileContents release];
>>
>>
>> return YES;
>>
>> }
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How to cancel a loading document in NSDocument's readFromURL:ofType:error method ?
On 10 Feb 2012, at 21:25, Gilles Celli wrote: > Opening the ASCII file can take up to 15-20 sec ( > 150MB), so I made some > changes as you suggested by moving the progressWindowController alloc/init > before the allocation of asciiFileContents... > And you're right I should have put addWindowController: in > makeWindowController > > This makes the opening of the file a little more responsive (clicking the > button) but not really what I expect... > >> Never blindly assign to error pointers. Check the caller is actually >> interested in receiving an error first. > Which caller do you mean ? Cocoa is calling your method. You should do: if (outError) *outError = … Otherwise it'll crash should outError be nil. The static analyser can warn you of this. > > Maybe the way to go is to use a new detached thread only for the progress > window, or to use Kyle's approach by using NSOperationQueue.. Again I repeat: AppKit is NOT thread safe. You must perform all UI on the main thread. You already have a detached thread. There is likely no point trying to start up another one. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Lion: Lock documents and custom undomanager
On 7 Feb 2012, at 11:28, Georg Seifert wrote:
> Hi,
>
> I have several undomanagers in my app. (I know that is unusual. Think of it
> as if you had a page layout app and every page has its own undo.)
>
> This all works well except if the document is locked. Then the documents
> undomanager knows about this and prevents the change and generates a error.
> But my undomanagers are not in sync with the document. I do not find anything
> about that in the docs. So, is there any way to get the locked state of the
> document or to connect the undomanagers with the document?
My line of thinking:
Each time one of your undo managers is about to close its top-level group,
register that with the doc's main undo manager. Thus the doc's undo manager
will see the change while locked, prompt the user to unlock, and if they do
choose to cancel, will undo the change to individual undo manager. Something
like:
- (void)undoManagerWillCloseGroup:(NSNotification *)notification
{
NSUndoManager *manager = [notification object];
if ([manager groupingLevel] == 1)
{
[[[self document] undoManager] registerUndoWithTarget:manager
selector:@selector(undo) object:nil];
}
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Lion: unlocking a document
On 7 Feb 2012, at 11:08, Georg Seifert wrote: > Hi, > > I still have problems with my document saving behavior in Lion. > > If I open a file that my app can only read (CFBundleRoleType = Viewer) the > state is set to locked. If I unlock it and do some changes, the autosave > replaces the document file with a native file. > > This is really not exactable. Not all data is read from the original (binary) > file and so I need to keep the original. > > Is there any way to prevent this. I would prefer that if the user unlocks the > document, it actually is duplicated. Some ideas: - Override one of the save or write methods to fail and return NSUserCancelledError under these circumstances - Does overriding -checkAutosavingSafetyAndReturnError: to return a custom error do the trick? - Jump in at -willPresentError: and provide your own custom error ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: drawing 1 bit images, and image resolution
On 11/02/2012, at 7:46 AM, Chris Paveglio wrote:
> for (column = 0; column {
> //get pixel value from grey and put into 1bit
> [imgRep getPixel:&lePixel atX:row y:column];
> [newRep setPixel:&lePixel atX:row y:column];
> }
> //FYI this is not an all purpose solution, this will ONLY work with greyscale
> images
> //that are already 1-bit in spirit
Noting your comment, you could make it general purpose with an extremely minor
change to your code.
Compare the value in 'le' against some desired threshold value (given that the
input image is 8-bit grey, this would be a value between 0 and 255), and call
setPixel: with 0 or 1 depending on the outcome.
Also, you might get a small performance improvement if you first clear the
destination image buffer to all zero, then only set the bits that are 1s. That
would avoid many calls to -setPixel in the inner loop (though whether that
performance matters would need to be determined).
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
NSReadPixel
I have two monitors connected. When I call NSreadPixel with a point that is on the main screen, origin 0,0 it returns the appropriate NSColor; When I call NSreadPixel with a point that is on the 2nd screen, origin -1280,0 it returns nil as the NSColor; So, how do I get the NSColor for a pixel whose x coordinate is <0? -koko ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Instruments won't symbolicate the call tree. What now?
I had a similar problem with Mac apps until a few months ago. Sometimes gdb would symbolicate, sometimes not. The problem was that, by default, gdb uses, er, Spotlight to locate dSYM files. The fact that I always put them in the same directory as the target app didn't seem to help. Surprised? I've not had the problem since I started specifying the dSYM files on the command line. Maybe something similar is going on with you. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Lion: Lock documents and custom undomanager
On Feb 10, 2012, at 15:03 , Mike Abdullah wrote:
> My line of thinking:
>
> Each time one of your undo managers is about to close its top-level group,
> register that with the doc's main undo manager. Thus the doc's undo manager
> will see the change while locked, prompt the user to unlock, and if they do
> choose to cancel, will undo the change to individual undo manager. Something
> like:
>
> - (void)undoManagerWillCloseGroup:(NSNotification *)notification
> {
> NSUndoManager *manager = [notification object];
> if ([manager groupingLevel] == 1)
> {
> [[[self document] undoManager] registerUndoWithTarget:manager
> selector:@selector(undo) object:nil];
> }
> }
Won't this have the effect of causing successive undos to affect various pages,
according to the order things were originally done, rather than just undoing
within the current "page"? That is, won't it undo on a global "timeline" rather
than a per-page timeline?
I don't recall that this was discussed, but what happens if the document's undo
manager is changed to the page undo manager every time page switch occurs? I
can't work out if the OP tried this and found that the document's "edited"
status doesn't capture the undo manager states properly, or if the OP didn't
try this.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
unknown type name virtual when using c++ in Xcode 4.2.1
I had read a book named "iPhone 3D programming" ,it used a c++ sample code
#include
#ifndef HelloArrow_IRenderingEngine_hpp
#define HelloArrow_IRenderingEngine_hpp
enum DeviceOrientation
{
DeviceOrientationUnknown,
DeviceOrientationPortrait,
DeviceOrientationPortraitUpsideDown,
DeviceOrientationLandscapeLeft,
DeviceOrientationLandscapeRight,
DeviceOrientationFaceUp,
DeviceOrientationFaceDown
};
//Creates an instance of the renderer and sets up various OpenGL state.
struct IRenderingEngine * CreateRender1();
//Interface to the OpenGL ES renderer;consumed by GLView.
struct IRenderingEngine
{
virtual void Initialize(int width,int height)=0;
virtual void Render() const=0;
virtual void UpdateAnimation(float timeStep)=0;
virtual void OnRotate(DeviceOrientation newOrientaion)=0;
virtual ~IRenderingEngine(){}
};
#endif
When I compiled this code in Xcode 4.2.1(OS X Lion 10.7.3),it reported that
IRenderingEngine.hpp: error: unknown type name 'virtual' .
I had created a empty application project which included this sample code.And I
had renamed all *.m file into *.mm.For example,renamed AppDelegate.m into
AppDelegate.mm, renamed GLView.m into GLView.mm,but remain *.hpp file and
*.cpp file.But it doesn't work for me.Any suggestions will be appreciated.
stevens
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSReadPixel
On Fri, Feb 10, 2012 at 4:44 PM, koko wrote: > I have two monitors connected. > > When I call NSreadPixel with a point that is on the main screen, origin 0,0 > it returns the appropriate NSColor; > > When I call NSreadPixel with a point that is on the 2nd screen, origin > -1280,0 it returns nil as the NSColor; > > So, how do I get the NSColor for a pixel whose x coordinate is <0? 1. Are you sure you're actually passing the correct point? NSReadPixel operates in the coordinate system of the currently-focused view. You might be getting the right color by sheer luck. 2. Why are you using NSReadPixel at all? There might be better ways of accomplishing your goal. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: unknown type name virtual when using c++ in Xcode 4.2.1
On Feb 10, 2012, at 4:15 AM, stevens wrote: > When I compiled this code in Xcode 4.2.1(OS X Lion 10.7.3),it reported that > IRenderingEngine.hpp: error: unknown type name 'virtual' . What source file was it trying to compile at the time? (I.e. which file was #including that header?) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
