On Jun 3, 2015, at 8:02 AM, Alex Zavatone z...@mac.com wrote:
On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote:
On Jun 1, 2015, at 11:43 PM, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
Although I have the luxury of requiring modern runtime capable systems,
some people
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 with. That's why I'm walking down this fun little road.
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
I based my code on one of Apple's examples and had tried using
NSBrowserCell but was not able to get that working; I assume there is
some reason why Apple chose to use NSTextFieldCell in their example and
I followed suit.
Currently, I have this coded - I had tried several variations to force
On 4 Jun 2015, at 10:20 am, Frank D. Engel, Jr. fde...@fjrhome.net wrote:
I am wondering if the browser is actually caching an image of the cells in
the second column when I switch away, then just displaying that without
actually recreating the cells in the second column until it needs
After all of this, I finally at least partially solved this one.
I added a line of code to run each time that method is called.
It wasn't being called most of the time. I found where I was calling
this and changed the code a bit to use a binding created by code, and
now it is almost working.
I have two questions I'm hoping I can get some advice on...
First the complicated one:
I have an NSTableView (cell-based) in which I am trying to rig two
columns with NSPopupButtonCell - the selection in the first one
determines the possible values of the second.
This is part of a
On 4 Jun 2015, at 7:29 am, Frank D. Engel, Jr. fde...@fjrhome.net wrote:
Now what I am hoping is the simpler one:
I have a custom subclass of NSTextFieldCell which I am using to show an icon
in an NSBrowser. The icon image is being generated dynamically by a method
in my subclass and
On Jun 3, 2015, at 11:30 AM, Mark Wright blue.bucon...@virgin.net wrote:
For what it’s worth, I’ve never had that problem either. Most of the time
self.whatever is used for property access, _whatever is used for ivar access
and that’s about it.
Yup. This is what I meant about properties
I’m fairly certain the warning is newer than the documentation.
On Jun 3, 2015, at 7:11 AM, Alex Zavatone z...@mac.com wrote:
Apple's Programming with Objective-C reference document © 2014
BTW; I get the error in both lines.
On Wed, Jun 3, 2015 at 11:35 AM, Juanjo Conti jjco...@carouselapps.com
wrote:
Same error with both names.
On Wed, Jun 3, 2015 at 11:31 AM, Scott Ribe scott_r...@elevated-dev.com
wrote:
On Jun 3, 2015, at 8:23 AM, Juanjo Conti jjco...@carouselapps.com
On Jun 3, 2015, at 9:02 AM, Alex Zavatone wrote:
On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote:
On Jun 1, 2015, at 11:43 PM, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
Variables declared in an @interface section trigger a compiler warning:
warning: declaration of
Apple's Programming with Objective-C reference document © 2014
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
Page 73
@interface XYZPerson () {
id _someCustomInstanceVariable;
}
...
@end
Uhh.
Doesn't
On Jun 3, 2015, at 8:23 AM, Juanjo Conti jjco...@carouselapps.com wrote:
Hi, I'm using WebView and I'd like to enable HTML5 local storage.
I've read some questions on Stack Overflow where the suggestion is to do:
WebPreferences *prefs = [webView preferences];
[prefs
Maybe I should have included the text above it.
It's also possible to use a class extension to add custom instance
variables. These are declared inside braces in the class extension interface.
So, I don't know how you see that it goes in the @implementation block since
the code I pasted and
Hi, I'm using WebView and I'd like to enable HTML5 local storage.
I've read some questions on Stack Overflow where the suggestion is to do:
WebPreferences *prefs = [webView preferences];
[prefs _setLocalStorageDatabasePath:@~/Library/Application
Support/MyApp];
[prefs
There are 3 ways to add ivars to a class. The traditional way:
@interface Foo {
id _bar;
}
And 2 new ways:
@interface Foo() { // Class extension, note the ()
id _baz;
}
@implementation Foo { // Implementation block.
id _faz;
}
On Jun 3, 2015, at 7:32 AM, Alex Zavatone
On 3 Jun 2015, at 22:23, Juanjo Conti jjco...@carouselapps.com wrote:
Hi, I'm using WebView and I'd like to enable HTML5 local storage.
I've read some questions on Stack Overflow where the suggestion is to do:
WebPreferences *prefs = [webView preferences];
[prefs
On Jun 3, 2015, at 6:30 AM, Alex Zavatone z...@mac.com wrote:
With that in mind, what should it have depended on instead?
His point was not that such dependence was bad, nor even avoidable. His point
was that the C++ was a steaming pile ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
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
Same error with both names.
On Wed, Jun 3, 2015 at 11:31 AM, Scott Ribe scott_r...@elevated-dev.com
wrote:
On Jun 3, 2015, at 8:23 AM, Juanjo Conti jjco...@carouselapps.com wrote:
Hi, I'm using WebView and I'd like to enable HTML5 local storage.
I've read some questions on Stack
On Jun 2, 2015, at 9:07 PM, Michael David Crawford wrote:
What horrified me was that they were completely unaware that their
product was likely to drop a pickup truck on top of an assembly plant
worker. While the overall architecture had all manner of
fault-tolerance engineered in, that
On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote:
On Jun 1, 2015, at 11:43 PM, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com 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
On Jun 3, 2015, at 10:41 AM, David Duncan wrote:
There are 3 ways to add ivars to a class. The traditional way:
@interface Foo {
id _bar;
}
And 2 new ways:
@interface Foo() { // Class extension, note the ()
id _baz;
}
Ahhh. Completely missed that. Haven't seen it
On Jun 3, 2015, at 11:15 AM, Mark Wright wrote:
Sorry, yes, I misread the initial paragraph that mentions the @implementation
block. I actually meant implementation *file* since that’s typically where
the class extension @interface is declared (it extends the class internally).
However,
On Jun 3, 2015, at 11:27 AM, Bernard Desgraupes wrote:
What about the @property declarations in the new scheme ?
Well, from what I've read, Apple wants you to use @properties over declaring
ivars. But… I don't know.
With auto-synthesis, you get ivars for free.
One point I haven't
On 03 Jun 2015, at 16:27, Bernard Desgraupes bdesgrau...@orange.fr wrote:
What about the @property declarations in the new scheme ?
I’m not sure what you’re asking, @properties are a big part of the 'new way'…
This is not about properties though, just about the notion of moving ivars
Sorry, yes, I misread the initial paragraph that mentions the @implementation
block. I actually meant implementation *file* since that’s typically where the
class extension @interface is declared (it extends the class internally).
However, as you’ve surmised, all this talk of clang warnings
What about the @property declarations in the new scheme ?
Le 3 juin 2015 à 17:15, Mark Wright blue.bucon...@virgin.net a écrit :
Sorry, yes, I misread the initial paragraph that mentions the @implementation
block. I actually meant implementation *file* since that’s typically where
the
On Jun 3, 2015, at 8:27 AM, Bernard Desgraupes bdesgrau...@orange.fr wrote:
What about the @property declarations in the new scheme ?
You can add @property declarations in any @interface block. Properties added in
a class extension will be automatically synthesized. Properties added via a
Here's what I found to be great places to start from within one of Apple's docs.
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
Essential reading
Page 16:
Page 43:
Page 73: Use Class Extensions to Hide Private
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:46, Mark Wright blue.bucon...@virgin.net wrote:
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
On Jun 3, 2015, at 12:46 PM, Mark Wright wrote:
This is important and is all about *scope*.
A class’s properties are only public if they’re in the header.
Exactly.
With that said, why do we not have a convention with properties declared within
the .m file for showing that they are private
My question was unclear. I was asking about _where_ they should be declared. I
guess they remain in the @interface.
Le 3 juin 2015 à 18:11, Mark+Vron mark.v...@virgin.net a écrit :
On 03 Jun 2015, at 16:27, Bernard Desgraupes bdesgrau...@orange.fr wrote:
What about the @property
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 secret stuff to NSObject or any other base class
you'd collide with.
-- Uli
So, how are we expected to tell the
On Jun 3, 2015, at 1:59 PM, Uli Kusterer 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 secret stuff to NSObject or
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
On 03 Jun 2015, at 19:06, Alex Zavatone z...@mac.com wrote:
On Jun 3, 2015, at 12:46 PM, Mark Wright wrote:
This is important and is all about *scope*.
A class’s properties are only public if they’re in the header.
Exactly.
With that said, why do we not have a convention with
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 secret stuff to NSObject or any other base
class you'd collide with.
--
40 matches
Mail list logo
