On 17 Mar 2012, at 05:56, Prime Coderama wrote:
Shouldn't the the SMJobBless example be used? Although I am still struggling
to get this to work - even have an open Apple support issue.
I just build SMJobBless. Didn't work.
Then I changed Joe Developer with some iPhone Provisioning
On 17.03.12 02:21, Raleigh Ledet wrote:
The System doesn't know if momentum scroll events will follow
normal scroll event phrase or not. There is no way for the underlying
driver to inform the system of this. Sorry. I have to deal with this
problem inside appkit as well. It gets even more
On Mar 16, 2012, at 9:16 PM, G S wrote:
Thanks for asking this, Brian. I've wondered the same thing, and in fact I
went through my code and removed almost all property declarations from my
view controllers. Since most properties are declared as retain, you're
just increasing your
just use isViewLoaded, it's a property of the UIViewController, don't need
to track it yourself.
BAH! I looked for this sort of thing under the properties of
UIViewController, not methods. Thanks.
___
Cocoa-dev mailing list
This pattern is pretty questionable though in terms of OO — you have one
class (NSNib, UINib, etc.) directly setting instance variables in another
class (your view controller) and using runtime functions to hack around
things like @private.
How do you figure? I'm not doing any manipulation
On Mar 17, 2012, at 3:45 AM, G S wrote:
This pattern is pretty questionable though in terms of OO — you have one
class (NSNib, UINib, etc.) directly setting instance variables in another
class (your view controller) and using runtime functions to hack around
things like @private.
How do
G
On 16 mar ibi, at 14:57, cocoa-dev-requ...@lists.apple.com wrote:
Send Cocoa-dev mailing list submissions to
cocoa-dev@lists.apple.com
To subscribe or unsubscribe via the World Wide Web, visit
Speer
ubInbhttpsuu://lists.al/viburnum-dev
or, via email, send a message with subject or
How do you think that (NS)|(UI)Nib — an unrelated class that shouldn’t
have access to your private ivars — sets the outlet variables to your nib
objects? It does it via runtime hackery. If you declare a property, on the
other hand, it just calls the setter. Much cleaner and more OO, if you
I am a registered developer. And I paid 80€ to get the permission to mess
around with my iPhone for one year.
I am NOT interested in the Mac app Store, and I do NOT want to pay another 80€.
But I want to codesign my OS X apps.
So how do I get the necessary certificate?
Kind regards,
Gerriet.
On 2012-03-17, at 9:18 AM, Gerriet M. Denkmann wrote:
But I want to codesign my OS X apps.
So how do I get the necessary certificate?
You need to buy it from a certificate authority, like Thawte or Verisign (or
one of the myriad resellers) and they will all be happy to sell you one at
prices
But I want to codesign my OS X apps.
So how do I get the necessary certificate?
You need to buy it from a certificate authority, like Thawte or Verisign (or
one of the myriad resellers) and they will all be happy to sell you one at
prices that range from around $80 to around $500/yr.
Can
Can you not just use a free provider, like http://www.startssl.com/?
I'm not an expert, but I think the free cert they provide cannot be used for
code signing.
One other alternative may be the Developer ID initiative that Apple has
announced as part of OS X 10.8 Mountain Lion, but I can't
On 17/03/2012, at 7:54 AM, Marco Tabini wrote:
Can you not just use a free provider, like http://www.startssl.com/?
I'm not an expert, but I think the free cert they provide cannot be used for
code signing.
FWIW they can; they'd be pretty useless otherwise. Many of them are marked,
One other alternative may be the Developer ID initiative that Apple has
announced as part of OS X 10.8 Mountain Lion, but I can't figure out if
that's still under NDA and don't want to incur the wrath of the mods :-)
I assumed thats what the original poster was referring to. I'm also
On 17 Mar 2012, at 22:41, Roland King wrote:
One other alternative may be the Developer ID initiative that Apple has
announced as part of OS X 10.8 Mountain Lion, but I can't figure out if
that's still under NDA and don't want to incur the wrath of the mods :-)
I assumed thats what the
So it seems that new technologies require code signing. Makes sense. But:
where and how do I get a free certificate?
Not sure you can yet.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or
On Mar 17, 2012, at 11:14 AM, Gerriet M. Denkmann wrote:
The problem: The documentation about SMJobBless says: The calling
application and target executable tool must both be signed.
So it seems that new technologies require code signing. Makes sense. But:
where and how do I get a free
On Mar 17, 2012, at 6:47 AM, G S wrote:
That kind of behind-the-scenes stuff really doesn't worry me too much, since
there are all kinds of hacky, non-OO things taking place in this language.
I'm not denigrating you for trying to avoid as much of it as possible, but it
seems like there's
On Mar 17, 2012, at 9:54 AM, Marco Tabini wrote:
'm not an expert, but I think the free cert they provide cannot be used for
code signing.
It can’t. Only Apple’s certs will work with Gatekeeper.
One other alternative may be the Developer ID initiative that Apple has
announced as part of
I've got a popover controller which loads one of several subviews ('panels'
below) as it's content. I have properties on the controller which expose the
current panel's height and width. The popover resizes correctly but fails to
place the panel correctly. If the replaceSubview:with: is
On 17 Mar 2012, at 2:48 PM, Erik Stainsby wrote:
I've got a popover controller which loads one of several subviews ('panels'
below) as it's content. I have properties on the controller which expose the
current panel's height and width. The popover resizes correctly but fails to
place the
Hi Fritz,
The popover controller is a standard NSViewController which is also acting as
the delegate for the popovers.
I guess I ought to have included the header as well before:
#import Cocoa/Cocoa.h
@interface RSPanelPopoverController : NSViewController NSPopoverDelegate
@property (weak)
I have a member variable to hold an NSDate:
NSDate* _firstBadAccuracyTime;
At some point, something happens and I set this value to now:
_firstBadAccuracyTime = [NSDate date];
On my next trip through this function, I calculate how long it has been
since I set this date:
NSDate*
Yes, [NSDate date] returns an autoreleased object. So you need to retain it if
you want to use it later. Once you are done with it, you should release it. See:
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html#//apple_ref/doc/uid/2994-SW6
On 2012-03-17, at 6:57 PM, Dave Fernandes wrote:
Yes, [NSDate date] returns an autoreleased object. So you need to retain it
if you want to use it later. Once you are done with it, you should release
it. See:
If a Cocoa method name doesn't begin with “alloc”, “new”, “copy”, or
“mutableCopy”, then the returned object is autoreleased.
Thanks, Dave. That's what I thought. But I don't understand why I need to
retain it then; it's assigned to a member pointer. Why does it get
released, and when? If
On Mar 17, 2012, at 6:10 PM, G S wrote:
Thanks, Dave. That's what I thought. But I don't understand why I need to
retain it then; it's assigned to a member pointer. Why does it get
released, and when?
Assigning something to an instance variable doesn’t cause it to get retained
unless
On Mar 17, 2012, at 6:10 PM, G S wrote:
I create another NSDate, on the stack, to hold now for use within that
function. Do I need to retain that too?
Er, sorry, I didn’t read this thoroughly last time. No, if you’re just using it
inside a method, and not storing it to an instance variable,
On 2012-03-17, at 7:10 PM, G S wrote:
If a Cocoa method name doesn't begin with “alloc”, “new”, “copy”, or
“mutableCopy”, then the returned object is autoreleased.
Thanks, Dave. That's what I thought. But I don't understand why I need to
retain it then; it's assigned to a member
First, read the memory management link posted by Dave.
G S mailto:stokest...@gmail.com wrote (Saturday, March 17,
2012 4:10 PM -0700):
Thanks, Dave. That's what I thought. But I don't understand why I need to
retain it then;
In general, you have to retain an object whenever you plan to
I create another NSDate, on the stack, to hold now for use within that
function. Do I need to retain that too?
Yes.
Not really, no. You could, it wouldn't be incorrect to retain it at the point
of creation (or use alloc/init) and then release it at the end of the function,
but it's not
I create another NSDate, on the stack, to hold now for use within that
function. Do I need to retain that too?
Yes.
Hm, Apple's doc says:
Cocoa’s ownership policy specifies that received objects should typically
remain valid throughout the scope of the calling method.
This leads me to
I did read the memory-management docs a long time ago, and I've run my app
through both Leaks and the analyzer. I avoid using properties because I
carefully manage my allocations.
I think the hole in my knowledge was limited to autorelease. I never use
autorelease in my code, so my exposure to
BTW, thanks for all the answers. I appreciate it!
Gavin
___
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
Hmm - with respect - autorelease is an implementation detail. Nothing says that
objects created through the convenience constructors like [ NSDate date ] have
to be autoreleased, they just have to be valid for long enough to be useful,
they could be held in a cache and cleaned out by little
On Sat, Mar 17, 2012 at 4:55 PM, Roland King r...@rols.org wrote:
Hmm - with respect - autorelease is an implementation detail. Nothing says
that objects created through the convenience constructors like [ NSDate
date ] have to be autoreleased, they just have to be valid for long enough
to be
I would've converted my project to ARC had time permitted. I will say that
this new understanding does make me reconsider my opinion on the merits of
properties (meaning I think they have more merit than I used to).
Would it be a waste of time to go through and add properties for my
I believe you were also on the discussion of properties vs. direct ivar access.
This ties into that discussion. If you declare/define a property with:
@property (nonatomic, retain) NSDate* firstBadAccuracyTime;
and
@synthesize firstBadAccuracyTime=_firstBadAccuracyTime;
then the runtime will
On Sat, Mar 17, 2012 at 5:19 PM, Eeyore eey...@monsterworks.com wrote:
I believe you were also on the discussion of properties vs. direct ivar
access. This ties into that discussion.
Yep. That's why I mentioned that I see new merit to properties.
You would still need to release the object
On Mar 17, 2012, at 6:12 PM, Roland King wrote:
So often I find I start with
@synthesize foo=_foo;
and by the time I get to the end of the project I've written custom foo: and
setFoo: methods which do something else too.
I have also done that but I recently read a blog where the
On Mar 17, 2012, at 6:10 PM, Richard Somers wrote:
On Mar 17, 2012, at 6:12 PM, Roland King wrote:
So often I find I start with
@synthesize foo=_foo;
and by the time I get to the end of the project I've written custom foo: and
setFoo: methods which do something else too.
I have
On Mar 18, 2012, at 9:10 AM, Richard Somers wrote:
On Mar 17, 2012, at 6:12 PM, Roland King wrote:
So often I find I start with
@synthesize foo=_foo;
and by the time I get to the end of the project I've written custom foo: and
setFoo: methods which do something else too.
I have
On Mar 17, 2012, at 5:05 PM, G S wrote:
I would've converted my project to ARC had time permitted. I will say that
this new understanding does make me reconsider my opinion on the merits of
properties (meaning I think they have more merit than I used to).
Would it be a waste of time to go
On Mar 18, 2012, at 9:53 AM, Greg Parker wrote:
If you have the Xcode 4.4 developer prerelease, the new synthesize-by-default
feature may be close to what you want.
--
Greg Parker gpar...@apple.com Runtime Wrangler
I do, and am just downloading DP2 as well. There is some
On Mar 17, 2012, at 6:59 PM, Roland King wrote:
I do, and am just downloading DP2 as well. There is some COOL stuff in there
which of course I won't talk about (but please bring it to iOS soon). The
auto-synthesize is super useful, wouldn't however save me from my own
stupidity in the case
On Mar 17, 2012, at 18:59 , Roland King wrote:
I will just need to be more diligent checking ivars against the properties
they support to ensure they match
Clang *was* checking this, at least in Xcode 4.2.
We had a thread a couple of months ago discussing this, in a case where the
check
On Mar 17, 2012, at 7:35 PM, Quincey Morris wrote:
The justification given for leaving them on @property was that the
complication of attributes on @synthesize seemed undesirable, and that
@synthesize is headed the way of the dodo anyway.
The memory management behavior of a property
The SMJobBless example code has a ReadMe.txt file that explains how to make a
self-signed certificate, and how to set up the project to use it. It worked
correctly when I tried it.
https://developer.apple.com/library/mac/#samplecode/SMJobBless/Listings/ReadMe_txt.html
You can get a
On Mar 17, 2012, at 9:35 PM, Quincey Morris wrote:
Also, note that 'weak' and 'strong' etc really shouldn't be on @property
either, since they only affect the way the ivar is handled. The property
itself is neither weak nor strong.
This doesn't seem right. It's an important part of the
On Mar 17, 2012, at 7:19 PM, Eeyore wrote:
I believe you were also on the discussion of properties vs. direct ivar
access. This ties into that discussion. If you declare/define a property with:
@property (nonatomic, retain) NSDate* firstBadAccuracyTime;
If you are using ARC, the property
On Mar 17, 2012, at 7:05 PM, G S wrote:
On Sat, Mar 17, 2012 at 4:55 PM, Roland King r...@rols.org wrote:
Hmm - with respect - autorelease is an implementation detail. Nothing says
that objects created through the convenience constructors like [ NSDate
date ] have to be autoreleased, they
On Mar 18, 2012, at 10:35 AM, Quincey Morris wrote:
On Mar 17, 2012, at 18:59 , Roland King wrote:
I will just need to be more diligent checking ivars against the properties
they support to ensure they match
Clang *was* checking this, at least in Xcode 4.2.
We had a thread a couple
On Mar 17, 2012, at 20:03 , Ken Thomases wrote:
It's an important part of the semantics of a property whether it holds a
strong or weak reference.
On Mar 17, 2012, at 20:04 , Greg Parker wrote:
The memory management behavior of a property frequently is part of the public
interface. For
On Mar 17, 2012, at 20:50 , Roland King wrote:
Did it really?
No, I didn't notice your sample code was the *good* code. :)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Just curious for the reasoning as to why some of the API calls like
[NSDictionary valueForKey:] take an NSString* and not a *const* NSString* ?
I guess NSStrings are immutable and maybe most runtime built strings are
more commonly not const ... but is everyone simply casting these guys at
API
On Mar 17, 2012, at 10:12 PM, Luther Baker wrote:
Just curious for the reasoning as to why some of the API calls like
[NSDictionary valueForKey:] take an NSString* and not a *const* NSString* ?
‘const’ doesn’t mean anything when applied to Objective-C object pointers.
Unlike C++, the
56 matches
Mail list logo
