Re: Looking at self = [super init].

> On Jun 1, 2015, at 9:53 PM, Scott Ribe wrote: > > On Jun 1, 2015, at 10:43 PM, Britt Durbrow > wrote: >> >> So…. it looks like clang at least is doing the right thing and calling the >> destructor when the variable goes out of scope. > > Yep. But I believe with goto you can skip over a co

How to debug a binding exception?

Things are working mostly fine with my app, but I discover an exception if I close a document which has not been saved, and elect to discard the document: * thread #1: tid = 0x51dfe8, 0x7fff9393b743 libobjc.A.dylib`objc_exception_throw, queue = 'com.apple.main-thread', stop reason = break

Re: How to debug a binding exception?

On Jun 2, 2015, at 02:36 , John Brownie wrote: > > * thread #1: tid = 0x51dfe8, 0x7fff9393b743 > libobjc.A.dylib`objc_exception_throw, queue = 'com.apple.main-thread', stop > reason = breakpoint 1.1 Have you tried continuing after the exception? The next thing it should do is log the exce

Re: NSPathControl

I just looked at what’s in my pathControl - the objectValue and URL are both the same, the initial file://localhost/Applications/ that you see in the nib. Makes sense - if you’re letting the PathControl make the components it builds them from the URL, but it doesn’t change the URL if you change

Re: Looking at self = [super init].

On Jun 1, 2015, at 11:43 PM, Britt Durbrow wrote: > > Although I have the luxury of requiring modern runtime capable systems, some > people do still have to target the old runtime… ARC requires the modern runtime, which has pretty much caused the old one to drop off the map for most people, I

NSTreeController Question

Hi, I’m trying to clear all the Items from a Tree View apart from the Root Item. When my View gets initialized, it creates a Section called: “OBJECTS”, this is the Item that has the Show/Hide in Title. Then when I get a Notification, I add items to the Tree Controller, this works fine. The “

Re: Looking at self = [super init].

> On Jun 2, 2015, at 12:13 PM, Charles Srstka wrote: > > That can be handy, if you’re not colorblind. If you are, the coloring isn’t > much help. It depends on what the colors are. Almost no one is entirely colorblind; usually it’s just red and green that are problematic. But yes, you might

Re: Looking at self = [super init].

> On 2 Jun 2015, at 11:02, Jeremy Pereira > wrote: > > >> On 1 Jun 2015, at 19:11, Dave wrote: >> >> >> Exactly, so make it more readable, to me anyway, unnecessary braces just add >> to complexity or at least makes the method look more complex than it >> actually is. > > N! >

Re: Looking at self = [super init].

Jens, I don't see a setting in the Source Editor's Fonts and Colors that displays a difference between a class's properties and a class's ivars. When you apply a color change or a font change there is no visual differentiation between those two. Honestly, I would love to see the properties on o

Re: Looking at self = [super init].

> On Jun 2, 2015, at 2:41 PM, Jens Alfke wrote: > >> On Jun 2, 2015, at 12:13 PM, Charles Srstka > > wrote: >> >> That can be handy, if you’re not colorblind. If you are, the coloring isn’t >> much help. > > > It depends on what the colors are. Almost no one i

Extending or replacing standard font panel?

Does anyone know whether it’s possible to extend or override the standard Mac font panel (NSFontPanel) across all apps? I’m guessing the answer is “not without nasty hacks that involve injecting code into all processes”, i.e. the sort of thing that DefaultFolder and other open/save panel utilit

Re: Looking at self = [super init].

> On Jun 2, 2015, at 1:28 PM, Charles Srstka wrote: > > Dogs don’t completely lack color vision. Also, calling a person a dog could > really come across in a way that you’re not intending. Sorry, not intended! I was thinking more of “On cocoa-dev, no one knows you’re a dog”. > Anyway, yes, o

Re: Looking at self = [super init].

> On Jun 2, 2015, at 3:31 PM, Jens Alfke wrote: > >> Anyway, yes, one could ugly up one’s code with italics and boldface and >> whatnot, but simply prefixing the ivar name with an underscore is simpler, >> it prevents accidentally referencing the ivar and/or shadowing it with a >> local variab

Re: Looking at self = [super init].

On Tue, Jun 2, 2015, at 03:42 PM, Charles Srstka wrote: > > On Jun 2, 2015, at 3:31 PM, Jens Alfke wrote: > > > > I agree, actually. But in Swift the concept of ivar no longer exists, so I > > have to rely on color/style to distinguish properties from locals. > > My solution with Swift is to co

Re: How to debug a binding exception?

___ 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.co

Re: Looking at self = [super init].

After I pointed out my diligent use of comments to Scott Lydiard, President of aerial photography firm Verde Technologies, he advised me not comment my code in any way. WUT? "That's because comments are rarely maintained in sync with the actual source code." For example: int offset( void ) {

Re: Looking at self = [super init].

> On 3 Jun 2015, at 9:03 am, Michael David Crawford > wrote: > > "That's because comments are rarely maintained in sync with the actual > source code." > So part of the responsibility of coding well is to maintain comments, not to remove them altogether. At a minimum, I comment what a meth

Another bindings question

The exception I was getting was from a binding established in IB, which is a bit of a worry, but it prompts me to ask whether I'm pursuing the right road. What I have is an NSTableView (still cell-based, moving to view-based is further down the track), and then a bunch of buttons that need to

Re: Looking at self = [super init].

I once worked for a company that had quite meticulous style rules regarding comments. I was also required to use a specific text editor because someone had written scripts that either enabled or enforced the comment style rules. I resigned in protest because their actual source code is quite like

Re: Another bindings question

On Jun 2, 2015, at 17:18 , John Brownie wrote: > > What I have is an NSTableView (still cell-based, moving to view-based is > further down the track), and then a bunch of buttons that need to be enabled > only when there is a selection in the table. Binding to the selection > property of the a

Re: Looking at self = [super init].

> On 3 Jun 2015, at 10:19 am, Michael David Crawford > wrote: > > If their coding conventions are > the sort that are likely to lead to correct code The reason for coding style guidelines is a) correctness b) maintainability. If it’s just a fetish that the chief developer has and he can’t ba

Re: Another bindings question

___ 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.co

Re: Looking at self = [super init].

While there were numerous reasons for my protest resignation, the reason I walked out - no notice given - was that I was the only one in the company who was aware that there even was such a thing as a C++ Smart Pointer. I knew something was up when I was told to stop referring to the computer prog

Re: Looking at self = [super init].

> On Jun 2, 2015, at 12:13 PM, Charles Srstka wrote: > > > Variables declared in an @interface section trigger a compiler warning: > > warning: declaration of instance variables in the interface is deprecated > [-Wobjc-interface-ivars] Hmm… I’ve never seen that warning actually be emitted by