Crashing Problem calling postNotificationName
Hi,
I have a crashing problem when calling postNotificationName, the following
method is called from an Operation Queue method/thread. It is called on the
Main Thread (the operation queue method, uses performSelectorOnMainThread which
calls parseOperationCompleted below. I've tried copying theResultDictionary
or just passing it in the dictionary as is, same result.
Any ideas what could be causing the crash?
-(void) parseOperationComplete:(NSDictionary*) theResultDictionary
{
myUserInfoDictionary = [[NSMutableDictionary alloc] init];
[myUserInfoDictionary setObject:self.pUpdateString
forKey:kUserInfoLiveUpdateString];
[myUserInfoDictionary setObject:[theResultDictionary copy]
forKey:kUserInfoLiveUpdateDictionary];
[NSNotificationCenter defaultCenter] postNotificationName:kNotificationName
object:self userInfo:myUserInfoDictionary];
}
Thanks in advance for any help!
All the Best
Dave
___
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
Apple Developer Support?
Hi All, I've been trying to contact Apple Developer about my iOS and Mac Developer Memberships - there is a problem with the subscription, I've paid but they haven't activated me. I sent an email to euro...@apple.com and got a automated response with a follow up number. I waited a few days, but heard nothing so emailed again, nothing, and again, nothing. I've now sent 6 emails now to euro...@apple.com and not had a response in over 3 weeks! Does anyone know what is going on? Is this the correct email address? Who do I need to talk to get my membership sorted out? A phone number would be good as now it's Very Urgent! Thanks a lot any help. Dave ___ 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: Apple Developer Support?
It's the correct mail but I don't know what's going on your membership, try to call them directly Sent from my iPhone On 10 Sep 2013, at 15:15, Dave d...@looktowindward.com wrote: Hi All, I've been trying to contact Apple Developer about my iOS and Mac Developer Memberships - there is a problem with the subscription, I've paid but they haven't activated me. I sent an email to euro...@apple.com and got a automated response with a follow up number. I waited a few days, but heard nothing so emailed again, nothing, and again, nothing. I've now sent 6 emails now to euro...@apple.com and not had a response in over 3 weeks! Does anyone know what is going on? Is this the correct email address? Who do I need to talk to get my membership sorted out? A phone number would be good as now it's Very Urgent! Thanks a lot any help. Dave ___ 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/vavelinkevin%40icloud.com This email sent to vavelinke...@icloud.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: Crashing Problem calling postNotificationName
What do the debug logs for the crash say? At what point does the crash occur?
Is your program getting into parseOperationComplete? When you step through,
which line fails?
On 10 Sep 2013, at 12:08, Dave d...@looktowindward.com wrote:
Hi,
I have a crashing problem when calling postNotificationName, the following
method is called from an Operation Queue method/thread. It is called on the
Main Thread (the operation queue method, uses performSelectorOnMainThread
which calls parseOperationCompleted below. I've tried copying
theResultDictionary or just passing it in the dictionary as is, same result.
Any ideas what could be causing the crash?
-(void) parseOperationComplete:(NSDictionary*) theResultDictionary
{
myUserInfoDictionary = [[NSMutableDictionary alloc] init];
[myUserInfoDictionary setObject:self.pUpdateString
forKey:kUserInfoLiveUpdateString];
[myUserInfoDictionary setObject:[theResultDictionary copy]
forKey:kUserInfoLiveUpdateDictionary];
[NSNotificationCenter defaultCenter] postNotificationName:kNotificationName
object:self userInfo:myUserInfoDictionary];
}
Thanks in advance for any help!
All the Best
Dave
___
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/45rpmlists%40googlemail.com
This email sent to 45rpmli...@googlemail.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: Crashing Problem calling postNotificationName
On 2013 Sep 10, at 04:52, Pax 45rpmli...@googlemail.com wrote: What do the debug logs for the crash say? At what point does the crash occur? Is your program getting into parseOperationComplete? Yes, like Pax said, and also, assuming that Xcode stops and shows you a call stack, make sure you've got that damned slider at the bottom of the Debug Navigator set all the way to the right. Between the messages you get in the Debug Area and call stack in the Debug Navigator, crashes while posting notifications are usually pretty easy to troubleshoot. Most of them occur because an object which has been registered to receive the notification has been deallocced or does not respond to the message it has been registered to receive. Search your code for the notification name string or constant (looks like kNotificationName in your case) and consider those two possibilities in each case. If you still can't figure it out, copy and post what Xcode gives you in both the Debug Area and the Debug Navigator. You may need to improve your Xcode setup. ___ 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 vs Manual Reference Counting
On Sep 9, 2013, at 4:15 AM, Marcel Weiher marcel.wei...@gmail.com wrote: On Sep 9, 2013, at 11:33 , Tom Davie tom.da...@gmail.com wrote: On 9 Sep 2013, at 10:18, Jean-Daniel Dupas devli...@shadowlab.org wrote: And does the profiler explicitly shows that ARC runtime code is the culprit ? Yes, it does. Isn’t it strange how when someone says “oh, and ARC is faster”, without measurements, that passes without comment?\\ I believe you’ve been on this list long enough to know that nothing ever passes without comment. [] The last time I tried this with with Xcode 4.5, and after I’d added a bunch of extra autorelease pools all over the place which reduced ARC’s overhead to “only 50%. This in itself suggests to me that ARC causes a significant increase in the number of autoreleased objects (which surprised me given the runtime optimisation to get rid of autorelease/retain pairs in callee/caller). It shouldn’t really be surprising. ARC adds an astounding number of additional reference counting ops to all code involving object pointers. If that were compiled, ObjC would be completely unusable and slower than all the so-called scripting languages out there. So for things to be usable, ARC then has the optimizer try to undo most of the damage and finally adds some clever runtime hacks to mitigate the rest. Since the hacks and the remaining damage are somewhat orthogonal, you sometimes end up ahead and sometimes you end up behind. The other thing that should be considered when seeing heroic hacks like the autorelease-undoer is that such techniques rarely arise spontaneously from an idle moment of relaxed performance optimization. More usually, they happen because there is some sort of “ho lee f*k” moment, where performance regression is so bad/project-threatening that something drastic/heroic needs to be done. For what it’s worth, the autorelease optimization was planned; the performance problem it solves was extremely predictable, since it’s actually a noticeable performance problem in MRC code as well. Worth noting: trying to micro-optimize retains and releases by naively opting files out of ARC is a great way to defeat the autorelease optimization; if you do this and care about performance, I strongly suggest using +1 returns. But most of these micro-optimizations are achievable within ARC by adding a few __unsafe_unretained annotations. Also of note: the ARC optimizer relies on being able to see how objects are used, so code that’s using dusty old “I don’t ever want to write retain/releases workarounds like literally making every temporary variable a property is basically asking to be pessimized. It’s a happy coincidence that, in this case, a better code style corresponds to better performance. Overall, while we’re happy to see that some people see performance improvements, our expectation going in was always that ARC would cause some regressions, and that while in most code those would be lost in the noise, in some cases people would need to help ARC out with things like __unsafe_unretained. Ultimately, ARC is just a tool for improving your productivity as a programmer, not a magic button with no downsides. John. ___ 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 vs Manual Reference Counting
On 9 Sep 2013, at 09:30, Kevin Meaney k...@yvs.eu.com wrote: I don't know what it is like to convert an old project, but I would recommend ARC for new projects and I believe the time investment is worthwhile. Kevin If the project is of any size it's the pits! It's not worthing doing unless the Project Memory Management is completely Beswicked! Cheers Dave On 9 Sep 2013, at 09:18, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 9 sept. 2013 à 09:58, Tom Davie tom.da...@gmail.com a écrit : On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more. On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote: They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes. I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard. However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC. And does the profiler explicitly shows that ARC runtime code is the culprit ? -- 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/ktam%40yvs.eu.com This email sent to k...@yvs.eu.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/dave%40looktowindward.com This email sent to d...@looktowindward.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 vs Manual Reference Counting
On Sep 10, 2013, at 2:11 PM, Dave wrote: On 9 Sep 2013, at 09:30, Kevin Meaney k...@yvs.eu.com wrote: I don't know what it is like to convert an old project, but I would recommend ARC for new projects and I believe the time investment is worthwhile. Kevin If the project is of any size it's the pits! It's not worthing doing unless the Project Memory Management is completely Beswicked! Cheers Dave FWIW, I like to think of it this way: What's the compelling business reason for the change? Does it justify the effort, time and money you will put in to it? If so, how? If you can't answer those questions clearly with good reasons, then don't spend the time on it. ___ 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: 64-bit iOS
On Sep 10, 2013, at 2:01 PM, Abdul Sowayan asowa...@vectorworks.net wrote: I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and there is no virtual memory. Until you exceed the 4 gig limit, I don't see why this matters. Fragmentation of address space dealing with large blocks... And it's not really a 4GB limit, since there has to be a big chunk (likely 1GB) of address space reserved for the kernel. Of course there's a vast variety of apps for which this does not matter at all. But 64-bit makes available some really powerful techniques that are impractical otherwise. Also, wouldn't it be nice if tech writers knew anything about their subject? I got $20 right here that sez the A7 has more than 2 general-purpose registers--anybody want to take that bet ;-) (Maybe somebody doesn't know the difference between a register and a core???) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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 vs Manual Reference Counting
On Sep 10, 2013, at 21:52 , Ken Thomases k...@codeweavers.com wrote: On Sep 9, 2013, at 3:49 AM, Marcel Weiher wrote: The pattern I adopted long ago to avoid that sort of situation is to have an instance variable for my temps, in which case the code becomes: [self setTemp:newObject]; … do stuff … [self setTemp:nil]; or if you prefer dot syntax: self.temp = newObject; … do stuff … self.temp = nil; Even if you forget nilling, you at most have an extended lifetime of an object, not a leak. I also generally do the same in initialization code (but not in dealloc). For me, that simply got rid of reference-counting pain. Completely. Memory management is mediated by accessors, always. And accessors are generated. This technique is not safe for reentrant methods, Hi Ken, I should have been more clear: this technique is not needed for ordinary methods or ordinary local variables. I use it for those types of methods that are run asynchronously and that therefore want to retain a temp. Those sorts of methods are not re-entrant anyhow. Cheers, Marcel ___ 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: 64-bit iOS
Should be interesting to see how this plays out. When it comes to Java, when you switch from a 32-bit JVM to a 64-bit JVM there is a 10% penalty doing so. The main reason has to do with pointers. All pointers double in size. The effect might be less in a Objective-C program. Paul Franz On Sep 10, 2013, at 5:47 PM, Tom Davie tom.da...@gmail.com wrote: On 10 Sep 2013, at 23:30, Jean-Daniel Dupas devli...@shadowlab.org wrote: For ARM, 64 bit matters because the instruction set has been updated to provider better performances. I just hope the performance boost provided by this architecture change will be enough to balance the slow-down due to the increase of instruction and pointer size. Note, this was actually more significant on x86, where most of the mess caused by CISC (like having bugger all registers) got sorted out. Tom Davie ___ 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/paul.p.franz%40gmail.com This email sent to paul.p.fr...@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: 64-bit iOS
For ARM, 64 bit matters because the instruction set has been updated to provider better performances. I just hope the performance boost provided by this architecture change will be enough to balance the slow-down due to the increase of instruction and pointer size. Le 10 sept. 2013 à 22:01, Abdul Sowayan asowa...@vectorworks.net a écrit : Scott, I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and there is no virtual memory. Until you exceed the 4 gig limit, I don't see why this matters. Abdul Sent from my iPhone On Sep 10, 2013, at 3:44 PM, Scott Ribe scott_r...@elevated-dev.commailto:scott_r...@elevated-dev.com wrote: Well, since nobody else has commented, let me be the first to say: YES! YES! YES! THANK YOU APPLE!! -- Scott Ribe scott_r...@elevated-dev.commailto:scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.commailto: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.comhttp://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.netmailto: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/devlists%40shadowlab.org This email sent to devli...@shadowlab.org -- 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 vs Manual Reference Counting
Hi, You with all this talk of memory management, you'd think that Apple (or someone) would have come up with a hardware solution for this by now. In the 70's and 80's I worked on some firmware and hardware that would handle garbage collection in real time (with a little help from OS Software). On 80386's and 486's this made an incredible difference. Leaks could be detected at the point in which the leak occurred (e.g when all references to the object were gone) and either release it or throw an exception. I think the overhead was an 8 bytes descriptor which was help in a private fast store SRAM for those in the know!) for each object allocated. In those days we were limited by the cost of the capacity of the devices. If Apple were to implement something like this I think there would be a massive increase in performance and reliability Cheers Dave On 9 Sep 2013, at 23:45, Patrick Cusack livinginlosange...@mac.com wrote: I appreciate everyone's replies. It was a question asked in complete humility. I agree that computers can do analysis much better than humans and that the less code you write, the less you have to debug, so ARC makes a lot of sense. My question really stemmed from Apple's WWDC lecture which appeared to justify the switch on the flimsiest of grounds, ie no longer having to be confused by [NSString stringWithFormat:] vs [NSString initWithString:] which is a pretty easy memory management rule. As my main application is 32 bit (on account of the Quicktime API), I haven't had much exposure to ARC yet. So I will be upgrading with Mavericks to ARC and AVFoundation. Thanks for all of the comments. Patrick On Sep 9, 2013, at 7:29 AM, Alex Zavatone wrote: On Sep 9, 2013, at 3:58 AM, Tom Davie wrote: On 9 Sep 2013, at 09:44, Kyle Sluder k...@ksluder.com wrote: Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer. --Kyle Sluder On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote: Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance. I think the big point is that if the compiler can figure out what is no longer needed and can be released, and the compiler can do this (at a reasonable cost to performance), then this is a no brainer. I'm sure there are special cases where you would want to do your own memory management. And in this case, you can always flag the class files to turn off ARC and manage memory yourself. Simply put, not having to worry about this gives more brain stack space to fill up with all the other parts of Cocoa and Objective-C that we need to keep track of and saves valuable developer time since it's now rare to have to deal with manual memory management mistakes. Cheers, - Alex Zavatone ___ 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/dave%40looktowindward.com This email sent to d...@looktowindward.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: 64-bit iOS
If we have hardware (registers) and software support for 64bit, doesn't that mean the device can perform more calculations per CPU cycle? Some operations that would have taken 2 cycles may now be done in one. Surely that leads to a performance boost, right? On Tue, Sep 10, 2013 at 3:01 PM, Abdul Sowayan asowa...@vectorworks.netwrote: Scott, I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and there is no virtual memory. Until you exceed the 4 gig limit, I don't see why this matters. Abdul Sent from my iPhone On Sep 10, 2013, at 3:44 PM, Scott Ribe scott_r...@elevated-dev.com mailto:scott_r...@elevated-dev.com wrote: Well, since nobody else has commented, let me be the first to say: YES! YES! YES! THANK YOU APPLE!! -- Scott Ribe scott_r...@elevated-dev.commailto:scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.commailto: 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 http://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.netmailto: 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/spam%40dixondata.com This email sent to s...@dixondata.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: 32bit vs 64bit and QuickTime/AVFoundation
I second what Mark said. I did exactly as he suggested. To move to 64-bit I isolated all QuickTime dependent code in a 32-bit only helper. The main app, the other helpers and a private framework are now fat binaries and I migrated all the media code to AVFoundation and related APIs. The 32-bit only helper is only used to handle legacy media that AVFoundation cannot handle. For reasons we cannot discuss publicly in this list there is help on our way that will allow us to get rid of this 32-bit only dependence for good. So do follow what Mark suggested. It is how I did. And if you check how Finder works with legacy media, you will notice that Apple itself followed the same strategy. HTH Joao To me, this seems like the wrong direction to move. This is sort of like saying you want to convert your OS X app to a Classic Mac OS app maintain support for some Mac OS API. I'd go 64-bit only for your main app. I'd leave the 32-bit helper separate. Isolate your dependence on this component. If you're lucky, it will become obsolete and you'll be able to replace it without affecting your app significantly. Setup an API layer in your 64-bit app that calls AVFoundation, but can optionally call out to your 32-bit helper app. As a general rule, I try to write more for the future and less for the past. That means moving to 64-bit apps as quickly as possible. My guess, 32-bit frameworks will go away in the not too distant future, see: 68K code PPC code, Carbon APIs, etc. 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
64-bit iOS
Well, since nobody else has commented, let me be the first to say: YES! YES! YES! THANK YOU APPLE!! -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: 64-bit iOS
On 10 Sep 2013, at 23:30, Jean-Daniel Dupas devli...@shadowlab.org wrote: For ARM, 64 bit matters because the instruction set has been updated to provider better performances. I just hope the performance boost provided by this architecture change will be enough to balance the slow-down due to the increase of instruction and pointer size. Note, this was actually more significant on x86, where most of the mess caused by CISC (like having bugger all registers) got sorted out. Tom Davie ___ 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 vs Manual Reference Counting
On Sep 9, 2013, at 3:49 AM, Marcel Weiher wrote: The pattern I adopted long ago to avoid that sort of situation is to have an instance variable for my temps, in which case the code becomes: [self setTemp:newObject]; … do stuff … [self setTemp:nil]; or if you prefer dot syntax: self.temp = newObject; … do stuff … self.temp = nil; Even if you forget nilling, you at most have an extended lifetime of an object, not a leak. I also generally do the same in initialization code (but not in dealloc). For me, that simply got rid of reference-counting pain. Completely. Memory management is mediated by accessors, always. And accessors are generated. This technique is not safe for reentrant methods, whether due to multi-threading or on the same thread through (possibly indirect) recursion. An automatic (local) temporary variable is private to that stack frame, while an instance variable is shared across the object, which usually means across many stack frames. Something to keep in mind before adopting this. 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: 64-bit iOS
Scott, I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and there is no virtual memory. Until you exceed the 4 gig limit, I don't see why this matters. Abdul Sent from my iPhone On Sep 10, 2013, at 3:44 PM, Scott Ribe scott_r...@elevated-dev.commailto:scott_r...@elevated-dev.com wrote: Well, since nobody else has commented, let me be the first to say: YES! YES! YES! THANK YOU APPLE!! -- Scott Ribe scott_r...@elevated-dev.commailto:scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.commailto: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.comhttp://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.netmailto: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: 64-bit iOS
On Tue, 10 Sep 2013 20:01:36 +, Abdul Sowayan said: I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and there is no virtual memory. Until you exceed the 4 gig limit, I don't see why this matters. One thing that pops to mind: it makes portability to/from OS X a little bit easier, since (these days anyway) OS X is mostly 64 bit only. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: 64-bit iOS
On Sep 10, 2013, at 2:39 PM, Joseph Dixon s...@dixondata.com wrote: Some operations that would have taken 2 cycles may now be done in one. Some. Probably not many. Surely that leads to a performance boost, right? Maybe, maybe not. The flip side is that pointers are twice as large, so half as many fit in cache. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: 64-bit iOS
On 10 Sep 2013, at 22:48, Scott Ribe scott_r...@elevated-dev.com wrote: On Sep 10, 2013, at 2:39 PM, Joseph Dixon s...@dixondata.com wrote: Some operations that would have taken 2 cycles may now be done in one. Some. Probably not many. Surely that leads to a performance boost, right? Maybe, maybe not. The flip side is that pointers are twice as large, so half as many fit in cache. And off when you do need to hit RAM you need to fetch more data. Tom Davie ___ 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
Cocoaheads Tomorrow, Wed Sept. 11 at 7pm
CocoaHeads Lake Forest will be meeting on the second Wednesday of the month. We will be meeting at the Orange County Public Library (El Toro) community room, 24672 Raymond Way, Lake Forest, CA 92630 We will be talking about the recently announced iGoodies, and Peter will be talking about Travis (https://travis-ci.org/), a continuous integration system that integrates with GitHub. Works on Mac and iOS projects, among others. Depending on interest, I may discuss some of the new goodies in the Webkit Web Inspector Please join us from 7pm to 9pm on Wednesday Bring laptops, code, discussion topics, etc. As always, details can be found on the cocoaheads web site at www.cocoaheads.org ___ 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 vs Manual Reference Counting
Hi,
I think that's problem with it and a lot of other things too! Once you get out
of the habit of thinking about memory management, you forget how to do it! How
many people can do long multiplication or division on paper these days?? I
started to do it the other day and had to really think to remember the rules!
The thing that bothers me about ARC is that it is a one-way street source code
wise unless you put #ifdefs all over the place and then you invariably don't
test the other version adequately. I try to make my code as compatible as
possible, e.g for properties I still define a dealloc and set them to nil to
release them. retain and release calls (for locals are harder to do right for
both versions. If Apple had allowed the retain and release method calls as per
Non-ARC but for ARC did nothing. This would at least allow code to be compiled
for both versions.
For CF Objects I usually make them properties and then write getters and
setters to manually CFRetain and CFRelease them.
The really good thing about ARC is that it does away with Auto-Release which is
very good news IMO!
One thing that puzzles me is how ARC figures out how to handle something like
this?
-(NSArray*) someMethod:(NSArray*) someArray andSomeValue:(NSInteger) someValue
{
NSArray * myArray;
if (someValue = 37)
myArray = [[NSArray alloc] init];
else
myArray = someArray;
return myArray;
}
Cheers
Dave
On 9 Sep 2013, at 08:44, Kyle Sluder k...@ksluder.com wrote:
Thirded. I thought I wouldn't like it. As soon as I didn't have to manage
retains and releases of temporary objects, the discipline completely left my
mind. Now whenever I go back to non-ARC code I invariably make a ton of
memory management errors, most of which are caught by the analyzer.
--Kyle Sluder
On Sep 8, 2013, at 11:18 PM, Alex Kac a...@webis.net wrote:
Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d
find weird errors that would be caused by some over-released object. We cut
a ton of code with ARC, and in the end we saw reliability go up and actually
even some performance.
ARC is a win. The only place it really got a bit hairy was CF objects. I
wish ARC would work with them a bit more.
On September 8, 2013 at 11:56:10 PM, Jens Alfke (j...@mooseyard.com) wrote:
They’re a _lot_ easier. It might not look that way when you’re reading about
all the details, or converting existing code, because then you’re focusing
on the rare edge cases. But for the most part when actually coding you can
simply ignore ref-counting. Your code becomes more compact and readable, and
you’re less likely to make mistakes.
Alex Kac - President and Founder
Web Information Solutions, Inc.
___
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/kyle%40ksluder.com
This email sent to k...@ksluder.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/dave%40looktowindward.com
This email sent to d...@looktowindward.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 vs Manual Reference Counting
On 9 Sep 2013, at 09:49, Marcel Weiher marcel.wei...@gmail.com wrote:
The pattern I adopted long ago to avoid that sort of situation is to have an
instance variable for my temps, in which case the code becomes:
[self setTemp:newObject];
… do stuff …
[self setTemp:nil];
or if you prefer dot syntax:
self.temp = newObject;
… do stuff …
self.temp = nil;
Even if you forget nilling, you at most have an extended lifetime of an
object, not a leak. I also generally do the same in initialization code (but
not in dealloc). For me, that simply got rid of reference-counting pain.
Completely. Memory management is mediated by accessors, always. And
accessors are generated.
This is great except that you lose the type information for the Class in
question? A way around it might be to have one Instance Variable and a number
of properties of the Right Type, but you'd have to define these in an
@interface section which would be messy.
e.g.
@interface someClass ()
{
id mTempIVar;
}
@property (nonatomic,retain) NSArray* pTempArray;
@property (nonatomic,retain) NSNumber* pTempNumber;
@end
@implementation someClass
@synthesize pTempArray = mTempIVar;
@synthesize pTempNumber = mTempIVar;
You'd also have to watch out that you didn't reuse the same temp in your
methods.
I toyed with the idea of writing a LocalMemoryManager class:
+(id) allocLocalObjectOfClass:(Class) theClass forInstance:(id)
theCallingObject andMethod:(NSString*) theMethodName;
+(void) releaseLocalObjectsForClass:(Class) theClass andMethod:(NSString*)
theMethodName;
+(void) releaseAllLocalObjectsForClass:(Class) theClass;
You'd call it like this:
NSString* myString;
myString = [[LocalMemoryManager allocLocalObjectOfClass:[NSString Class]
forInstance:self andMethod:__FUNCTION__] initWithString@x];
Place a call to releaseLocalObjectsForClass at end of method to release all
local objects and in dealloc call releaseAllLocalObjectsForClass.
I just couldn't bear the thought of having to use a long wordy method call like
allocLocalObjectOfClass to allocate objects.
I am starting to think that this may explain the (vast) difference in
perception of ARC, at least it’s an explanation I can understand: if you
made the switch to always having reference counting mediated by accessors, RC
goes away as a pain point. If you haven’t, it’s probably a huge pain that
ARC removes.
Agreed I have my own way of handling local storage and use a different pattern,
which, sometimes involves the dreaded goto!
Cheers
Dave
___
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: 64-bit iOS
When you use the system call mmap(2) to map in a huge file you will find it useful. Sent from my iPhone On 2013年9月11日, at 4:01, Abdul Sowayan asowa...@vectorworks.net wrote: Scott, I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and there is no virtual memory. Until you exceed the 4 gig limit, I don't see why this matters. Abdul Sent from my iPhone On Sep 10, 2013, at 3:44 PM, Scott Ribe scott_r...@elevated-dev.commailto:scott_r...@elevated-dev.com wrote: Well, since nobody else has commented, let me be the first to say: YES! YES! YES! THANK YOU APPLE!! -- Scott Ribe scott_r...@elevated-dev.commailto:scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.commailto: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.comhttp://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.netmailto: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/xcvista%40me.com This email sent to xcvi...@me.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 vs Manual Reference Counting
On Sep 10, 2013, at 12:33 PM, Dave d...@looktowindward.com wrote: You with all this talk of memory management, you'd think that Apple (or someone) would have come up with a hardware solution for this by now. In the 70's and 80's I worked on some firmware and hardware that would handle garbage collection in real time (with a little help from OS Software). I’ve read through a lot of GC papers in the past, and I’m not sure what you’re talking about here, unless it’s something that allows extra tag bits to be stored in pointers. This was used a lot in old LISP systems; it can be useful with interpreted languages but I don’t think it’d be applicable to a C-based language. (A lot of the more sophisticated GC techniques simply don’t work with C-like code because it’s too low-level and makes too many assumptions about memory. For example, you can’t use compaction or copying collectors at all because objects can’t be relocated. The Obj-C garbage collector had to rely on inefficient conservative mark/sweep algorithms.) If Apple were to implement something like this I think there would be a massive increase in performance and reliability Nothing personal, but I think you’re falling into the common fallacy of thinking that Apple engineers are naive and/or ignorant. It happens all the time on these lists. In general, you should assume that the people working on system software are pretty damn smart and experienced, and are aware of all the techniques that an interested but non-expert outsider would know of. If they’re not using them, there’s probably a good reason for it. (This is a special case of the nearly universal engineer’s fallacy of dismissing any problem you haven’t personally worked on as trivial.) —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 vs Manual Reference Counting
On 9 Sep 2013, at 11:15, Kevin Meaney k...@yvs.eu.com wrote: On 9 Sep 2013, at 10:33, Tom Davie tom.da...@gmail.com wrote: Yes, it does. If you’d like an example to verify this behaviour with, play with converting https://github.com/beelsebob/CoreParse to ARC, and profiling the result. This is the example that showed 100% slowdown initially. The last time I tried this with with Xcode 4.5, and after I’d added a bunch of extra autorelease pools all over the place which reduced ARC’s overhead to “only 50%. This in itself suggests to me that ARC causes a significant increase in the number of autoreleased objects (which surprised me given the runtime optimisation to get rid of autorelease/retain pairs in callee/caller). One of the things that has changed in the code that I write, is that in manual retain/release I would often use the autorelease class methods for creating an object arrayWith... etc. and think about the placement of autorelease pools. Using ARC I almost never use these class methods for creating an object but instead use alloc init. I don't have a lot of temporary objects hanging around now. I never use autorelease if I can help it. I think this is the route cause of a lot of the problems and why ARC was introduced (apart from it being good anyway). I've seen so many projects written by engineers that didn't understand memory management and couldn't be bothered to learn it, so they used AU instead! Cheers Dave ___ 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: Crashing Problem calling postNotificationName
On Sep 10, 2013, at 4:08 AM, Dave d...@looktowindward.com wrote: I have a crashing problem when calling postNotificationName Most of the time this happens because an object registered as an observer of that notification has been dealloced. Try running with NSZombieEnabled and, if this is the case, you should get an exception identifying the deallocated object. Also, as others have pointed out, if you’re asking about a crash you should include some kind of details about it like the backtrace and any relevant logs. —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: 64-bit iOS
On Sep 10, 2013, at 10:03 PM, Maxthon Chan xcvi...@me.com wrote: When you use the system call mmap(2) to map in a huge file you will find it useful. Especially if you want to map more than one, unmap one, mmap another, and so on ;-) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: 64-bit iOS
On Sep 11, 2013, at 12:03 AM, Maxthon Chan wrote: When you use the system call mmap(2) to map in a huge file you will find it useful. How so? ___ 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: 64-bit iOS
When you map in a file, its contents will consume address space of your application. When the file is bigger than 3 GiB, since there is no more bits on the address lines, you will not be able to map the file in completely all in once. On Sep 11, 2013, at 12:37, Alex Zavatone z...@mac.com wrote: On Sep 11, 2013, at 12:03 AM, Maxthon Chan wrote: When you use the system call mmap(2) to map in a huge file you will find it useful. How so? ___ 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
NSWindowCloseButton and friends mouse over highlight
Hello all, So, working with a borderless window with a custom style, but wanting to have standard traffic light buttons, I am unable to figure out how to get the proper mouseover highlight state. I have created a generic container view class that can be told which kind of NSWindowButtonType to hold, and the container creates the button itself. The container is really for keeping things tidy and includes an NSTrackingArea to track the mouse entering and exiting the button rect. This all works really great. However, sending highlight:YES to the button or setHighlighted:YES to the button cell, both give the mouse down image of the traffic light buttons. Is there something I'm missing in the docs or documented in a header somewhere? Or is this just some stuff private to NSThemWidget ? Or, is there a way to have those standard window buttons actually behave in a borderless window the same way they behave everywhere else, without resorting to photoshopping some screenshots of the things? It's certainly possible to locate assets for these within tons of apps and borrow those as well, but surely this shouldn't be so hard, right? ___ 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
