On 03 Jun 2015, at 19:54, Alex Zavatone z...@mac.com wrote:
On Jun 3, 2015, at 2:30 PM, Mark Wright wrote:
The only potential problem is ivars that don’t have the leading underscore.
My project has 377 of them. All named the same as the property, if there is
a property to begin
That’s a ‘Class Extension’. Furthermore, it’s under the title Class
Extensions Extend the Internal Implementation”. It also mentions that it goes
in the @implementation block…
On 03 Jun 2015, at 15:11, Alex Zavatone z...@mac.com wrote:
Apple's Programming with Objective-C reference
out
of the class @interface and (if still needed) into the @implementation or class
extension. There’s a clang warning that can be enabled to help you if desired:
-Wobjc-interface-ivars
Le 3 juin 2015 à 17:15, Mark Wright blue.bucon...@virgin.net a écrit :
Sorry, yes, I misread
://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
On Jun 3, 2015, at 10:22 AM, Mark Wright wrote:
That’s a ‘Class Extension’. Furthermore, it’s under the title Class
Extensions Extend the Internal Implementation”. It also
On 03 Jun 2015, at 17:08, Alex Zavatone z...@mac.com wrote:
One point I haven't looked at is, if @properties are declared within the
@implementation or the class extension, are they private? And if so,
shouldn't they be preceded with an underscore and in that case, what does
that
On 03 Jun 2015, at 18:59, Uli Kusterer witness.of.teacht...@gmx.net wrote:
On 03 Jun 2015, at 19:09, Alex Zavatone z...@mac.com wrote:
On Jun 3, 2015, at 12:59 PM, Uli Kusterer wrote:
So you're not supposed to use the underscore convention even for your
private ivars, as Apple could add
I’m afraid I may not be too helpful here because in my case I’m not using an
NSTextView, rather mine is a custom view that displays text in various ‘cells’
so I had to implement the full textFinderClient protocol and build a corpus of
searchable text for it to query against.
On 14 Apr 2015,
FWIW it crashes on mine too (not too surprising, same Xcode and OS).
It doesn’t crash if you replace the crashing line with:
SKIndexAddDocumentWithText(searchIndexFile, doc, NULL, false);
I don’t know if that’s any use to you (never used the framework).
I think it’s failing because it’s
Shouldn't that be:
- (BOOL) wrapsLines {
return ![self isHorizontallyResizable];
}
Otherwise if you set it to YES the getter will return NO because of the [self
setHorizontallyResizable: !wraps] line in the setter?
On 16 Oct 2013, at 06:55, Jens Alfke wrote:
On Oct 12, 2013, at 2:42
Hi all,
Has anyone, anywhere, ever, gotten -slideDraggedImageTo: to actually work as
described in the docs or otherwise do anything at all?
The docs lay it out in black and white:
Slides the image to a specified location.
- (void)slideDraggedImageTo:(NSPoint)aPoint
Parameters
aPoint
A
However, as far as I recall, the scroll view is responsible for tiling
and drawing the table column headers (and the little corner view).
So, it's only a workable solution if you don't want headers over your
table columns...
On 21 Feb 2011, at 04:10:24, Scott Anguish wrote:
although
Ah HA!
This problem has bugged me for ages and I could never find it. I too
worked around it with re-saves or forcing nib recompilation whenever
one of them worked. I always blamed some obscure corruption in IB but
since I'm stuck on 10.5 I assumed it was just something to live with.
Your AudionetQueueDelegate protocol is probably not inheriting from
NSObject (the protocol) so it warns that valueForKeyPath: is not
found. It'll also probably complain about methods like
respondsToSelector: which is also part of the NSObject protocol.
You need to write your protocol
On 16 Nov 2010, at 11:27:22, Remco Poelstra wrote:
Op 16 nov 2010, om 12:18 heeft Mark Wright het volgende geschreven:
Your AudionetQueueDelegate protocol is probably not inheriting from
NSObject (the protocol) so it warns that valueForKeyPath: is not
found. It'll also probably complain
14 matches
Mail list logo
