Update of Typography panel
Hi, I am trying to support the Typography panel (available through the Fonts panel). I can get the user settings by implementing -changeAttributes: in the first responder. But if i set a new active font with [[NSFontManager sharedFontManager] setSelectedFont:isMultiple:], an already opened Typography panel is not adjusted to the features of the new font. Instead it continues to show the features of the last font. How can I refresh the Typography panel to show the features of the active font? Martin ___ 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: Bindings crash
Hi list,
This is the error I'm seeing:
2012-01-26 07:54:20.418 FileExplorer[1338:707] NSScanner: nil string
argument
2012-01-26 07:54:20.420 FileExplorer[1338:707] NSScanner: nil string
argument
2012-01-26 07:54:20.421 FileExplorer[1338:707] NSScanner: nil string
argument
2012-01-26 07:54:20.467 FileExplorer[1338:707] NSDecimalNumber overflow
exception
2012-01-26 07:54:20.692 FileExplorer[1338:707] (
0 CoreFoundation 0x7fff92c1f286
__exceptionPreprocess + 198
1 libobjc.A.dylib 0x7fff9366ad5e
objc_exception_throw + 43
2 CoreFoundation 0x7fff92c1f0ba
+[NSException raise:format:arguments:] + 106
3 CoreFoundation 0x7fff92c1f044
+[NSException raise:format:] + 116
4 Foundation 0x7fff8d4be9fd
-[NSDecimalNumberHandler
exceptionDuringOperation:error:leftOperand:rightOperand:] + 193
rest of stack dump snipped
The first NSScanner error appears to be from the code I posted before.
The second two and the NSDecimalNumber overflow problem appear to be
from this:
- (NSString *)usedSpace {
NSDictionary *systemInfo = [[NSFileManager defaultManager]
attributesOfFileSystemForPath: [[NSBundle mainBundle] bundlePath] error:
nil];
NSDecimalNumber *total = [NSDecimalNumber decimalNumberWithString:
[[systemInfo objectForKey: NSFileSystemSize] stringValue]];
NSDecimalNumber *avail = [NSDecimalNumber decimalNumberWithString:
[[systemInfo objectForKey: NSFileSystemFreeSize] stringValue]];
return [self humanReadableNumber: [total decimalNumberBySubtracting:
avail]];
}
This problem seems to depend on the compilation order. Commenting out
the offending code, recompiling, then restoring the code and recompiling
makes the problem go away. Performing a Clean operation than
recompiling makes the problem reappear. This suggests compilation order
affects whether the systemInfo dictionary has valid elements or not at
runtime.
I could put in exception handling code for the NSDecimalNumber
operation, but as far as I can tell from the documentation, the
attributes in the dictionary shouldn't ever be empty. Any ideas on what
conditions I need to wait for? If something else must happen first,
then that would mean that this code can't be executed in response to a
binding, and I'd have to set their values directly.
As to why @dynamic is there, I thought that was the proper way to
implement a property where the implementation was supplied by me rather
than synthesised. Is that not the case?
Cheers,
Arved
___
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: Bindings crash
On Jan 26, 2012, at 4:12 AM, Arved von Brasch wrote:
- (NSString *)usedSpace {
NSDictionary *systemInfo = [[NSFileManager defaultManager]
attributesOfFileSystemForPath: [[NSBundle mainBundle] bundlePath] error: nil];
NSDecimalNumber *total = [NSDecimalNumber decimalNumberWithString:
[[systemInfo objectForKey: NSFileSystemSize] stringValue]];
NSDecimalNumber *avail = [NSDecimalNumber decimalNumberWithString:
[[systemInfo objectForKey: NSFileSystemFreeSize] stringValue]];
return [self humanReadableNumber: [total decimalNumberBySubtracting:
avail]];
}
First, why are you using strings to convert to NSDecimalNumber? Ask the
NSNumber for its decimalValue and then use +[NSDecimalNumber
decimalNumberWithDecimal:]. That avoids formatting and parsing of strings.
Second, why do you need NSDecimalNumber? Can you not use either unsigned long
long or double for this purpose?
This problem seems to depend on the compilation order. Commenting out the
offending code, recompiling, then restoring the code and recompiling makes
the problem go away. Performing a Clean operation than recompiling makes the
problem reappear. This suggests compilation order affects whether the
systemInfo dictionary has valid elements or not at runtime.
I doubt that. Probably, you have an uninitialized variable or stack smashing
bug somewhere and the compilation order affects the layout of the stack which
changes either what garbage is in the uninitialized variable or what on the
stack gets smashed.
Certainly, you can log the values you get from systemInfo to check your
hypothesis.
As to why @dynamic is there, I thought that was the proper way to implement a
property where the implementation was supplied by me rather than synthesised.
Is that not the case?
You don't need @dynamic for properties where you supply the accessors at
compilation time. It's only necessary for when the accessors aren't apparently
available but will be at runtime. For example, by dynamically loading a
category or self-modifying code. (NSManagedObject uses something like the
latter.)
Regards,
Ken
___
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 open CMYK TIF in Cocoa?
The problem seems to be with the embedded alpha channel in the TIF. It is always using the alpha when you try to do anything with the file. Is there an easy way to avoid this? In my case, I need the full image without the alpha. Currently, if you open the TIF and display it, it will only show you the image thru the alpha. Todd On Jan 25, 2012, at 9:54 PM, Ken Ferry wrote: NSImage handles everything CGImage does, and this includes CMYK. NSImage loads bitmaps with ImageIO, which is what you'd do at the CG layer. If the file isn't being read correctly, I would try to investigate if the file was bad. -ken On Jan 25, 2012, at 2:47 PM, douglas welton douglas_wel...@earthlink.net wrote: What have you tried? Did you try using one of the CGImage-related functions to read the file? On Jan 24, 2012, at 3:01 PM, Todd Freese wrote: Is there an easy way to open a CMYK TIF file and put it into an NSImage? Seems like the Framework is assuming the file is RGB. Todd __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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/douglas_welton%40earthlink.net This email sent to douglas_wel...@earthlink.net ___ 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/kenferry%40gmail.com This email sent to kenfe...@gmail.com __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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 open CMYK TIF in Cocoa?
This might be a bug in the framework. Preview has the same problem with any TIF file with an alpha channel in it. t On Jan 25, 2012, at 9:54 PM, Ken Ferry wrote: NSImage handles everything CGImage does, and this includes CMYK. NSImage loads bitmaps with ImageIO, which is what you'd do at the CG layer. If the file isn't being read correctly, I would try to investigate if the file was bad. -ken On Jan 25, 2012, at 2:47 PM, douglas welton douglas_wel...@earthlink.net wrote: What have you tried? Did you try using one of the CGImage-related functions to read the file? On Jan 24, 2012, at 3:01 PM, Todd Freese wrote: Is there an easy way to open a CMYK TIF file and put it into an NSImage? Seems like the Framework is assuming the file is RGB. Todd __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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/douglas_welton%40earthlink.net This email sent to douglas_wel...@earthlink.net ___ 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/kenferry%40gmail.com This email sent to kenfe...@gmail.com __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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 open CMYK TIF in Cocoa?
Sorry for all the emails…. This only seems to appear with CMYK TIF files. If anyone has a workaround I would greatly appreciate it. I am really in the bind over this one. Todd On Jan 25, 2012, at 9:54 PM, Ken Ferry wrote: NSImage handles everything CGImage does, and this includes CMYK. NSImage loads bitmaps with ImageIO, which is what you'd do at the CG layer. If the file isn't being read correctly, I would try to investigate if the file was bad. -ken On Jan 25, 2012, at 2:47 PM, douglas welton douglas_wel...@earthlink.net wrote: What have you tried? Did you try using one of the CGImage-related functions to read the file? On Jan 24, 2012, at 3:01 PM, Todd Freese wrote: Is there an easy way to open a CMYK TIF file and put it into an NSImage? Seems like the Framework is assuming the file is RGB. Todd __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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/douglas_welton%40earthlink.net This email sent to douglas_wel...@earthlink.net ___ 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/kenferry%40gmail.com This email sent to kenfe...@gmail.com __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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
Atta Boys, 4 bags-full
The purpose of this document is to give thunderous applause to some very patient folk. But, before I crank up the volume, I would like to share with you a small amount of history. I am within a week of finishing my Universal app, Love Song to America whose purpose is to support all our military veterans from World War II, Korea, Vietnam and up to and including Iraq and Afghanistan. Every last one of them, living and deceased, are true heroes and deserve all the applause and support we can generate. The on-going process of submitting and re-submitting and re-re-submitting my mobile app to the App Store has been very, very painful and I wanted to share a glimpse of it. I have found that all the rules in the App Guidelines manual are to describe all the official DO's and DO NOT's. The unspoken list of DO's and DON'Ts are what I am concerned about. As a strictly hypothetical example, it is entirely possible that a unspoken rule is to never, ever have need to use the More Nav Controller in a UITabController app. It is clear that no written rule stipulates that, but politically its use may be politically Incorrect. When I submitted the app the first couple of times (without a TabBar Item pertaining to Military Support Agencies), their response essentially stated my app was nothing but a glorified web page. They were almost correct, but I countered that there are books and movie-equivalents of books. Gone With the Wind, Ivanhoe, Sound of Music, and Secretariat come to mind. Did I forget Cinderella and Snow White? They said, in effect, Nice Try. Their official comment was Make Love Song more interactive. Okay, specifically how or what do you recommend? Mr Love, just make it more interactive than it is. What's wrong with this picture? I just can't deal with this, so I scoured the web and found similar experiences of many, many other developers. I finally talked with a real human in the App Store and it was like prying wisdom teeth, but I FINALLY extracted his suggestion about the Support Agencies so veterans on the road could find out phone numbers and names to contact in case disaster struck. That idea was really, really awesome so I incorporated it … my mind was literally wrapped up in Protocols and Delegates, I didn't see the forest. But, I had to literally browbeat him to extract the idea. What's wrong with this picture? In addition, I tried and tried to get an App Store rep to tell me how to de-pixelate all my images (one of their complaints leading to rejection). Give me the name of a specific piece of software and I'll try to use it (praying that it wasn't PhotoShop = $$$). Literally, silence. I then called directly the Apple Business section for Developers, talked to some young man who apparently took pity on me and essentially said go to this web site and beg. The web site was Apple's Dev Support forum. I did that, and the flood gates opened and that is how I met lots of human beings with a heart. Now, that 8-minute phone call to Apple Business, what a God-send … spent hours with the App Store … but just a few minutes with Apple Business and Manna from Heaven. Do I have to ask what's wrong with this picture? Manna in the form of: Sandy McGuffog mcguff...@gmail.com Bill Kunz b...@tigerbears.com pbear pb...@pbear.net Kevin Messina dvmagicstud...@me.com All these guys displayed the patience of a million saints. Of extraordinary note is Kevin who came to the table with 20+ years as a programmer and has his own Digital Video Studio. Kevin taught me so darn much about his-res graphics and even more about Xcode. For example, he talked about png-crush (I'm embarrassed to ask, so I'll look around for its meaning). He taught me about making the project settings independent of a particular directory, in short, not hard-wiring the location. Let's hear a ear-splitting round of applause for these 4 guys … I didn't hear you … oh, come on, you can do better than that! That's better. John Love Touch the Future! Teach! ___ 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
Open a new terminal tab or window from a Cocoa app at a certain directory without using NSAppleScript?
I would like to perform the same logic as the New Terminal Tab at Folder service in Finder in my Cocoa app. The only code I found via Google is all using AppleScript to open the Terminal.app, but nothing I found was a Cocoa interface besides 3rd party terminal apps (iTerm, iTerm2). Is there a better way than using NSAppleScript to do this? I do not see any core libraries for the terminal app, but perhaps I am just looking in the wrong location. If I were to use NSWorkspace, I tried using the open at the command line, but I am not able to: 1. figure out how to open a new tab as opposed to a window 2. not have to run a program 3. it does not open the default terminal theme Thanks, Andrew ___ 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: Atta Boys, 4 bags-full
Glad you were able to solve your problems but it sounds like you were going to the wrong places for help. It's really not the job of App Review to explain how to use the tools, or to recommend a specific vendor's third party solution… Sounds like you found the forums though, which are perfect for this sort of thing. On Jan 26, 2012, at 9:12 AM, John Love wrote: In addition, I tried and tried to get an App Store rep to tell me how to de-pixelate all my images (one of their complaints leading to rejection). Give me the name of a specific piece of software and I'll try to use it (praying that it wasn't PhotoShop = $$$). Literally, silence. ___ 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: Bindings crash
Thanks very much for your response. You pointed me in the right direction. On 26/01/2012, at 3:23 PM, Ken Thomases wrote: First, why are you using strings to convert to NSDecimalNumber? Ask the NSNumber for its decimalValue and then use +[NSDecimalNumber decimalNumberWithDecimal:]. That avoids formatting and parsing of strings. Second, why do you need NSDecimalNumber? Can you not use either unsigned long long or double for this purpose? You're right I changed this to use NSDecimals and C methods instead. I'm a little cautious about going to long longs or doubles because I want to be sure that it'll work if Apple changes the format of the elements in the dictionary. This problem seems to depend on the compilation order. Commenting out the offending code, recompiling, then restoring the code and recompiling makes the problem go away. Performing a Clean operation than recompiling makes the problem reappear. This suggests compilation order affects whether the systemInfo dictionary has valid elements or not at runtime. I doubt that. Probably, you have an uninitialized variable or stack smashing bug somewhere and the compilation order affects the layout of the stack which changes either what garbage is in the uninitialized variable or what on the stack gets smashed. Certainly, you can log the values you get from systemInfo to check your hypothesis. I did what I should have done in the first place. Pass an error object into NSFileManager and see what it reports. Yeah, it was a case of uninitialised values, and was relatively easy to track down once I'd done that. As to why @dynamic is there, I thought that was the proper way to implement a property where the implementation was supplied by me rather than synthesised. Is that not the case? You don't need @dynamic for properties where you supply the accessors at compilation time. It's only necessary for when the accessors aren't apparently available but will be at runtime. For example, by dynamically loading a category or self-modifying code. (NSManagedObject uses something like the latter.) Thanks, this was clearly my misunderstanding the way it worked. I've cleaned it up. Cheers, Arved ___ 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: Open a new terminal tab or window from a Cocoa app at a certain directory without using NSAppleScript?
Well, I found this: http://code.google.com/p/cdto/source/browse/plugins/terminal/CD2Terminal.m?spec=svn20c4d028f197a6810230ddff969de81c4b23876dr=20c4d028f197a6810230ddff969de81c4b23876d And got the terminal opening in a new window at the path. So I now need to find how I can set the settings and have it open a new tab instead of window. On Thu, Jan 26, 2012 at 10:13 AM, Andrew andrewrwr+cocoa...@gmail.comwrote: I would like to perform the same logic as the New Terminal Tab at Folder service in Finder in my Cocoa app. The only code I found via Google is all using AppleScript to open the Terminal.app, but nothing I found was a Cocoa interface besides 3rd party terminal apps (iTerm, iTerm2). Is there a better way than using NSAppleScript to do this? I do not see any core libraries for the terminal app, but perhaps I am just looking in the wrong location. If I were to use NSWorkspace, I tried using the open at the command line, but I am not able to: 1. figure out how to open a new tab as opposed to a window 2. not have to run a program 3. it does not open the default terminal theme Thanks, Andrew ___ 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: Open a new terminal tab or window from a Cocoa app at a certain directory without using NSAppleScript?
Well, I figured it out for myself. Posting here in case anyone else
wants to do the same:
- (void)openTerminal:(id)sender
{
TerminalApplication* termApp = [SBApplication
applicationWithBundleIdentifier:@com.apple.terminal];
NSString *dir = // Get your directory here
NSString *cmd = [NSString stringWithFormat:@cd \%@\; clear,
dir]; // Assumes bash, which is okay for me, but maybe not others.
TerminalWindow *window = nil;
if (termApp.windows.count 0)
{
// Use the first window:
window = [termApp.windows objectAtIndex:0];
}
TerminalSettingsSet *settings = [termApp startupSettings];
TerminalTab *newTab = [termApp doScript:cmd in:window];
[newTab setCurrentSettings:settings];
[newTab setSelected:YES];
[termApp activate];
}
On Thu, Jan 26, 2012 at 11:02 AM, Andrew andrewrwr+cocoa...@gmail.com wrote:
Well, I found this:
http://code.google.com/p/cdto/source/browse/plugins/terminal/CD2Terminal.m?spec=svn20c4d028f197a6810230ddff969de81c4b23876dr=20c4d028f197a6810230ddff969de81c4b23876d
And got the terminal opening in a new window at the path. So I now need to
find how I can set the settings and have it open a new tab instead of window.
On Thu, Jan 26, 2012 at 10:13 AM, Andrew andrewrwr+cocoa...@gmail.com wrote:
I would like to perform the same logic as the New Terminal Tab at Folder
service in Finder in my Cocoa app. The only code I found via Google is all
using AppleScript to open the Terminal.app, but nothing I found was a Cocoa
interface besides 3rd party terminal apps (iTerm, iTerm2). Is there a better
way than using NSAppleScript to do this?
I do not see any core libraries for the terminal app, but perhaps I am just
looking in the wrong location.
If I were to use NSWorkspace, I tried using the open at the command line,
but I am not able to:
figure out how to open a new tab as opposed to a window
not have to run a program
it does not open the default terminal theme
Thanks,
Andrew
___
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: Atta Boys, 4 bags-full
On Jan 26, 2012, at 9:12 AM, John Love wrote: In addition, I tried and tried to get an App Store rep to tell me how to de-pixelate all my images (one of their complaints leading to rejection). Give me the name of a specific piece of software and I'll try to use it (praying that it wasn't PhotoShop = $$$). Literally, silence. … spent hours with the App Store … but just a few minutes with Apple Business and Manna from Heaven. Do I have to ask what's wrong with this picture? I understand your frustration, but the reviewers’ job is to enforce guidelines, not to teach developers. They have a huge workload and pretty much all they can do is check off things that need to be fixed. It’s like you were asking an IRS auditor to teach you how to do double-entry bookkeeping. :) I’m glad you found the forums / mailing lists; there are a lot of helpful people. There are also any number of books and online tutorials for these sorts of things. —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
Re: Open a new terminal tab or window from a Cocoa app at a certain directory without using NSAppleScript?
On Jan 26, 2012, at 9:13 AM, Andrew wrote: The only code I found via Google is all using AppleScript to open the Terminal.app, but nothing I found was a Cocoa interface besides 3rd party terminal apps (iTerm, iTerm2). Is there a better way than using NSAppleScript to do this? Not that I’m aware of. NSAppleScript is a perfectly valid way to do inter-application communication, so don’t think of this as a kludge. —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
Re: How to open CMYK TIF in Cocoa?
On Jan 26, 2012, at 8:25 AM, Todd Freese wrote: The problem seems to be with the embedded alpha channel in the TIF. It is always using the alpha when you try to do anything with the file. Is there an easy way to avoid this? In my case, I need the full image without the alpha. Isn’t it the expected behavior for it to use the alpha channel if there’s one present? That doesn’t sound like a bug to me. If you want to strip out the alpha channel, you may need to load the image into a pixmap and then manually set the alpha component to 1.0 in all pixels. I’m not sure if there’s a graphics call to do this, or if you need to walk through the pixels in memory and manually OR 0xFF into the alpha component. —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
Re: boundingRectWithSize problem?
I had exactly the same problem and solved it by using the
NSStringDrawingUsesDeviceMetrics option instead of
NSStringDrawingDisableScreenFontSubstitution.
Tim
Am 25.01.2012 um 16:26 schrieb Tony Pollard:
Hi folks,
I'm having a strange problem with NSAttributedString boundingRectWithSize in
getting the needed height for a fixed width. It works 99% of the time, but
it consistently underestimates the height for certain text (by approximately
one line). There doesn't appear to be a pattern for the text that works and
the text that fails (tested on 10.6 and 10.7).
The code is:
NSRect textRect = [attrString boundingRectWithSize:NSMakeSize(300.0, 0.0)
// Width 300, any height (max height also
fails)
options: NSStringDrawingUsesLineFragmentOrigin |// Needed for
multi-line
NSStringDrawingDisableScreenFontSubstitution];
The attributed strings are built from data sources. Here's one that fails:
Printing description of attrString:
n. {
CdctPhraseType = Grammer;
NSColor = NSCalibratedRGBColorSpace 0.878431 0.0980392 0.160784 1;
NSFont = LucidaGrande 9.00 pt. P [] (0x50bbd0) fobj=0x50b7b0, spc=2.85;
}A hopper is a device shaped like a large funnel, in which substances such as
grain, coal, animal food, or sand can be stored.{
CdctPhraseType = Transition;
NSColor = NSCalibratedRGBColorSpace 0.227451 0.54902 0.258824 1;
NSFont = LucidaGrande 9.00 pt. P [] (0x50bbd0) fobj=0x50b7b0, spc=2.85;
}
{
}F.ex: Large trailers came along and tipped it into a big hopper.{
CdctPhraseType = Transition;
NSColor = NSCalibratedRGBColorSpace 0.227451 0.54902 0.258824 1;
NSFont = LucidaGrande 9.00 pt. P [] (0x50bbd0) fobj=0x50b7b0, spc=2.85;
}
The resulting Rect is too short by about 9 pixels. Anyone had the same
problem?
Tony Pollard
___
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/tim%40timschroeder.net
This email sent to t...@timschroeder.net
___
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
Intermittent IKImageBrowserView crash
I have an intermittent crasher that appears to be associated with IKImageBrowserView, but I have been unable to find a technique to get to the source of the problem. I have a dozen crash reports from the last month from beta testers of PhotoLinker, which now uses ARC. The crash reports all point to a crash in -release, none of the stack traces appear to have any of my code, and in all cases there appears to be some IKImageBrowserView activity. Here are some of the most recent crash reports, http://jeffreyearly.com/crashreports.html A big problem is that I have been unable to reproduce the crash on my own machine, so I'm stuck mining through crash reports and making wild guesses as to the problem. If anybody has guidance on how to get to the source of the problem this would be greatly appreciated. Thanks in advance, Jeffrey ___ 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: Open a new terminal tab or window from a Cocoa app at a certain directory without using NSAppleScript?
On Jan 26, 2012, at 10:22 AM, Andrew wrote: NSString *cmd = [NSString stringWithFormat:@cd \%@\; clear”, dir]; // Assumes bash, which is okay for me, but maybe not others. Watch out — that line has quoting problems. If the path to the directory contains double-quotes, dollar signs, backslashes, exclamation points or various other shell meta-characters, that command will at best fail and at worst do something unexpected. There’s even a remote chance this could be used as an exploit to run malicious code, depending on how that directory path got created. For example, if someone could create a directory named ;rm -rf ~; (including the quotes) it would be quite dangerous to use your code to open a Terminal window on it or any subdirectory of it. Given that many document formats are actually packaged directory trees, I can think of ways this could be done without a user's knowledge... To work around this I suggest using single-quotes instead, and preprocessing the string to insert a backslash in front of any exclamation point or single-quote. I *think* that will be enough. —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
- (NSPoint)convertBaseToScreen:(NSPoint)point
The docs say that - (NSPoint)convertBaseToScreen:(NSPoint)point is deprecated and to use - (NSRect)convertRectToScreen:(NSRect)aRect So, does one create a rect whose origin is the point in question and whose size is zero? So here is some code: NSWindow *keyWindow = [NSApp keyWindow]; NSRect r; r.origin.x = lpPoint-x; r.origin.y = lpPoint-y; r.size.width = 0; r.size.height = 0; NSRect cr = [keyWindow convertRectToScreen:r]; The last line throws one error and a warning: No viable conversion from 'id' to 'NSRect' (aka '_NSrect') instance method '-convertRectToScreen' not found (return type defaults to 'id') But -convertRectToScreen ins in the NSWindow reference. So what am I missing? -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: - (NSPoint)convertBaseToScreen:(NSPoint)point
On Thu, Jan 26, 2012 at 11:41 AM, koko k...@highrolls.net wrote:
The docs say that - (NSPoint)convertBaseToScreen:(NSPoint)point is deprecated
and to use - (NSRect)convertRectToScreen:(NSRect)aRect
So, does one create a rect whose origin is the point in question and whose
size is zero?
Just like any other rect: use NSMakeRect(), or just set the fields directly.
But more importantly, read the section of the AppKit release notes
named Changes for Resolution Independence:
http://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKit.html
In Mac OS X 10.7, the base coordinate system doesn't exist anymore;
windows and screens share the same coordinate system, modulo the
origin. All -[NSWindow convertRectToScreen:] does is translate the
passed-in rect by the window's origin. No scaling is required.
So you could just as easily translate a point yourself:
NSWindow window = /* ...*/
NSPoint pointInWindowSpace = /* ... */;
NSPoint pointInScreenSpace;
NSPoint windowOrigin = [window frame].origin;
pointInScreenSpace.x = pointInWindowSpace.x - (windowOrigin.x);
pointInScreenSpace.y = pointInWindowSpace.y - (windowOrigin.y);
Nonetheless, you should file a radar asking for -[NSWindow
convertPoint{To,From}Screen:]. This is precisely the kind of tedious
code that I find myself screwing up on a regular basis. Heck, I
might've even screwed it up in this email.
NSRect cr = [keyWindow convertRectToScreen:r];
The last line throws one error and a warning:
No viable conversion from 'id' to 'NSRect' (aka '_NSrect')
instance method '-convertRectToScreen' not found (return type defaults to
'id')
But -convertRectToScreen ins in the NSWindow reference.
So what am I missing?
Are you not building with the 10.7 SDK? Or is your Maximum Deployment
Version set to 10.6 or earlier?
--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
ARC and blocks
Hello,
This code is given in the Transitioning to ARC Release Notes as an
example of accomodating blocks in an ARC environment:
__block MyViewController *myController = [[MyViewController alloc]
init…];
// ...
myController.completionHandler = ^(NSInteger result) {
[myController dismissViewControllerAnimated:YES completion:nil];
myController = nil;
};
Supposedly this avoids a retain cycle. But where is the cycle? At
least two objects are needed for a cycle. What is the second one?
Excuse me if I'm being dumb.
Jan E.
___
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: - (NSPoint)convertBaseToScreen:(NSPoint)point
I did not read far enough … not using 10.7 SDK is my problem. I will take Kyle's suggestion to file a Radar for NSWindow convertPoint (to, from) Screen -koko On Jan 26, 2012, at 2:43 PM, Marco S Hyman wrote: On Jan 26, 2012, at 11:41 AM, koko wrote: But -convertRectToScreen ins in the NSWindow reference. So what am I missing? • Available in Mac OS X v10.7 and later. Are you using the 10.7 SDK? ___ 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: Open a new terminal tab or window from a Cocoa app at a certain directory without using NSAppleScript?
Le 26 janv. 2012 à 20:30, Jens Alfke a écrit : On Jan 26, 2012, at 10:22 AM, Andrew wrote: NSString *cmd = [NSString stringWithFormat:@cd \%@\; clear”, dir]; // Assumes bash, which is okay for me, but maybe not others. Watch out — that line has quoting problems. If the path to the directory contains double-quotes, dollar signs, backslashes, exclamation points or various other shell meta-characters, that command will at best fail and at worst do something unexpected. There’s even a remote chance this could be used as an exploit to run malicious code, depending on how that directory path got created. For example, if someone could create a directory named ;rm -rf ~; (including the quotes) it would be quite dangerous to use your code to open a Terminal window on it or any subdirectory of it. Given that many document formats are actually packaged directory trees, I can think of ways this could be done without a user's knowledge... To work around this I suggest using single-quotes instead, and preprocessing the string to insert a backslash in front of any exclamation point or single-quote. I *think* that will be enough. And before backslash too I think (what if the directory name isd\';rm -rf ~;\' ) -- Jean-Daniel ___ 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: ARC and blocks
On Jan 26, 2012, at 1:51 PM, Jan E. Schotsman wrote:
Hello,
This code is given in the Transitioning to ARC Release Notes as an example
of accomodating blocks in an ARC environment:
__block MyViewController *myController = [[MyViewController alloc] init…];
// ...
myController.completionHandler = ^(NSInteger result) {
[myController dismissViewControllerAnimated:YES completion:nil];
myController = nil;
};
Supposedly this avoids a retain cycle. But where is the cycle? At least two
objects are needed for a cycle. What is the second one?
Excuse me if I'm being dumb.
myController retains/copies the block. Then the block retains myController
(under ARC __block variables are strong references, so they get retained). Thus
you are left with myController retains the block which retains myController.
--
David Duncan
___
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: ARC and blocks
Le 26 janv. 2012 à 22:51, Jan E. Schotsman a écrit :
Hello,
This code is given in the Transitioning to ARC Release Notes as an example
of accomodating blocks in an ARC environment:
__block MyViewController *myController = [[MyViewController alloc] init…];
// ...
myController.completionHandler = ^(NSInteger result) {
[myController dismissViewControllerAnimated:YES completion:nil];
myController = nil;
};
Supposedly this avoids a retain cycle. But where is the cycle? At least two
objects are needed for a cycle. What is the second one?
The first object if myController.
The second object is the block.
myController retains the block.
the block retains myController.
You have your retain cycle.
-- Jean-Daniel
___
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: ARC and blocks
On 1/26/12 1:51 PM, Jan E. Schotsman wrote:
Hello,
This code is given in the Transitioning to ARC Release Notes as an
example of accomodating blocks in an ARC environment:
__block MyViewController *myController = [[MyViewController alloc] init…];
// ...
myController.completionHandler = ^(NSInteger result) {
[myController dismissViewControllerAnimated:YES completion:nil];
myController = nil;
};
Supposedly this avoids a retain cycle. But where is the cycle? At least
two objects are needed for a cycle. What is the second one?
Excuse me if I'm being dumb.
The block normally would retain variables it captures from its scope,
including, in this case, myController. Presumably myController would
retain the completionHandler block, ergo a retain cycle.
However, __block variables are NOT retained automatically by a block
during capture, so this breaks the retain cycle.
So, when myController is nil'ed out, ARC releases it, and it releases
the block in turn. No leaks/abandoned memory.
A special form of this is the idiom:
__block id mySelf = self;
^{
[mySelf doSomething];
}
This lets you use self in a block without retaining it.
--
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.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: ARC and blocks
On Jan 26, 2012, at 1:51 PM, Jan E. Schotsman wrote: Supposedly this avoids a retain cycle. But where is the cycle? At least two objects are needed for a cycle. What is the second one? The block. When a block is copied (which it has to be, in order to be called later after the calling function has returned) it becomes a bona fide object. And this object retains objects in variables that are referred to in the block's code; myController in this case. And since myController presumably has a reference to the block too (so that it can call it), you have a cycle. The extra line to set myController = nil at the end breaks the cycle. —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
Re: ARC and blocks
On 26 Jan 2012, at 3:51 PM, Jan E. Schotsman wrote:
This code is given in the Transitioning to ARC Release Notes as an example
of accomodating blocks in an ARC environment:
__block MyViewController *myController = [[MyViewController alloc] init…];
There is a MyViewController object named myController
myController.completionHandler = ^(NSInteger result)
It retains a void(^)(NSInteger) block (or a copy thereof.
{
[myController dismissViewControllerAnimated:YES completion:nil];
The block refers to myController, so the block automatically retains it.
myController - block is a cycle
myController = nil;
Now the block no longer refers to myController, so myController is released.
};
When myController is deallocated, it releases the block. No cycle.
Supposedly this avoids a retain cycle. But where is the cycle? At least two
objects are needed for a cycle. What is the second one?
— F
___
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: ARC and blocks
On 2012-01-26, at 3:51 PM, Jan E. Schotsman wrote:
Hello,
This code is given in the Transitioning to ARC Release Notes as an example
of accomodating blocks in an ARC environment:
__block MyViewController *myController = [[MyViewController alloc] init…];
// ...
myController.completionHandler = ^(NSInteger result) {
[myController dismissViewControllerAnimated:YES completion:nil];
myController = nil;
};
Supposedly this avoids a retain cycle. But where is the cycle? At least two
objects are needed for a cycle. What is the second one?
ARC has changed the behaviour of __block [1] so that it forces a retain of the
value (previously, it forced a variable to behave like a weak property). This
(as I understand it) is necessary because otherwise the value would be released
at the end of the current method, which is obviously not what you want. Note
that, even if you don't specify myController as __block, the variable will
still be declared with an implicit __strong attribute.
The key is that, by declaring it as __block, you give your block the option to
alter its contents. At the end of the block, you simply force it to Nil, which
implicitly releases it, thus breaking the retain cycle. Pretty neat, eh?
HTH,
—Mt.
[1]: See the CLANG docs, section 7.5.
___
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: ARC and blocks
On Jan 26, 2012, at 3:51 PM, Jan E. Schotsman wrote:
This code is given in the Transitioning to ARC Release Notes as an example
of accomodating blocks in an ARC environment:
__block MyViewController *myController = [[MyViewController alloc] init…];
// ...
myController.completionHandler = ^(NSInteger result) {
[myController dismissViewControllerAnimated:YES completion:nil];
myController = nil;
};
Supposedly this avoids a retain cycle. But where is the cycle? At least two
objects are needed for a cycle. What is the second one?
Excuse me if I'm being dumb.
The block is an object. It has retained myController. myController has
retained the block because it's been assigned to the completionHandler property.
By the way, a retain cycle doesn't need two objects. An object can retain
itself and that's a cycle.
Cheers,
Ken
___
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: ARC and blocks
On Jan 26, 2012, at 1:51 PM, Jan E. Schotsman wrote:
This code is given in the Transitioning to ARC Release Notes as an example
of accomodating blocks in an ARC environment:
__block MyViewController *myController = [[MyViewController alloc] init…];
// ...
myController.completionHandler = ^(NSInteger result) {
[myController dismissViewControllerAnimated:YES completion:nil];
myController = nil;
};
Supposedly this avoids a retain cycle. But where is the cycle? At least two
objects are needed for a cycle. What is the second one?
Remember that blocks are objects too. If you are not careful then the view
controller points to the block object and the block object points back to the
view controller.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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: ARC and blocks
Without ARC, you would use __block to prevent the block from retaining the
object and causing the retain cycle. With ARC, however, the object is retained
when you put it into the variable, so to avoid a retain cycle, you have to
declare it like so:
__unsafe_unretained __block MyViewController *myController = …
It looks awful, yes, but without the first piece we were having extreme memory
leaks.
Jeff Kelley
On Jan 26, 2012, at 5:34 PM, David Duncan wrote:
On Jan 26, 2012, at 1:51 PM, Jan E. Schotsman wrote:
Hello,
This code is given in the Transitioning to ARC Release Notes as an example
of accomodating blocks in an ARC environment:
__block MyViewController *myController = [[MyViewController alloc] init…];
// ...
myController.completionHandler = ^(NSInteger result) {
[myController dismissViewControllerAnimated:YES completion:nil];
myController = nil;
};
Supposedly this avoids a retain cycle. But where is the cycle? At least two
objects are needed for a cycle. What is the second one?
Excuse me if I'm being dumb.
myController retains/copies the block. Then the block retains myController
(under ARC __block variables are strong references, so they get retained).
Thus you are left with myController retains the block which retains
myController.
--
David Duncan
___
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: ARC and blocks
On Jan 26, 2012, at 2:44 PM, Conrad Shultz wrote: However, __block variables are NOT retained automatically by a block during capture, so this breaks the retain cycle. This is not true under ARC, where __block variables also retain. -- David Duncan ___ 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: ARC and blocks
On Thu, Jan 26, 2012 at 2:44 PM, Conrad Shultz con...@synthetiqsolutions.com wrote: However, __block variables are NOT retained automatically by a block during capture, so this breaks the retain cycle. __block variables *are* retained under ARC: http://clang.llvm.org/docs/AutomaticReferenceCounting.html#misc.blocks The important bit of the code that Jan cited isn't that myController is annotated with __block, it's that the block nils out the myController variable when it executes. This works because the block is a completion handler—it's only executed once, so there's a sensible time for it to engage in cleanup. Long-lived block arguments, however, need a different strategy. This is why the Transitioning to ARC Release Notes also recommend strategies that use __weak (or __unsafe_unretained if you're targeting older OSes). --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: ARC and blocks
On 1/26/12 4:21 PM, Kyle Sluder wrote: On Thu, Jan 26, 2012 at 2:44 PM, Conrad Shultz con...@synthetiqsolutions.com wrote: However, __block variables are NOT retained automatically by a block during capture, so this breaks the retain cycle. __block variables *are* retained under ARC: http://clang.llvm.org/docs/AutomaticReferenceCounting.html#misc.blocks The important bit of the code that Jan cited isn't that myController is annotated with __block, it's that the block nils out the myController variable when it executes. This works because the block is a completion handler—it's only executed once, so there's a sensible time for it to engage in cleanup. Long-lived block arguments, however, need a different strategy. This is why the Transitioning to ARC Release Notes also recommend strategies that use __weak (or __unsafe_unretained if you're targeting older OSes). D'oh. Thanks for the pointer (no pun intended). I guess I still have some reading to do about ARC... I thought that keeping the various __bridge attributes straight was hard enough, now I have to go read up on interaction with blocks too. -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.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
Full-Height Toolbar Item
Hi Everyone, I'm looking for a way to make a view-based Toolbar Item that occupies the full height of the toolbar (i.e. including the space normally reserved for the toolbar item's label). Xcode 4 does this for its status display, and I have a similar need in my application. The NSToolbar and NSToolbarItem definitions don't appear to make this possible, but perhaps there is something I've overlooked. Thanks -Mark ___ 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: ARC and blocks
Hi,
So, when myController is nil'ed out, ARC releases it, and it releases
the block in turn. No leaks/abandoned memory.
A special form of this is the idiom:
__block id mySelf = self;
^{
[mySelf doSomething];
}
Wouldn't using __weak instead of __block be better and clearer in the above
context?
Thanks,
Abdul
This lets you use self in a block without retaining it.
--
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.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/asowayan%40vectorworks.net
This email sent to asowa...@vectorworks.net
___
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: ARC and blocks
On Jan 27, 2012, at 6:44 AM, Conrad Shultz wrote:
On 1/26/12 1:51 PM, Jan E. Schotsman wrote:
The block normally would retain variables it captures from its scope,
including, in this case, myController. Presumably myController would
retain the completionHandler block, ergo a retain cycle.
However, __block variables are NOT retained automatically by a block
during capture, so this breaks the retain cycle.
under ARC, __block variables ARE retained automatically, if they weren't, there
wouldn't be a cycle.
So, when myController is nil'ed out, ARC releases it, and it releases
the block in turn. No leaks/abandoned memory.
That is correct, and the variable has to be a __block variable to allow you to
modify it.
A special form of this is the idiom:
__block id mySelf = self;
^{
[mySelf doSomething];
}
This lets you use self in a block without retaining it.
Not so under ARC, mySelf retains self, but it's ok, the block releases it at
the end so it all balances out.
___
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
Binding Leak - Turn off Raises For Not Applicable Keys
Very simple setup in a test project. I have an array controller with content bound to App Delegate's objects array, and I have a slider control bound to the controller's selection.value. I set App Delegate's objects array to an array with an NSString in it. So the NSString *does not respond* to value, so normally this would raise an exception. If you turn off Raises For Not Applicable Keys on the slider's Value binding, then the application leaks an NSString from within valueForKeyPath:. http://www.sethwillits.com/temp/BindingRaiseLeak.zip http://sethwillits.com/temp/upshot/upshot_xMuBExbD.jpg It leaks for each binding with the setting turned off, each time the selection changes. Thoughts? Will radar it if I'm not missing something. -- Seth Willits ___ 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: ARC and blocks
On 2012-01-26, at 6:09 PM, Jeff Kelley wrote: Without ARC, you would use __block to prevent the block from retaining the object and causing the retain cycle. With ARC, however, the object is retained when you put it into the variable, so to avoid a retain cycle, you have to declare it like so: __unsafe_unretained __block MyViewController *myController = … It looks awful, yes, but without the first piece we were having extreme memory leaks. Maybe I'm reading this wrong, but I think this might be a bit too unsafe. If you declare something as __unsafe_unretained, ARC won't try to track the variable through its lifetime, so if for some reason that variable is deallocated and then your block gets called, your app will crash. The OP's code feels a bit safer to me: it retains the variable strongly, then Nils it at the end of the block to force a release. There's no retain cycle or memory leak, and the __block variable is guaranteed to stick around until your block is done with it. —Mt. ___ 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 open CMYK TIF in Cocoa?
The issue is that it only loads the pixels that are allowed by the alpha. Almost no graphic program does this. It should load all the pixels and give you the option of using the alpha if needed. Another words, there is no way to just get the full image. From my research, the original TIFF spec did not allow for alpha when the file is CMYK. It did for RGB. It was later updated by Adobe to support it which is why some programs support it and others do not. At least that is what several web sites state. You can't go the route of walking through the pixels and setting the alpha because the original data was already lost on file read. I ended up building and linking to libTIFF library which works like a champ. Todd On Jan 26, 2012, at 12:33 PM, Jens Alfke wrote: On Jan 26, 2012, at 8:25 AM, Todd Freese wrote: The problem seems to be with the embedded alpha channel in the TIF. It is always using the alpha when you try to do anything with the file. Is there an easy way to avoid this? In my case, I need the full image without the alpha. Isn’t it the expected behavior for it to use the alpha channel if there’s one present? That doesn’t sound like a bug to me. If you want to strip out the alpha channel, you may need to load the image into a pixmap and then manually set the alpha component to 1.0 in all pixels. I’m not sure if there’s a graphics call to do this, or if you need to walk through the pixels in memory and manually OR 0xFF into the alpha component. —Jens __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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
Binding Leak - Turn off Raises For Not Applicable Keys
Very simple setup in a test project. I have an array controller with content bound to App Delegate's objects array, and I have a slider control bound to the controller's selection.value. I set App Delegate's objects array to an array with an NSString in it. So the NSString *does not respond* to value, so normally this would raise an exception. If you turn off Raises For Not Applicable Keys on the slider's Value binding, then the application leaks an NSString from within valueForKeyPath:. http://www.sethwillits.com/temp/BindingRaiseLeak.zip http://sethwillits.com/temp/upshot/upshot_xMuBExbD.jpg It leaks for each binding with the setting turned off, each time the selection changes. -- Note that any NSObjectController will do, it's not just NSArrayController. Also, the leaked string is the binding's controller key value selection. I would just file this and move on, except I'm planning to rely a lot on setting NSRaisesForNotApplicableKeysBindingOption to NO so that it will automatically disable controls which are for editing properties that one or more objects in the array controller's selection don't support. I'm not sure how else I can accomplish this easily while avoiding the leak. It does seem I can implement a getter for every key and return NSNotApplicableMarker, and that appropriately disables the control and doesn't leak. valueForKeyPath: nor valueForUndefinedKey: is called on the instances so I can't try it in one spot there. Thoughts? Will radar it if I'm not missing something. -- Seth Willits ___ 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: ARC and blocks
On Jan 26, 2012, at 6:04 PM, Marco Tabini wrote: On 2012-01-26, at 6:09 PM, Jeff Kelley wrote: Without ARC, you would use __block to prevent the block from retaining the object and causing the retain cycle. With ARC, however, the object is retained when you put it into the variable, so to avoid a retain cycle, you have to declare it like so: __unsafe_unretained __block MyViewController *myController = … It looks awful, yes, but without the first piece we were having extreme memory leaks. Maybe I'm reading this wrong, but I think this might be a bit too unsafe. If you declare something as __unsafe_unretained, ARC won't try to track the variable through its lifetime, so if for some reason that variable is deallocated and then your block gets called, your app will crash. The OP's code feels a bit safer to me: it retains the variable strongly, then Nils it at the end of the block to force a release. There's no retain cycle or memory leak, and the __block variable is guaranteed to stick around until your block is done with it. The solutions in ARC from best to worst are: 1. Use `__block` and set it to nil when you are done. This works fine for one-shot callbacks, for example. There is a temporary retain cycle but the cycle is broken by the assignment to nil. 2. Use `__block __weak`. The weak pointer breaks the retain cycle. 3. Use `__block __unsafe_unretained`. The unretained pointer breaks the retain cycle. This is more fragile than `__block __weak`, but may be necessary if you are deploying to iOS older than 5.0 or OS X older than 10.7. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: ARC and blocks
On Jan 27, 2012, at 10:04 AM, Marco Tabini wrote: On 2012-01-26, at 6:09 PM, Jeff Kelley wrote: Without ARC, you would use __block to prevent the block from retaining the object and causing the retain cycle. With ARC, however, the object is retained when you put it into the variable, so to avoid a retain cycle, you have to declare it like so: __unsafe_unretained __block MyViewController *myController = … It looks awful, yes, but without the first piece we were having extreme memory leaks. Maybe I'm reading this wrong, but I think this might be a bit too unsafe. If you declare something as __unsafe_unretained, ARC won't try to track the variable through its lifetime, so if for some reason that variable is deallocated and then your block gets called, your app will crash. The OP's code feels a bit safer to me: it retains the variable strongly, then Nils it at the end of the block to force a release. There's no retain cycle or memory leak, and the __block variable is guaranteed to stick around until your block is done with it. Yes - that __unsafe_unretained pattern is in the transition guide, but it's not recommended and seems to be there more for illustration of what pre-ARC code was equivalent to. Just setting the __block variable nil will work fine under ARC and pre-ARC runtimes so, unless the code in that block is really complex and it's hard to set the block variable nil in all relevant places, I'd definitely use the OPs code (which is what the transition guide seems to recommend also). ___ 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: ARC and blocks
On Jan 26, 2012, at 10:45 PM, Roland King wrote: On Jan 27, 2012, at 10:04 AM, Marco Tabini wrote: On 2012-01-26, at 6:09 PM, Jeff Kelley wrote: Without ARC, you would use __block to prevent the block from retaining the object and causing the retain cycle. With ARC, however, the object is retained when you put it into the variable, so to avoid a retain cycle, you have to declare it like so: __unsafe_unretained __block MyViewController *myController = … It looks awful, yes, but without the first piece we were having extreme memory leaks. Maybe I'm reading this wrong, but I think this might be a bit too unsafe. If you declare something as __unsafe_unretained, ARC won't try to track the variable through its lifetime, so if for some reason that variable is deallocated and then your block gets called, your app will crash. The OP's code feels a bit safer to me: it retains the variable strongly, then Nils it at the end of the block to force a release. There's no retain cycle or memory leak, and the __block variable is guaranteed to stick around until your block is done with it. Yes - that __unsafe_unretained pattern is in the transition guide, but it's not recommended and seems to be there more for illustration of what pre-ARC code was equivalent to. Just setting the __block variable nil will work fine under ARC and pre-ARC runtimes so, unless the code in that block is really complex and it's hard to set the block variable nil in all relevant places, I'd definitely use the OPs code (which is what the transition guide seems to recommend also). I agree, but in the case I ran into, I passed more than one block to the object, which would then call one of them depending on the outcome of its operations. Since not every block would be called, those temporary retain cycles would last forever. I'm also using ARC and targeting iOS 4.3. If you're only setting one block and you know it's going to be called, setting it to nil ought to do the trick. Jeff Kelley ___ 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
afterDelay not working?
I have a simple NSView class that is an indicator light that I want to flash.
Here are the two methods to perform the flash:
-(void) performFlash {
if (ledOn) return;
ledOn = YES;
[selfsetNeedsDisplay:YES];
[selfperformSelector:@selector(endFlash) withObject:nilafterDelay:0.1];
}
-(void) endFlash {
if (!ledOn) return;
NSLog(@Turning off LED);
ledOn = NO;
[selfsetNeedsDisplay:YES];
}
For some reason the afterDelay method isn't working. I know my simple methods
work because when I call endFlash independently it works just fine. I have
tried every permutation of the afterDelay method, I tried putting it in the
delegate class, I tried using a NSTimer scheduleTimerWithTimeInterval: with no
success.
I am completely stumped on something that should be extremely straightforward.
Is there ANY instance where the afterDelay method wont work? I'm pulling my
hair out on this one.
Thanks
GW
___
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 open CMYK TIF in Cocoa?
On Jan 26, 2012, at 6:21 PM, Todd Freese wrote: The issue is that it only loads the pixels that are allowed by the alpha. Almost no graphic program does this. It should load all the pixels and give you the option of using the alpha if needed. Another words, there is no way to just get the full image. I don't think that's true; it's just that when you render the image normally it takes the alpha into account, so it *looks* like some of the pixels aren't there. Modifying the alpha channel directly would reveal the pixels. Keep in mind that most Mac graphics programs (well, probably except Adobe's) are using the system libraries to read standard file formats. —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
Re: afterDelay not working?
On Jan 26, 2012, at 8:56 PM, GW Rodriguez wrote: For some reason the afterDelay method isn't working. I know my simple methods work because when I call endFlash independently it works just fine. I have tried every permutation of the afterDelay method, I tried putting it in the delegate class, I tried using a NSTimer scheduleTimerWithTimeInterval: with no success. The code you showed should work. How do you know the perform-after-delay isn't working? Did you set a breakpoint at the start of the -endFlash method to make sure it's not being called? This code is running on the main thread, right? Perform-after-delay probably won't work if invoked on a background thread that doesn't have a runloop. —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
Re: afterDelay not working?
Correct, it's not on a different thread. That's why I'm so confused as to why it's not working. :-/ GW Rodriguez Audio Technician South Coast Repertory (c) 909-720-4202 www.gwrodriguez.com On Jan 26, 2012, at 9:12 PM, Jens Alfke j...@mooseyard.com wrote: On Jan 26, 2012, at 8:56 PM, GW Rodriguez wrote: For some reason the afterDelay method isn't working. I know my simple methods work because when I call endFlash independently it works just fine. I have tried every permutation of the afterDelay method, I tried putting it in the delegate class, I tried using a NSTimer scheduleTimerWithTimeInterval: with no success. The code you showed should work. How do you know the perform-after-delay isn't working? Did you set a breakpoint at the start of the -endFlash method to make sure it's not being called? This code is running on the main thread, right? Perform-after-delay probably won't work if invoked on a background thread that doesn't have a runloop. —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
Re: afterDelay not working?
I imagine your run loop isn't being allowed to run in the default mode (NSDefaultRunLoopMode). I'd check this by pausing your program at the time that you would expect -endFlash to be called; your stack trace will might indicate that the run loop's being run recursively. Perhaps this occurring while the user's dragging something around in your view? ___ 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
