exception in init
Hi,
I think the question was asked and answered but I cannot see a clearance
what is the right way to write init in the cases the arguments are nil or
wrong?
Returning a nil or raising an exception?
- (id) initWithURL: (NSURL *) url {
if ((self = [super init])) {
if (!url) {
// ?
}
if (![url isFileURL]) {
// ?
}
}
return self;
}
I can frequently see the following in init
NSAssert(url, @"url may not be nil", );
--
best regards
Ariel
___
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: exception in init
On Apr 4, 2012, at 1:38 PM, Ariel Feinerman wrote:
> Hi,
>
> I think the question was asked and answered but I cannot see a clearance
> what is the right way to write init in the cases the arguments are nil or
> wrong?
> Returning a nil or raising an exception?
Well first, this is my personal opinion how to deal with this, but others may
think differently:
Assuming we don't know anything about a client who invokes the init method -
which is often a reasonable assumption, then I think, you have not much options:
In a "debug" version, use NSAssert and friends (ensure Preprocessor macro
"NS_BLOCK_ASSERTIONS" is not defined). Use Unit tests in order to detect *any*
possible logic error. In a "release" version where NSAsserts and friends may
become no ops, this may possibly ensure that no invalid parameters will be ever
passed to the method.
However, if you cannot guarantee that - or if you find this assumption too
hairy - the best you probably can do is:
if (url == nil) {
NSLog(@"FATAL ERROR: invalid parameter in initWithURL:");
abort();
}
This may sound harsh, but otherwise, we don't know how a client would deal with
a nil result. If your init methods is well documented, and the client would
pass invalid parameters anyway, it is very likely that the client is NOT
properly prepared to deal with unexpected results. Likely, it doesn't know that
the parameter is invalid - because of another bug.
So, we can almost be certain, that a client would not expect anything to fail
in this regard. So, subsequently possibly really bad things may happen.
Don't throw an exception, this only obfuscates the error, and may cause even
more harm. Cocoa is not exception safe, which means that after an exception has
been thrown, the program is likely in a corrupt state.
And on Mac OS X - as opposed on iOS - an exception is not properly (IMHO)
handled anyway: the event hander just logs a message and then happily continues
to handle events, guaranteeing for high chances that more bad things will
happen.
Regards
Andreas
>
> - (id) initWithURL: (NSURL *) url {
>
>
> if ((self = [super init])) {
>
> if (!url) {
>
> // ?
>
> }
>
> if (![url isFileURL]) {
>
> // ?
>
> }
>
> }
>
> return self;
>
> }
>
> I can frequently see the following in init
>
> NSAssert(url, @"url may not be nil", );
>
> --
> best regards
> Ariel
> ___
>
> 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/agrosam%40onlinehome.de
>
> This email sent to agro...@onlinehome.de
___
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: exception in init
On Apr 4, 2012, at 4:38 AM, Ariel Feinerman wrote: > I think the question was asked and answered but I cannot see a clearance > what is the right way to write init in the cases the arguments are nil or > wrong? > Returning a nil or raising an exception? If the argument values are literally wrong — if it's illegal to pass those values — then you raise an exception. The idea is that this must represent a bug in the program, so you abort what's going on to keep it from going any further. If the situation could occur in a valid program, but should not create a new object, then you can release self and return nil. In this case it's often good to return an NSError or other error information to the caller, i.e. as an 'out' parameter. —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: exception in init
On Apr 4, 2012, at 8:37 AM, Andreas Grosam wrote:
> In a "debug" version, use NSAssert and friends (ensure Preprocessor macro
> "NS_BLOCK_ASSERTIONS" is not defined). Use Unit tests in order to detect
> *any* possible logic error. In a "release" version where NSAsserts and
> friends may become no ops, this may possibly ensure that no invalid
> parameters will be ever passed to the method.
I don't think NS_BLOCK_ASSERTIONS is normally set for you in a Release build.
Of course you can change the project settings to do so, but I don't know how
common that is — Apple generally ships its apps and frameworks with assertions
enabled, and I've never turned them off in anything I've written.
> However, if you cannot guarantee that - or if you find this assumption too
> hairy - the best you probably can do is:
>
> if (url == nil) {
>NSLog(@"FATAL ERROR: invalid parameter in initWithURL:");
>abort();
> }
I disagree.
First, if the developer is turning off assertions, it's because s/he doesn't
want the overhead (in code size and runtime) of these kinds of checks. So
except in very unusual circumstances you should honor that and not force your
check to happen anyway.
Second, calling abort() is way too harsh. Call +[NSException raise:] instead.
That way the caller has some chance of handling it, and Lion can put up it's
nifty an-exception-occurred alert, and the app doesn't just go "poof" in front
of the user.
—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: exception in init
Le 4 avr. 2012 à 17:57, Jens Alfke a écrit :
>
> On Apr 4, 2012, at 8:37 AM, Andreas Grosam wrote:
>
>> In a "debug" version, use NSAssert and friends (ensure Preprocessor macro
>> "NS_BLOCK_ASSERTIONS" is not defined). Use Unit tests in order to detect
>> *any* possible logic error. In a "release" version where NSAsserts and
>> friends may become no ops, this may possibly ensure that no invalid
>> parameters will be ever passed to the method.
>
> I don't think NS_BLOCK_ASSERTIONS is normally set for you in a Release build.
> Of course you can change the project settings to do so, but I don't know how
> common that is — Apple generally ships its apps and frameworks with
> assertions enabled, and I've never turned them off in anything I've written.
>
>> However, if you cannot guarantee that - or if you find this assumption too
>> hairy - the best you probably can do is:
>>
>> if (url == nil) {
>> NSLog(@"FATAL ERROR: invalid parameter in initWithURL:");
>> abort();
>> }
>
> I disagree.
> First, if the developer is turning off assertions, it's because s/he doesn't
> want the overhead (in code size and runtime) of these kinds of checks. So
> except in very unusual circumstances you should honor that and not force your
> check to happen anyway.
> Second, calling abort() is way too harsh. Call +[NSException raise:] instead.
>
> —Jens
While +[NSException raise:] is a convenient method, it is not annotated as
'noreturn' and so don't let the compiler/analyzer know about the control flow.
Using @throw does not have such issue and may prevent unexpected warnings (for
example about uninitialized variable or about missing return statement).
-- 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: exception in init
The general rule is:
1. If it is considered a programming error, raise an exception (or assert -- it
is the same)
2. If it is normal code flow, then don't log or do anything strange.
However, in general, it is troublesome to have init's return nil.
corbin
On Apr 4, 2012, at 4:38 AM, Ariel Feinerman wrote:
> Hi,
>
> I think the question was asked and answered but I cannot see a clearance
> what is the right way to write init in the cases the arguments are nil or
> wrong?
> Returning a nil or raising an exception?
>
> - (id) initWithURL: (NSURL *) url {
>
>
> if ((self = [super init])) {
>
> if (!url) {
>
> // ?
>
> }
>
> if (![url isFileURL]) {
>
> // ?
>
> }
>
> }
>
> return self;
>
> }
>
> I can frequently see the following in init
>
> NSAssert(url, @"url may not be nil", );
>
> --
> best regards
> Ariel
> ___
>
> 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/corbind%40apple.com
>
> This email sent to corb...@apple.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: exception in init
On Apr 4, 2012, at 5:57 PM, Jens Alfke wrote:
>
> On Apr 4, 2012, at 8:37 AM, Andreas Grosam wrote:
>
>> In a "debug" version, use NSAssert and friends (ensure Preprocessor macro
>> "NS_BLOCK_ASSERTIONS" is not defined). Use Unit tests in order to detect
>> *any* possible logic error. In a "release" version where NSAsserts and
>> friends may become no ops, this may possibly ensure that no invalid
>> parameters will be ever passed to the method.
>
> I don't think NS_BLOCK_ASSERTIONS is normally set for you in a Release build.
> Of course you can change the project settings to do so, but I don't know how
> common that is — Apple generally ships its apps and frameworks with
> assertions enabled, and I've never turned them off in anything I've written.
>
>> However, if you cannot guarantee that - or if you find this assumption too
>> hairy - the best you probably can do is:
>>
>> if (url == nil) {
>>NSLog(@"FATAL ERROR: invalid parameter in initWithURL:");
>>abort();
>> }
>
> I disagree.
> First, if the developer is turning off assertions, it's because s/he doesn't
> want the overhead (in code size and runtime) of these kinds of checks. So
> except in very unusual circumstances you should honor that and not force your
> check to happen anyway.
The macro NS_BLOCK_ASSERTIONS is strictly set per translation unit. If it is
set as "Preprocessor Macro" in the build setting, it will be set for all
translation units of the target. If this is a library or framework where the
init method resides, then it would have been set in the library or framework
build setting by the *library developer* and she might have good reason for
doing so or not.
That is, whether this macro is defined or not is a decision of the library
developer. The client can not change this, nor does the library developer know
whether the macro is set in the client code.
>
> Second, calling abort() is way too harsh. Call +[NSException raise:] instead.
> That way the caller has some chance of handling it, and Lion can put up it's
> nifty an-exception-occurred alert, and the app doesn't just go "poof" in
> front of the user.
The problem on Mac OS X in Cocoa Apps is, that there is no alert. The
application also does not stop, or terminate gracefully. The default behavior
of the event loop is to log an error message, and then **continue**.
Note, this is the default behavior. If you want to handle exceptions and
possibly terminate the app, AFAIK it requires a very elaborated procedure,
unless someone proves me wrong, and shows a simple code snippet how to
terminate gracefully after encountering an exception.
On the other hand, returning nil in an init method can cause other issues
(subclass instances may receive a dealloc message, yet its ivars are not yet
initialized). This has been discussed recently - in the Objective-C list, if I
remember correctly.
Regards
Andreas
___
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: exception in init
On Apr 4, 2012, at 9:29 AM, Andreas Grosam wrote: > The problem on Mac OS X in Cocoa Apps is, that there is no alert. The > application also does not stop, or terminate gracefully. The default behavior > of the event loop is to log an error message, and then **continue**. Not anymore. In Lion you get a very nice "Internal error / An uncaught exception was raised..." alert, with buttons "Show Details", "Crash", "Continue". I think it's important to give the user the option to continue, even if the app may be unstable. The user might have some critical unsaved data (assuming this isn't an app that autosaves.) > Note, this is the default behavior. If you want to handle exceptions and > possibly terminate the app, AFAIK it requires a very elaborated procedure, > unless someone proves me wrong, and shows a simple code snippet how to > terminate gracefully after encountering an exception. https://github.com/snej/MYUtilities/blob/master/ExceptionUtils.h Make your app's main class be MYExceptionReportingApp instead of NSApplication, and exceptions will be reported with an alert. I haven't tested this functionality recently so I don't know if it still works in Lion, and anyway you might want to add code to no-op it in that case so the nice Apple alert shows up instead. —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: exception in init
On Apr 4, 2012, at 9:55 AM, Jens Alfke wrote: > > On Apr 4, 2012, at 9:29 AM, Andreas Grosam wrote: > >> The problem on Mac OS X in Cocoa Apps is, that there is no alert. The >> application also does not stop, or terminate gracefully. The default >> behavior of the event loop is to log an error message, and then **continue**. > > Not anymore. In Lion you get a very nice "Internal error / An uncaught > exception was raised..." alert, with buttons "Show Details", "Crash", > "Continue". > > I think it's important to give the user the option to continue, even if the > app may be unstable. The user might have some critical unsaved data (assuming > this isn't an app that autosaves.) > >> Note, this is the default behavior. If you want to handle exceptions and >> possibly terminate the app, AFAIK it requires a very elaborated procedure, >> unless someone proves me wrong, and shows a simple code snippet how to >> terminate gracefully after encountering an exception. > > https://github.com/snej/MYUtilities/blob/master/ExceptionUtils.h > > Make your app's main class be MYExceptionReportingApp instead of > NSApplication, and exceptions will be reported with an alert. I haven't > tested this functionality recently so I don't know if it still works in Lion, > and anyway you might want to add code to no-op it in that case so the nice > Apple alert shows up instead. In Lion+, I recommend using the default AppKit behavior. (see my reply to Andreas) corbin ___ 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: exception in init
On Apr 4, 2012, at 9:29 AM, Andreas Grosam wrote: > The problem on Mac OS X in Cocoa Apps is, that there is no alert. The > application also does not stop, or terminate gracefully. The default behavior > of the event loop is to log an error message, and then **continue**. No, there is an alert! you just have to turn it on. From: https://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKit.html "AppKit now has the ability to report uncaught exceptions. It is controlled by a user default: NSApplicationShowExceptions (YES/NO). The default shipping value is NO. In general, it is recommend that developers set it to YES during development to catch programming errors. Individual applications can automatically turn this on by using [[NSUserDefaults standardUserDefaults] registerDefaults: ...] to register the option on. It can be set with defaults via: 'defaults write com.yourdomain.app NSApplicationShowExceptions YES'. It can also globally be turned on by writing to the global domain." --corbin ___ 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: exception in init
Hi,
If it's a real error, this is what I do:
- (id) initWithURL: (NSURL *) url
{
self = [super init];
if (self == nil)
return nil;
if (url == nil)
{
[self release];
return nil;
}
return self;
}
or in this case, you could just do this:
- (id) initWithURL: (NSURL *) url
{
if (url == nil)
return nil;
self = [super init];
if (self == nil)
return nil;
return self;
}
The caller should check for a nil value returned from the init method.
If it's a programming error, e.g. it should never happen, then it's
probably best to log the error and abort the App.
Hope this helps.
All the Best
Dave
On 4 Apr 2012, at 12:38, Ariel Feinerman wrote:
Hi,
I think the question was asked and answered but I cannot see a
clearance
what is the right way to write init in the cases the arguments are
nil or
wrong?
Returning a nil or raising an exception?
- (id) initWithURL: (NSURL *) url {
if ((self = [super init])) {
if (!url) {
// ?
}
if (![url isFileURL]) {
// ?
}
}
return self;
}
I can frequently see the following in init
NSAssert(url, @"url may not be nil", );
--
best regards
Ariel
___
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: exception in init
On Apr 4, 2012, at 10:33 AM, Corbin Dunn wrote: > "AppKit now has the ability to report uncaught exceptions. It is controlled > by a user default: NSApplicationShowExceptions (YES/NO). The default shipping > value is NO. In general, it is recommend that developers set it to YES during > development to catch programming errors. Individual applications can > automatically turn this on by using [[NSUserDefaults standardUserDefaults] > registerDefaults: ...] to register the option on. It can be set with defaults > via: 'defaults write com.yourdomain.app NSApplicationShowExceptions YES'. It > can also globally be turned on by writing to the global domain." Ah! Now I remember that a few months ago I got a hot tip to set this default globally, to make apps easier to troubleshoot. defaults write -g NSApplicationShowExceptions YES That explains why it works for me. This seems like something that would be good to enable in one's own apps. That can be done by registering it at launch time via the registerDefaults: method as Corbin says above. —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: exception in init
Hi, On 4 Apr 2012, at 19:39, Dave wrote: Hi, If it's a real error ... If it's a programming error ... Just to be sure what you mean: What is a real error? Simply an error which is not a programmer's (or programming?) error? Regards Klaus ___ 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: exception in init
On Apr 4, 2012, at 11:48 AM, Klaus Backert wrote: > Just to be sure what you mean: What is a real error? Simply an error which is > not a programmer's (or programming?) error? A runtime error, one that could occur in a valid program. What this means exactly is up to the designer of the API. For example, let's say your init method takes a required file reference as an NSURL. If this is nil, that's a programmer error —> exception. If this is a URL of some other scheme than file:, that's probably also a programmer error —> exception. If it's a file URL but the file doesn't exist or is unreadable, that cannot be a programmer error, simply because there is no way to preflight-check for that. —> return nil, ideally also an NSError as an 'out' parameter. One of Cocoa's design principles is that a hypothetical 100%-debugged program should never raise any exceptions no matter what. That is, exceptions only result from programmer errors, not runtime issues. (In practice, even Foundation doesn't adhere to this principle completely. Most notoriously, Distributed Objects will raise exceptions if a message-send to a remote object fails for legitimate reasons like a network problem. And since your code could be passed a proxy to a remote object without knowing it, that means pretty much anything could raise an exception. This is one of the reasons I avoid DO.) For what it's worth, I really dislike and disagree with this design principle; I'd rather have a design that used exceptions to signal runtime error conditions — as in every other modern language — instead of kludges like "out NSError**" parameters that mess up everyone's class APIs. But it's much too late to do anything about this other than have lengthy pointless flame-wars, so never mind. —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
Placing Cells in an NSMatrix
Xcode 4.3, Lion 10.7.3 Given a 3 x 3 Matrix which is a sub-class of NSMatrix with Cells sub-classed from NSButton the X origins of column 0 cells seem to be 1.0 point inside the Matrix bounds. So if I want to stroke the Matrix bounds with a line width of e.g. 4.0 points it draws over the left area of the column 0 cells. Hence I would like to make sure that the origins of the cells are where I want them to be, i.e. leave enough room to stroke the Matrix bounds. I've read Matrix Programming Guide and looked at the NSMatrix and NSCell references but I do not understand which methods to use to accomplish this. Should I do this in NSCell calcDrawInfo? And then does that mean for each Cell? Surely there must be simple way to provide a frame for all the Cells inset from the bounds of the Matrix. Nor can I find a way to do this in Interface Builder. AutoLayout is checked but Automatically Resizes Cells is not. TIA for your help. respect Peter ___ 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: Placing Cells in an NSMatrix
On 4 Apr 2012, at 2:20 PM, Peter Teeson wrote: > Given a 3 x 3 Matrix which is a sub-class of NSMatrix with Cells sub-classed > from NSButton > the X origins of column 0 cells seem to be 1.0 point inside the Matrix bounds. > > So if I want to stroke the Matrix bounds with a line width of e.g. 4.0 points > it draws over the left area of the column 0 cells. > > Hence I would like to make sure that the origins of the cells are where I > want them to be, i.e. leave enough room to stroke the Matrix bounds. > > I've read Matrix Programming Guide and looked at the NSMatrix and NSCell > references but I do not understand which methods to use to accomplish this. > > Should I do this in NSCell calcDrawInfo? And then does that mean for each > Cell? > Surely there must be simple way to provide a frame for all the Cells inset > from the bounds of the Matrix. > > Nor can I find a way to do this in Interface Builder. > AutoLayout is checked but Automatically Resizes Cells is not. I read the NSMatrix class reference to say that NSMatrix enforces its frame being the hull of the cells plus the intercell spacing. You won't accomplish you want, in the way you propose, without fighting the framework. Why not embed the matrix in a view of your own? You can then draw whatever you like around it. — F ___ 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: Placing Cells in an NSMatrix
On 2012-04-04, at 5:02 PM, Fritz Anderson wrote: > On 4 Apr 2012, at 2:20 PM, Peter Teeson wrote: >> Given a 3 x 3 Matrix which is a sub-class of NSMatrix with Cells sub-classed >> from NSButton >> the X origins of column 0 cells seem to be 1.0 point inside the Matrix >> bounds. >> >> So if I want to stroke the Matrix bounds with a line width of e.g. 4.0 points >> it draws over the left area of the column 0 cells. >> >> Hence I would like to make sure that the origins of the cells are where I >> want them to be, i.e. leave enough room to stroke the Matrix bounds. >> >> I've read Matrix Programming Guide and looked at the NSMatrix and NSCell >> references but I do not understand which methods to use to accomplish this. >> >> Should I do this in NSCell calcDrawInfo? And then does that mean for each >> Cell? >> Surely there must be simple way to provide a frame for all the Cells inset >> from the bounds of the Matrix. >> >> Nor can I find a way to do this in Interface Builder. >> AutoLayout is checked but Automatically Resizes Cells is not. > > I read the NSMatrix class reference to say that NSMatrix enforces its frame > being the hull of the cells plus the intercell spacing. You won't accomplish > you want, in the way you propose, without fighting the framework. > > Why not embed the matrix in a view of your own? You can then draw whatever > you like around it. Thanks for your thought. But the strange thing is that my experiments show that there is in fact an spacing on the top, right, and bottom of the area between the cells and the matrix bounds. But not on the left side!! I would expect there to be equal spacing all around. I have confirmed this by reducing the size of the cells (setCellSize) and the area between the cells and the Matrix bounds adjusts appropriately except for the left edge. Something I do not understand is going on here that I do not find logical. Peter ___ 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
Core Data migration, what to do when adding the nth version of your model?
Hi all, My Mac app currently has 3 versions of my xcdatamodel. I have explicit .xcmappingmodels for 1->3 and 2->3 (they pre-date lightweight migration). I now need to create version 4. Let's assume it's a trivial change from 3. Thus, I hope to do 3->4 with lightweight migration. In fact, currently I've created 4 and it's identical to 3 (confirmed by diffing them). I've marked 4 as the 'current version'. How do I update my existing .xcmappingmodels to point to version 4 instead of 3? When viewing the xcmappingmodel in Xcode 4, should I use the 'destination' popup and change it from 3 to 4? After doing so, and diffing its xcmapping.xml, I see the "destinationmodelpath" changes in the expecting way, and one big blob also changes. h, scary. Thanks for any help, -- 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: Using NSView fullscreen mode vs. autolayout constraints
This should "just work", of course that depends on the project. Please file a bug and attach the project you're seeing this with. Kevin On 3 Apr 2012, at 18:11, douglas welton wrote: > Hi All, > > [I've read the Cocoa Autolayout release notes and googled for "NSView > autolayout fullscreen" and nothing I've found has shed any light on my > problem] > > Here's the issue: > > My application has a custom view with constraints set to pin it to the top, > bottom, and trailing edges of the window. The width is fixed and the height > may vary as the window resizes. All works well when the application runs on > Lion (10.7.3). Resizing the window produces the desired affect. > > However, when I put the custom view into fullscreen mode (using > -enterFullScreenMode:withOptions:) the view does NOT occupy the entire screen > like I expect (and like it did under Snow Leopard 10.6.8). Instead I get the > normal-sized view positioned in the lower left hand corner of the screen. > When I exit fullscreen mode, the view does NOT return to its previous frame > (like under snow leopard). Instead it is positioned within the window with > its normal bounds at an origin of (0,0). > > When I listen for bounds change notifications, I can see that when the view > goes into fullscreen mode I get two notices: the first one with the bounds > matching the screen, followed by a second with the bounds matching the > original size of the view. Similarly, when I exit fullscreen mode I get two > bounds change notices: the correct bounds followed by an incorrect value. > > If I remove the constraints from the view before entering fullscreen mode, I > get the results I expect. Adding the constraints back to the view when > exiting fullscreen mode has not been successful. Perhaps this is because > some of the constraints depend on the superview (does a fullscreen view have > a superview?) > > My Question: How do constraints affect views placed into fullscreen mode? > Is there something obvious that I can do to get this to "just work" like it > did under Snow Leopard? > > Thanks in advance. > > regards, > > douglas > ___ > > 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/cathey%40apple.com > > This email sent to cat...@apple.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
Help debugging EXC_BAD_ACCESS
This is odd. I have an app that downloads locations from a web service, and
creates NSManagedObejct (subclass: Location) for them. It's been working fine
on simulator and device. Suddenly, I get a consistent EXC_BAD_ACCESS on device
and simulator every time I create a new location (existing locations in the
store work fine.
Here's the code snippet:
[NSOperationQueue addOperationOnMainQueueWithBlock:
^{
for (NSDictionary* locD in locs)
{
NSNumber* woeID = [locD valueForKey: @"woeid"];
Location* loc = [Location locationWithId: woeID inMOC: inMOC];
loc.temp = [locD valueForKey: @"temp"];
NSString* s = [locD valueForKey: @"photoURI"];
loc.photoURI = s;
The line that gets the error is the last line. Thread 1: EXC_BAD_ACCESS
(code=1, address=0x8).
po loc and po s both work. photoURI is a simple dynamic property on Location,
type NSString. The other property, temp, is NSNumber, and always executes fine.
Any ideas? I don't really even know what to check for. ARC, 5.1, Xc4.3.2
Thanks!
--
Rick
___
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
Fielding a mouseDown in a textField
Good people, How do I go about fielding a mouseDown event in an NSTextField? Charlie Dickman 3tothe...@comcast.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: Placing Cells in an NSMatrix
On 2012-04-04, at 6:52 PM, Peter Teeson wrote: > On 2012-04-04, at 5:02 PM, Fritz Anderson wrote: >> On 4 Apr 2012, at 2:20 PM, Peter Teeson wrote: >>> Given a 3 x 3 Matrix which is a sub-class of NSMatrix with Cells >>> sub-classed from NSButton >>> the X origins of column 0 cells seem to be 1.0 point inside the Matrix >>> bounds. >>> >>> So if I want to stroke the Matrix bounds with a line width of e.g. 4.0 >>> points >>> it draws over the left area of the column 0 cells. >>> >>> Hence I would like to make sure that the origins of the cells are where I >>> want them to be, i.e. leave enough room to stroke the Matrix bounds. >>> >>> I've read Matrix Programming Guide and looked at the NSMatrix and NSCell >>> references but I do not understand which methods to use to accomplish this. >>> >>> Should I do this in NSCell calcDrawInfo? And then does that mean for each >>> Cell? >>> Surely there must be simple way to provide a frame for all the Cells inset >>> from the bounds of the Matrix. >>> >>> Nor can I find a way to do this in Interface Builder. >>> AutoLayout is checked but Automatically Resizes Cells is not. >> >> I read the NSMatrix class reference to say that NSMatrix enforces its frame >> being the hull of the cells plus the intercell spacing. You won't accomplish >> you want, in the way you propose, without fighting the framework. >> >> Why not embed the matrix in a view of your own? You can then draw whatever >> you like around it. > Thanks for your thought. > But the strange thing is that my experiments show that there is in fact an > spacing on the top, right, and bottom > of the area between the cells and the matrix bounds. But not on the left > side!! > > I would expect there to be equal spacing all around. I have confirmed this by > reducing the size of the cells (setCellSize) > and the area between the cells and the Matrix bounds adjusts appropriately > except for the left edge. > > Something I do not understand is going on here that I do not find logical. > > Peter In Lion there are new methods related to constraints (in NSLayoutConstraint.h -alignmentRectForFrame and -frameForAlignmentRect) that might be applicable to my query. Also in XCode in the xib Size inspector for the Matrix the View section it shows Frame Rectangle or Layout Rectangle. But changing the X value of one changes it in the other. Looks like I may have to override the above methods as suggested in the reference. Anyone done this and used these and can point at example code or more documentation? But these were only added in Lion so how was it done previously (if at all)? Peter ___ 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: Placing Cells in an NSMatrix
Small bit if knowledge to share. The stroke of the border is drawn centred over the line of the border. So your described 4pt line would intrude 2pts into the bounded area. I'm know if that will help any with understanding the left-shifting you have observed. Erik Stainsby erik.stain...@roaringsky.ca - Consistently place constants on the LHS of an expression: you cannot accidentally assign when you meant to compare. On 2012-04-04, at 9:04 PM, Peter Teeson wrote: > On 2012-04-04, at 6:52 PM, Peter Teeson wrote: >> On 2012-04-04, at 5:02 PM, Fritz Anderson wrote: >>> On 4 Apr 2012, at 2:20 PM, Peter Teeson wrote: Given a 3 x 3 Matrix which is a sub-class of NSMatrix with Cells sub-classed from NSButton the X origins of column 0 cells seem to be 1.0 point inside the Matrix bounds. So if I want to stroke the Matrix bounds with a line width of e.g. 4.0 points it draws over the left area of the column 0 cells. Hence I would like to make sure that the origins of the cells are where I want them to be, i.e. leave enough room to stroke the Matrix bounds. I've read Matrix Programming Guide and looked at the NSMatrix and NSCell references but I do not understand which methods to use to accomplish this. Should I do this in NSCell calcDrawInfo? And then does that mean for each Cell? Surely there must be simple way to provide a frame for all the Cells inset from the bounds of the Matrix. Nor can I find a way to do this in Interface Builder. AutoLayout is checked but Automatically Resizes Cells is not. >>> >>> I read the NSMatrix class reference to say that NSMatrix enforces its frame >>> being the hull of the cells plus the intercell spacing. You won't >>> accomplish you want, in the way you propose, without fighting the framework. >>> >>> Why not embed the matrix in a view of your own? You can then draw whatever >>> you like around it. >> Thanks for your thought. >> But the strange thing is that my experiments show that there is in fact an >> spacing on the top, right, and bottom >> of the area between the cells and the matrix bounds. But not on the left >> side!! >> >> I would expect there to be equal spacing all around. I have confirmed this >> by reducing the size of the cells (setCellSize) >> and the area between the cells and the Matrix bounds adjusts appropriately >> except for the left edge. >> >> Something I do not understand is going on here that I do not find logical. >> >> Peter > In Lion there are new methods related to constraints (in NSLayoutConstraint.h > -alignmentRectForFrame and -frameForAlignmentRect) that might be applicable > to my query. > Also in XCode in the xib Size inspector for the Matrix the View section it > shows Frame Rectangle or Layout Rectangle. But changing the X value of one > changes it in the other. > Looks like I may have to override the above methods as suggested in the > reference. Anyone done this and used these and can point at example code or > more documentation? > > But these were only added in Lion so how was it done previously (if at all)? > > Peter > ___ > > 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/erik.stainsby%40roaringsky.ca > > This email sent to erik.stain...@roaringsky.ca ___ 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: Fielding a mouseDown in a textField
On 05/04/2012, at 9:51 AM, Charlie Dickman wrote: > Good people, > > How do I go about fielding a mouseDown event in an NSTextField? For what purpose? NSTextField generally works without you having to do anything special. If you have some unusual requirement, you'll need to tell us what it is. --Graham ___ 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
