Re: Objective-C Question
On 11 Mar 2013, at 21:45, John McCall wrote:
On Mar 11, 2013, at 2:02 PM, Dave d...@looktowindward.com wrote:
On 11 Mar 2013, at 20:53, John McCall wrote:
On Mar 11, 2013, at 1:33 PM, Dave d...@looktowindward.com wrote:
On 11 Mar 2013, at 20:26, Mike Abdullah wrote:
I had assumed (and I thought I'd done something like this
before) that the:
myDict = [[super class] newDict];
statement would call newDict in BaseClass Instead it calls
the version in NewClass and goes into an infinite loop!!
Yes. [super class] calls super's implementation of the -class
method. You haven't overridden -class, so it does the same
thing as [self class].
People often make the same mistake in trying to do [super
respondsToSelector…
I'm guessing what you're really after is [[self superclass]
newDict]
Thanks a Million, yes that's what I wanted!
Are you sure? This will indeed call the superclass's 'newDict',
but the 'self' object will be the superclass, not your class.
That means it'll (almost certainly) create an instance of your
class's superclass. The easier way to do this is just [Foo
newDict], where Foo is the name of your superclass.
If you want to invoke your superclass method, but with your class
as 'self' — i.e. if you want to create an instance of your class
— you should use [super newDict].
I don't know what you mean by:
i.e. if you want to create an instance of your class
I don't want to create an instance of my class, I want the class
to return a dictionary, that gets things added from the current
class down through the inheritance hierarchy,
BaseClass alloc's a dict and puts in some data,
Subclass1 calls base class and it's it own data.
Subclass2 calls subclass1.
How is this creating an instance of any object except the NSDict?
Where do you think Subclass1's own data goes if the object
allocated is actually a BaseClass?
I'm not allocating a base class or any other kind of class except a
dictionary. Did I say anything about instance data? No. The data I
mean is NOT instance data, how could it be? There is no object
allocated in this example (except the dictionary). I am using class +
methods and they work on the Class,
I could just say [BaseClass newDict], but the reason I didn't is
so the code is not dependent on knowing the base class, e.g. it
can move position in the hierarchy and still call the correct
class method.
Do you want the created dictionary to have the instance variables
and methods you've defined in your subclass or not? If so, you
need to create an instance of your subclass.
There are no instance variables as I keep saying, this no instance,
so how can there be instance variables?
I think you are having basic conceptual problems with inheritance
here.
I don't think you understand the difference between class methods and
instance methods. Here is an example of what I mean:
BaseClass (Class not an instance of a class).
+(MSMutableDictionary*) newDict
{
MSMutableDictionary*myDict;
myDict = [[MSMutableDictionary alloc] init];
[myDIct setObect:@SomeaValueX forKey:@someKeyX];
return myDict;
}
Subclass1:
+(MSMutableDictionary*) newDict
{
MSMutableDictionary*myDict;
myDict = [super newDict];
[myDIct setObect:@SomeValueY forKey:@someKeyY];
return myDict;
}
Subclass2:
+(MSMutableDictionary*) newDict
{
MSMutableDictionary*myDict;
myDict = [super newDict];
[myDIct setObect:@SomeValueZ forKey:@someKeyZ];
return myDict;
}
No instance data in site and no instances of the objects in question,
just class methods.
All the Best
Dave
___
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: Objective-C Question
On 11 Mar 2013, at 21:14, Mike Abdullah wrote: if from an instance + Method I do: [super someMethod], then surely it's an error because this isn't an instance? It *is* an instance. An instance of the *metaclass*. This is where you're deep into the guts of Objective-C :) H, I think I kind of knew this already but the details were fuzzy. Ok, i understand what you mean, so is the following correct: 1. In a Instance - method, if you do [self someMethod] it will call - someMethod in the current class if it is defined there, or it will call -someMethod, in one of the parents of the current instance or error if -someMethod is not defined. If -someMethod is defined, and it calls [self -someMethod] then it will call as high up the chain as possible, e.g. will find -someMethod in one of the subclasses if it is defined or it will call it's own version? e.g. BaseClass --- Subclass1 --- Subclass2 --- Subclass3 -someMethhod--- Subclass2 --- Subclass3 ___ 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: Issue with makeKeyAndOrderFront
Thanks Ken. That works but this property doesn't make it active window.
Regards,
Anni
From: Ken Thomases k...@codeweavers.com
To: anni saini anni_sa...@yahoo.com
Cc: cocoa-dev@lists.apple.com cocoa-dev@lists.apple.com
Sent: Monday, 11 March 2013 7:31 PM
Subject: Re: Issue with makeKeyAndOrderFront
On Mar 11, 2013, at 3:15 AM, anni saini wrote:
My app is just having NSStatusBar menu such as Adium. On right click context
menu, I'm calling some window to open.
//Calling method
myWindow = [[MyWindowViewController alloc]init];
myWindow.data = @abc;
[myWindow show:self];
//Called method
- (void)show:(NSWindow*)parentWindow
{
[myPanel centre];
[myPanel setFloatingPanel:YES];
[myPanel makeKeyAndOrderFront:nil];
}
Observations:
1. When app doesn't have any window open. myPanel doesn't open until I open
any window of my app.
2. When app have some window open but its in background, myPanel doesn't open
until I click on any window of my app to make it front window.
3. When I tried to debug the issue, window gets open each time if I set break
point in this method.
4. If I use [NSApp activateIgnoringOtherApps:YES]; before
makeKeyAndOrderFront method, myPanel is working as expected.
Please let me know whats wrong with the above code or how can i make it
better?
Your panel probably has hidesOnDeactivate set.
Regards,
Ken
___
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
Another Gnarly Objective-C Question!
Hi All, Thanks for all help on the last question, here is one on a similar vein: This is all Class methods, no instances are allocated or intended to be allocated at this stage. in + Method in a subclass: [[self class] someMethod]; This calls +someMethod in the current class, if it exists, if not, it calls in one of the super-classes if it exists. Is this correct? If one of the super classes calls [[self class] someMethod]; It will call as high up the chain as possible, resulting in an infinite loop in this case? Is there a diagram somewhere showing how this works for the 4 cases of: 1. [[self class] +someMethod]; 2. [[super class] +someMethod]; 3. [super +someMethod]; 4. [[self superclass] +someMethod]; It does seem logical to expect that if: [[self class] someMethod]; calls +someMethod the [[super class] +someMethod] would call +someMethod in the Superclass or is it just me??? lol Thanks a lot Dave ___ 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: Objective-C Question
On 12/03/2013, at 6:31 PM, Dave d...@looktowindward.com wrote:
I don't think you understand the difference between class methods and
instance methods.
Are you certain you do?
Here is an example of what I mean:
Why not state you goals instead of give us a lump of incoherent code?
As far as I can see you don't need a series of subclasses here (unless there is
something else going on you haven't told us about). If you just want some
factory classes to return certain prefilled dictionaries, then just do that,
and forget about trying to mangle the meaning of inheritance and do something
overcomplicated.
All you need is:
@interface DictionaryFactory1 : NSObject
+ (NSDictionary*) dictionary;
@end
// repeat the above with additional class names as desired, e.g.
DictionaryFactory2, DictionaryFactory3
+ (NSDictionary*) dictionary
{
// create the dictionary
// set some preloaded data
// return it
}
then your code just calls [DictionaryFactory1 dictionary], [DictionaryFactor2
dictionary] etc.
what's so hard about that?
(n.b. it's NSDictionary, not MSDictionary, you may have the wrong OS in mind).
Even if Dictionary factory 2 inherits from Dictionary factory 1 for some reason
that isn't clear from your post, it doesn't change this at all. You just
override +dictionary and return what you want. There is no reason to call super
at all.
If you want DF2 to add some further items to DF1's implementation, then call
super and add the extra items to the dict:
@implementation DF2
+ (NSDictionary*) dictionary
{
NSMutableDictionary* md = [[super dictionary] mutableCopy];
// add extra items to md
return [md autorelease];
}
--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
Re: Another Gnarly Objective-C Question!
On 12/03/2013, at 7:39 PM, Dave d...@looktowindward.com wrote:
Hi All,
Thanks for all help on the last question, here is one on a similar vein:
This is all Class methods, no instances are allocated or intended to be
allocated at this stage.
in + Method in a subclass:
[[self class] someMethod];
There's no reason to do this in a +method, just call [self someMethod];
However, it's equivalent because in a +method, [self class] simply returns self.
This calls +someMethod in the current class, if it exists, if not, it calls
in one of the super-classes if it exists. Is this correct?
Yes, like any method of any class, whether an instance method or a class method.
If one of the super classes calls [[self class] someMethod]; It will call as
high up the chain as possible, resulting in an infinite loop in this case?
It will enter an infinite loop if it calls itself, like any function anywhere
(that doesn't terminate under some condition). It's got nothing to do with how
high in the chain, or whatever.
+ (void) method
{
[[self class] method]; // stack overflow due to infinite recursion
because this is identical to [self method]
}
in a + method, [self class] === self. Once you've got that, you've got it.
You're overthinking this.
A class method is just an instance method of the class object. No magic at all.
So all this confusion you've caused yourself about [super class] and so on is
wholly unnecessary to correctly use class methods.
[super class] is a useless construction because +class returns self. That means
that [super class] is no different from [self class] is no different from self.
It's reasonable to call [super sameMethod] in a class method and it will do
exactly what it does for an instance method (because it IS an instance method
of the class object). It will call super's implementation. In general that's
all you need - deeper introspection in class methods just to do ordinary kinds
of work (like your dictionary case) are not required.
--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
Re: Objective-C Question
Hi,
What I have works fine now, but to explain:
Basically I have just a Class definition, e.g.
Class theClass;
I can't instantiate the class (not that I'd consider that anyway),
because I have no idea what side effects calling the init method of
the class would be, it might, for instance, spawn off a millions
worker threads or it might be a Singleton that can't be released and
should never have been created in the first place! So, I can't call
any Instance Methods of the Class, but, I need to know info about the
class in order cache it and later combine it with other data, e.g. I
take the data returned from the Class Method chain and use this along
with other data to form a value. This system is already in place and
I've seen it used a number of times, I think even in Apple Sample
code. I think CoreData does something like this although I may be
mistaken.
This is performed once at Initialization (App Launch) time.
The object chain may or may not be created at some later point, if it
does need to be, then another method in the same class as above gets
called, it then uses information provided to the Method and Data
Stored from the initialization to build the object corresponding
Class chain.
So, in a Class called something like DataManager, there are two methods:
-(void) configureClass:(Class) theClass
{
DataManagerInfo*myInfo;
myDict = [theClass newDict];
if (myDict == nil)
return;
myInfo = [[DataManagerInfo alloc] init];
[self computeInfoUsing:myInfo withSomeOtherData:otherData
andConfigDict:myDict];
// Store Info in Dictionary for later
[self.pClassDict setObject:myInfo forKey:NSStringFromClassName
(theClass)];
}
-(id) createObjectForClass:(Class) theClass andOtherData:someOtherData
{
// takes info from pClassDict and data from OtherData and uses this
to create the Object and returns it.
}
This all works fine and I think it's quite neat, it's certainly very
fast, since a lot is pre-computed. The only problem I had was in some
code in one of the newly added classes that called the super class
like so:
[[super class] newDict];
Instead of [super newDict]
It was late and I was tired when I looked at the code and [[super
class] newDict]; doesn't seem that unreasonable to expect to call the
super class, which it did, but I hadn't realized that it in turn
would call back up the chain. Then someone suggested:
[[self superclass] newDict];
Which also works, but so does [super newDict],
I not really sure which is the best in this case? I really don't want
any class calling back up the chain in this case, so I think [[self
superclass] newDict]; ?
I've got it working ok with [super newDict] but not sure if it would
be best to change it to [[self superclass] newDict]
I don't want to hard code the class names into the code. Because I
need it to work regardless of the order which I have no control over.
The code that calls the DataManager class, has a network of class
inheritance chains and hard coding (not that I can) would break that,
for example:
BaseClass
BaseClass --- TypeAClass
TypeAClass --- TypeBClass
TypeBClass --- TypeCClass
TypeCClass --- TypeDClass
In this case 5 classes are configured and might created, BaseClass,
A, B, C and D.
If someone changed it so that they inherited in a different order the
code would break, by using super it avoids this problem.
On 12 Mar 2013, at 08:44, Graham Cox wrote:
All you need is:
@interface DictionaryFactory1 : NSObject
+ (NSDictionary*) dictionary;
@end
// repeat the above with additional class names as desired, e.g.
DictionaryFactory2, DictionaryFactory3
+ (NSDictionary*) dictionary
{
// create the dictionary
// set some preloaded data
// return it
}
then your code just calls [DictionaryFactory1 dictionary],
[DictionaryFactor2 dictionary] etc.
what's so hard about that?
Nothing, but it doesn't do what I want it to!
(n.b. it's NSDictionary, not MSDictionary, you may have the wrong
OS in mind).
Even if Dictionary factory 2 inherits from Dictionary factory 1 for
some reason that isn't clear from your post,
From my original post:
Take the following example:
@interface BaseClass
+(NSMutableDictionary*) newDict;
@end
@implementation BaseClass
+(NSMutableDictionary*) newDict
{
return [[NSMutableDictionary alloc] init];
}
@class NewClass;
@interface NewClass : BaseClass
+(NSMutableDictionary*) newDict;
@end
#import BaseClass.h
@implementation NewClass
+(NSMutableDictionary*) newDict
{
NSMutableDictionary*myDict;
myDict = [[super class] newDict];//*** This was the problem,
it now read [super newDict] as all is well.
[myDict setObject:@Some Data forKey:@someKey];
return myDict;
}
@end
How is the above not clear? Apart from the names I chose, I'd say:
@interface NewClass : BaseClass
Was a bit of a give away! lol
it doesn't change this at all.
Re: Objective-C Question
On 12/03/2013, at 11:45 PM, Dave d...@looktowindward.com wrote:
Except it doesn't do what the above does!
Yes it does.
@implementation DF2
+ (NSDictionary*) dictionary
{
NSMutableDictionary* md = [[super dictionary] mutableCopy];
// add extra items to md
return [md autorelease];
}
From reading the above, I cant see this is any better than what I have, it
fact it copies the dictionary every time, which is not what is wanted as well
as being slower.
Is it? Have you measured it? Does it matter?
In any case, it was only an example of how to achieve what you want, to show
how to use class inheritance.
To be honest, the rest of your explanation doesn't make any sense to me, and I
can't really be bothered to unravel it. Your whole I can't instantiate the
class is incoherent at best (you *are* instantiating the class, like it or
not). Maybe it makes sense to you, but not to me. I was trying to cut across
all that irrelevant discussion by going back to basics and trying to get you to
understand that:
a) [super class] is a meaningless construct, in that it doesn't do anything
different from [self class],
b) in a class method, [self class] is just self,
c) a class method is just an ordinary instance method of the class object.
If you can understand those points, the rest should follow naturally. What you
are trying to do is very straightforward, and requires no special trickery. The
attempts you made show a clear lack of understanding about inheritance, which
is what others were trying to tell you.
--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
Re: Fast user switching notifications
Le 11 mars 2013 à 23:25, Jean Suisse jean.li...@gmail.com a écrit : Dear All, There may be several approaches to solve the issue I am about to describe, either on the userland side or on the kernel side... or in-between, using a daemon. Current situation A bsd kernel extension communicates with a regular userland application (called theApp). The kext gathers statistics, sends data to the user, takes orders from the user, etc.. There are two-way communications initiated by both sides using control sockets – There may be no market for such app, it is more of investigation tool, but that's irrelevant. Goal I would need to handle fast user switching, so that data sent by the kext are directed towards the user that can actually handle them. This user is the one owning the graphic interface (is there a technical word to say that?). Issue When switching from user(A) to user(B) (using fast user switching for instance), user(A) no longer owns the graphic interface and theApp(A) is no longer able to interact with the user and give the required feedback to the kext. User(B) starts theApp(B) and interacts normally with the kext. Then, when switching from B to A, the same issue occurs in reverse. Solution One approach would be to have theApp(A) launched by user(A) to be notified when user(A) looses access to the graphic interface. When switching back to user(A) theApp(A) and theApp(B) would also get notified. I read this document (https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPMultipleUsers/Concepts/UserSwitchNotifications.html), but it seems that there is some race condition occurring, maybe as a result of interacting with the kernel (the kext must perform a few tasks before allowing theApp(A) to disconnect and theApp(B) to connect). Are there any other alternatives, from the userland side ? There is an other way to track the current user: using the SystemConfiguration framework notification: http://developer.apple.com/library/mac/#qa/qa1133/_index.html -- 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: Objective-C Question
On 12 Mar 2013, at 13:37, Graham Cox wrote:
On 12/03/2013, at 11:45 PM, Dave d...@looktowindward.com wrote:
Except it doesn't do what the above does!
Yes it does.
Oh No it doesn't!
crowd echo's Oh Yes it does!
It creates a copy of read only dictionary and then modifies that. If
the underlying dictionary changes, you will not see the changes
reflected in the copy!
@implementation DF2
+ (NSDictionary*) dictionary
{
NSMutableDictionary* md = [[super dictionary] mutableCopy];
// add extra items to md
return [md autorelease];
}
From reading the above, I cant see this is any better than what I
have, it fact it copies the dictionary every time, which is not
what is wanted as well as being slower.
Is it? Have you measured it? Does it matter?
Well, like anyone else I'd like it run run as fast as possible and
anyway, it is of course slower, it would have to send a retain
message to each Object in the dictionary.
In any case, it was only an example of how to achieve what you
want, to show how to use class inheritance.
To be honest, the rest of your explanation doesn't make any sense
to me, and I can't really be bothered to unravel it. Your whole I
can't instantiate the class is incoherent at best (you *are*
instantiating the class, like it or not).
Ok, instantiate the object that is defined by the class!, to spell it
out do a [[theClass alloc] init];,
I'm not sure what you mean by
(you *are* instantiating the class, like it or not)
The class may well be being instantiated, but AFAIK, there is no
statement in the App that does this, apart from the @interface
definition if that''s what you mean,
Maybe it makes sense to you, but not to me. I was trying to cut
across all that irrelevant discussion by going back to basics and
trying to get you to understand that:
It makes sense to a whole lot more people that me and something very
similar is done in an Apple Sample somewhere too.
a) [super class] is a meaningless construct, in that it doesn't do
anything different from [self class],
I know that now, but it's not instantly obvious to me anyway! It's a
language gotcha, I will remember now hopefully.
b) in a class method, [self class] is just self,
c) a class method is just an ordinary instance method of the class
object.
If you can understand those points, the rest should follow
naturally. What you are trying to do is very straightforward, and
requires no special trickery.
There why not just look at the original post and say, ah you need
to change it to use [super ], instead of all the other stuff that
didn't even do the same thing!
The attempts you made show a clear lack of understanding about
inheritance, which is what others were trying to tell you.
Not it doesn't! It shows that I was confused after 16 hours coding by
the difference between [[super class] ] and [super ]. From
reading my original and subsequent posts, only a complete moron or
someone trying to cause upset would say The attempts you made show a
clear lack of understanding about inheritance. If you are serious
and not just trying to wind me up and you are a complete moron, then
please do explain how you can say that after looking at the original
post.
Take the following example:
@interface BaseClass
+(NSMutableDictionary*) newDict;
@end
@implementation BaseClass
+(NSMutableDictionary*) newDict
{
return [[NSMutableDictionary alloc] init];
}
@class NewClass;
@interface NewClass : BaseClass
+(NSMutableDictionary*) newDict;
@end
#import BaseClass.h
@implementation NewClass
+(NSMutableDictionary*) newDict
{
NSMutableDictionary*myDict;
myDict = [[super class] newDict]; //***
should be [super NewDict];
[myDict setObject:@Some Data forKey:@someKey];
return [[NSMutableDictionary alloc] init];
}
@end
So, what is it? Wind up merchant or Moron?
All the Best
Dave
___
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
UITableViewController init not called (storyboard)
I'm playing around with a storyboard app on iOS. To test a TableView I created a UITableViewController subclass, and set it as the custom class in the storyboard. Then in the init method, I added a bunch of objects to act as the datasource, however init never gets called, and my tableview remains empty. If I modify the datasource methods, by adding a cell title and return a positive number for the numberOfRows, I do see the table being filled, so everything must be hooked up ok. But why is init never called? I also tried - (id)initWithStyle:(UITableViewStyle)style, but that is not called either. Any ideas? - Koen. ___ 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: UITableViewController init not called (storyboard)
Have you tried moving those datasource codelines to viewDidLoad or viewWillAppear? It may be that when the view is instantiated from the storyboard init is not called? Op 12 mrt. 2013, om 17:09 heeft Koen van der Drift koenvanderdr...@gmail.com het volgende geschreven: I'm playing around with a storyboard app on iOS. To test a TableView I created a UITableViewController subclass, and set it as the custom class in the storyboard. Then in the init method, I added a bunch of objects to act as the datasource, however init never gets called, and my tableview remains empty. If I modify the datasource methods, by adding a cell title and return a positive number for the numberOfRows, I do see the table being filled, so everything must be hooked up ok. But why is init never called? I also tried - (id)initWithStyle:(UITableViewStyle)style, but that is not called either. Any ideas? - Koen. ___ 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/diederik%40tenhorses.com This email sent to diede...@tenhorses.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: Problem with using a Navigation Controller in Xcode
On Mon, 11 Mar 2013 09:19:23 -0600, gary.gard...@brokensoftware.com said: 10) Drag a Navigation Controller to the storyboard window 11) Click on the root view controller view Yes, but the problem is that the default root view controller (11) that you get when drag a navigation controller into the canvas (10) is a UITableViewController. Your class is not a UITableViewController, so, quite correctly, you can't turn a UITableViewController into your class. You have to *delete* the UITableViewController and replace it as root view controller with a plain vanilla UIViewController. m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ A fool + a tool + an autorelease pool = cool! Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do ___ 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: UITableViewController init not called (storyboard)
On Mar 12, 2013, at 12:32 PM, Ten Horses | Diederik Meijer diede...@tenhorses.com wrote: Have you tried moving those datasource codelines to viewDidLoad or viewWillAppear? It may be that when the view is instantiated from the storyboard init is not called? I thought about that, and yes it works. I was hesitant to use that because I thought that it would be called every time the view appears on the screen, but it looks like it doesn't in the case of viewDidLoad. Thanks, - Koen. ___ 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: Objective-C Question
On Mar 12, 2013, at 12:31 AM, Dave d...@looktowindward.com wrote:
On 11 Mar 2013, at 21:45, John McCall wrote:
On Mar 11, 2013, at 2:02 PM, Dave d...@looktowindward.com wrote:
On 11 Mar 2013, at 20:53, John McCall wrote:
On Mar 11, 2013, at 1:33 PM, Dave d...@looktowindward.com wrote:
On 11 Mar 2013, at 20:26, Mike Abdullah wrote:
I had assumed (and I thought I'd done something like this before) that
the:
myDict = [[super class] newDict];
statement would call newDict in BaseClass Instead it calls the
version in NewClass and goes into an infinite loop!!
Yes. [super class] calls super's implementation of the -class method.
You haven't overridden -class, so it does the same thing as [self class].
People often make the same mistake in trying to do [super
respondsToSelector…
I'm guessing what you're really after is [[self superclass] newDict]
Thanks a Million, yes that's what I wanted!
Are you sure? This will indeed call the superclass's 'newDict', but the
'self' object will be the superclass, not your class. That means it'll
(almost certainly) create an instance of your class's superclass. The
easier way to do this is just [Foo newDict], where Foo is the name of your
superclass.
If you want to invoke your superclass method, but with your class as
'self' — i.e. if you want to create an instance of your class — you should
use [super newDict].
I don't know what you mean by:
i.e. if you want to create an instance of your class
I don't want to create an instance of my class, I want the class to return
a dictionary, that gets things added from the current class down through
the inheritance hierarchy,
BaseClass alloc's a dict and puts in some data,
Subclass1 calls base class and it's it own data.
Subclass2 calls subclass1.
How is this creating an instance of any object except the NSDict?
Where do you think Subclass1's own data goes if the object allocated is
actually a BaseClass?
I'm not allocating a base class or any other kind of class except a
dictionary. Did I say anything about instance data? No. The data I mean is
NOT instance data, how could it be? There is no object allocated in this
example (except the dictionary). I am using class + methods and they work on
the Class,
You seem to be assuming that this works the way it does in C# or Java. It does
not.
To use your example:
BaseClass (Class not an instance of a class).
+(MSMutableDictionary*) newDict
{
MSMutableDictionary* myDict;
myDict = [[MSMutableDictionary alloc] init];
[myDIct setObect:@SomeaValueX forKey:@someKeyX];
return myDict;
}
Subclass1:
+(MSMutableDictionary*) newDict
{
MSMutableDictionary* myDict;
myDict = [super newDict];
[myDIct setObect:@SomeValueY forKey:@someKeyY];
return myDict;
}
Subclass2:
+(MSMutableDictionary*) newDict
{
MSMutableDictionary* myDict;
myDict = [super newDict];
There is exactly one difference between [[self superclass] newDict] and [super
newDict] here: the value of 'self'. (This assumes the obvious behavior for
+superclass, of course.)
[[self superclass] newDict] is exactly equivalent to [Subclass1 newDict].
[super newDict] calls the same method as [Subclass1 newDict], but using a
'self' value that is still the Subclass1 class.
Now, if everything is implemented the way you've quoted it, the value of 'self'
doesn't matter, because +[Subclass1 newDict] just passes it on to +[BaseClass
newDict], and +[BaseClass newDict] ignores 'self'.
However, that wouldn't be an idiomatic implementation. The usual expectation
is that allocating methods, like +new methods, construct an object *of type
self* (at least). For example, NSObject has a +new method that looks like this:
+ (id) new {
return [[self alloc] init];
}
This way, subclasses don't have to reimplement +new in order to make it work:
[NSWindow new] eventually does an [[NSWindow alloc] init], just like you'd
expect.
This is why I was talking about instance methods and fields: because,
generally, people introduce new classes because they expect to create instances
of them, and [[self superclass] newDict] bypasses that in a way that might not
be obvious.
What you're doing is introducing a ton of classes in order to create a
delegation hierarchy of factory methods. It's probably the most wasteful way
of achieving this goal that I can see — why not just use functions or
something? — but you're certainly welcome to it. Just understand that most
people, reading code like +[FooDictionary newDict], would reasonably assume
that this actually creates an instance of FooDictionary.
John.
___
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:
Re: UITableViewController init not called (storyboard)
The particular initializer in use is initWithCoder: UITableView conforms to the NSCoding protocol. Hope this helps. Damian On Mar 12, 2013, at 11:09 AM, Koen van der Drift wrote: I'm playing around with a storyboard app on iOS. To test a TableView I created a UITableViewController subclass, and set it as the custom class in the storyboard. Then in the init method, I added a bunch of objects to act as the datasource, however init never gets called, and my tableview remains empty. If I modify the datasource methods, by adding a cell title and return a positive number for the numberOfRows, I do see the table being filled, so everything must be hooked up ok. But why is init never called? I also tried - (id)initWithStyle:(UITableViewStyle)style, but that is not called either. Any ideas? - Koen. ___ 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/damiancarrillo%40me.com This email sent to damiancarri...@me.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: Freshly created .xcmappingmodel seems to have incorrect version hashes
On Mon, 17 Dec 2012 17:37:22 -0500, Sean McBride said:
I created a brand new .xcmappingmodel for version x to y of my
xcdatamodel. I don't change anything in the mapping GUI. I clean. I
build. I write some test code:
NSURL* url = ...App.app/Contents/Resources/VersionXToY.cdm
mappingModel = [[NSMappingModel alloc] initWithContentsOfURL:url]
for (NSEntityMapping* em in [mappingModel entityMappings])
{
id dn = [em destinationEntityName];
id dh = [em destinationEntityVersionHash];
NSLog(@%@ = %@, dn, dh);
}
I then open up the VersionInfo.plist file within my .app and compare the
entity hashes.
For most, the VersionInfo.plist matches the hashes extracted from
the .cdm, but for 2 entities they do not.
How can this be?! As I said, the xcmappingmodel is freshly created!
Just to follow up on this for the archives...
It turns out to be a bug in Xcode's GUI, which I filed as:
rdar://13073236 Xcode relationship editor shouldn't toggle 'minimum' when
toggling 'optional'
-
Summary:
Xcode's Core Data relationship editor should *not* toggle the 'minimum'
checkbox when toggling the 'optional' checkbox because doing so breaks Core
Data migration.
Details:
- unzip TrivialMigrationTestStartPoint.zip
- open its Xcode project
- notice it has a trivial xcdatamodel with just 2 entities
- each entity has a relationship and they are both non-optional
- now let's say we need to change the model…
- in Xcode:
- select the xcdatamodel
- choose Editor Add Model Version…
- the xcdatamodeld bundle and a Version 2.xcdatamodel are created
- select the version 2.xcdatamodel
- select the Person entity's 'department' relationship
- notice the 'optional' checkbox is off, the 'minimum' checkbox is on, and the
minimum value is 1.
- now let's say we want 'department' to be optional. This should be no problem
for migration, since in old stores it will always be present (since it was
non-optional)
- click the optional checkbox
- At this point you have the equivalent of TrivialMigrationTestEndPoint.zip
(also attached)
Expected:
- 'optional' checkbox should go ON, and other settings *should not change*.
Actual:
- 'optional' checkbox does correctly go ON
- the 'minimum' checkbox is also turned OFF. This is bad, elaboration below.
- (see attached video)
Notes:
- turning off 'minimum' is bad because it results in rdar://13000229. It
breaks migration. An xcmappingmodel built from Version1 and Version2 above
will have different hashes than the actual xcdatamodels. It seems that,
rightly or wrongly, because the minCount is present in the old model but not in
the new model the hashes are different.
- see also the attached ModelDiff.png which shows the change in the xml
xcdatamodel
Version1:
relationship name=department minCount=1 maxCount=1
deletionRule=Nullify destinationEntity=Department inverseName=people
inverseEntity=Department syncable=YES/
Version2:
relationship name=department optional=YES maxCount=1
deletionRule=Nullify destinationEntity=Department inverseName=people
inverseEntity=Department syncable=YES/
The fact that minCount=1 is gone in Version2 is what breaks migration, as per
rdar://13000229.
Regression:
Occurs in 4.5.2 and 4.6dp4. Didn't try older.
-
Cheers,
--
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: Problem with using a Navigation Controller in Xcode
Matt, Step #7 was delete what's there. Perhaps I was not clear. In the Storyboard, I delete it. Step #8 I add a UIViewController. Sorry if that caused confusion 1) Launch XCode 2) Create a new project 3) Select Single View Application 4) Give a Project Name 5) Select Device iPhone 6) Click on MainStoryboard.storyboard 7) Delete what's there so that it's blank --- 8) Add New file Objective-C class subclass UIViewController -- 9) Uncheck iPad and uncheck XIB 10) Drag a Navigation Controller to the storyboard window 11) Click on the root view controller view 12) Click on the Identity Inspector 13) Type in the Custom Class section the name of the class from step #8 Thanks in advance On Mon, 11 Mar 2013 09:19:23 -0600, gary.gard...@brokensoftware.com said: 10) Drag a Navigation Controller to the storyboard window 11) Click on the root view controller view Yes, but the problem is that the default root view controller (11) that you get when drag a navigation controller into the canvas (10) is a UITableViewController. Your class is not a UITableViewController, so, quite correctly, you can't turn a UITableViewController into your class. You have to *delete* the UITableViewController and replace it as root view controller with a plain vanilla UIViewController. m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ A fool + a tool + an autorelease pool = cool! Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do ___ 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: Objective-C Question
On 12 Mar 2013, at 16:44, John McCall wrote:
There is exactly one difference between [[self superclass] newDict]
and [super newDict] here: the value of 'self'. (This assumes the
obvious behavior for +superclass, of course.)
[[self superclass] newDict] is exactly equivalent to [Subclass1
newDict].
[super newDict] calls the same method as [Subclass1 newDict], but
using a 'self' value that is still the Subclass1 class.
Now, if everything is implemented the way you've quoted it, the
value of 'self' doesn't matter, because +[Subclass1 newDict] just
passes it on to +[BaseClass newDict], and +[BaseClass newDict]
ignores 'self'.
However, that wouldn't be an idiomatic implementation. The usual
expectation is that allocating methods, like +new methods,
construct an object *of type self* (at least). For example,
NSObject has a +new method that looks like this:
+ (id) new {
return [[self alloc] init];
}
This way, subclasses don't have to reimplement +new in order to
make it work: [NSWindow new] eventually does an [[NSWindow alloc]
init], just like you'd expect.
This is why I was talking about instance methods and fields:
because, generally, people introduce new classes because they
expect to create instances of them, and [[self superclass] newDict]
bypasses that in a way that might not be obvious.
What you're doing is introducing a ton of classes in order to
create a delegation hierarchy of factory methods. It's probably
the most wasteful way of achieving this goal that I can see
Firstly, I didn't create it, it was already there and I had/have to
make it work faster since it is/was too slow. There was no time to
rewrite it, and, even if there was, I really can't see a better way,
there may be different ways, but I can't see that they would be
substantially better.
This class I am working can receive data from the following sources:
An Object of the same Class.
PList Raw Data String.
Dictionary.
Network
PList file.
Core Data.
SQLite Database.
Other Data File.
This source is turned into Objective-C Objects using data created in
the Class Chain, then Cached and later if necessary used to create
the Object. The basic mechanism was already there, all I've done is
to make it quicker by caching info so that it doesn't need to be
regenerated each time an object is created. The .m file for each of
the classes in the chain have specialist *instance* methods that are
used during the object life cycle. The things that threw me I think
was that I did two things at once, I changed the caching code and
also added two more classes to the chain. The problem was in the
newly added Classes, not in the caching code and was just the
difference between [super xxx] and [[super class] xxx], a simple bug
to fix once I realized what the problem was.
Another way to do it would be to define each Class to contain all the
fields contained in the chain, but this would mean that there would
loads more classes and lots of duplication of code. At present there
are around 50 such classes, if I were to Flatten them, there would
probably be 200+.
I thought the initial design was quite good, it was just a slow,
fairly dumb implementation, this makes it a lot faster which is a
good and fixes the immediate problem. If I thought this was really
probably the most wasteful way of achieving this goal that I can
see, I could and would ask for time to fix it. But I can't see a
substantially better way of doing it or why you think this way of
doing it is wasteful? Wasteful in terms of what? Code Size? Execution
Time (bearing in mind it is done one, the class chaining I mean and
instances allocated many times). I can't think of anything that is
excessively wasteful and it's very flexible.
If you can of better, less wasteful way then please do let me know
and I will look at your suggestions.
— why not just use functions or something? — but you're certainly
welcome to it.
I'm not sure how functions would help me achieve anything given the
above?
Just understand that most people, reading code like +[FooDictionary
newDict], would reasonably assume that this actually creates an
instance of FooDictionary.
But that is NOT how the code looks, which can be seen from my
original post, it looks like this:
Class myClass = [someClass class];
NSDictionarymyDict;
myDict = [myClass newDict];
Why would you think newDict returned a myClass object?
If you saw:
Class myClass = [NSDictionary class];
SomeObject* myObj;
myObj = [myClass newObj];
Would you think that newObj was returning an NSDictionary?
If so, why?
All the Best
Dave
___
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
Re: Another Gnarly Objective-C Question!
On Mar 12, 2013, at 2:08 AM, Graham Cox graham@bigpond.com wrote: A class method is just an instance method of the class object. No magic at all. So all this confusion you've caused yourself about [super class] and so on is wholly unnecessary to correctly use class methods. Agreed. This can be confusing to people coming from less-dynamic languages like C++ or Java. * In Objective-C a class is an object. You can think of it as a singleton — so when “Foo” appears as the receiver in an expression (like “[Foo alloc]”) it means the singleton object that represents the class Foo. * Class (“+”-prefixed) methods are instance methods of the class object. * “super” works as it does for instances, so in the implementation of +[Subclass foo], calling “[super foo]” will invoke the superclass’s implementation of +foo, if it has one.* * Calling +class on a class object is a no-op, because it’s already a class. The only reason this is useful is it allows you to say “[Foo class]” to get the class object of Foo, because for some syntactic reason just saying “Foo” doesn’t work. —Jens * The details of this are really weird and involve the existence of metaclasses, which have an even weirder relationship to each other, but fortunately you almost never have to think about this in Objective-C. It’s much more explicit in Smalltalk-80, where these concepts originate. Look up “metaclass” on Wikipedia if you want the gory details. ___ 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: Objective-C Question
On Mar 12, 2013, at 9:44 AM, John McCall rjmcc...@apple.com wrote: However, that wouldn't be an idiomatic implementation. The usual expectation is that allocating methods, like +new methods, construct an object *of type self* (at least). Are you just quibbling about the prefix “new-“? The specific method +new is expected to create a new instance of the receiving class, yes. There may be a convention (I can’t remember?) that class methods prefixed “new-” are intended to do the same. However, it’s hardly unusual to have a class method that instantiates and returns some other kind of object. Dave’s use case of a dictionary that describes metadata about the class seems reasonable. This is why I was talking about instance methods and fields: because, generally, people introduce new classes because they expect to create instances of them, and [[self superclass] newDict] bypasses that in a way that might not be obvious. I don’t see the problem here. Presumably the class is going to be instantiated at some point, but the code Dave is working with is operating on metadata about the class, so only class methods are involved in it. —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: Objective-C Question
On 12 Mar 2013, at 18:50, Jens Alfke wrote:
On Mar 12, 2013, at 9:44 AM, John McCall rjmcc...@apple.com wrote:
However, that wouldn't be an idiomatic implementation. The usual
expectation is that allocating methods, like +new methods,
construct an object *of type self* (at least).
Are you just quibbling about the prefix “new-“? The specific method
+new is expected to create a new instance of the receiving class,
yes. There may be a convention (I can’t remember?) that class
methods prefixed “new-” are intended to do the same.
I'm not sure if its a convention, but it does make sense, for
instance, I've been code like this before.
-(NSDictionary) newDictForSomethingWithInfo:(Info*) theInfo
{
// returns an dictionary allocated and initialized
}
somewhere else in the same class:
myDict = [self newDictForSomethingWithInfo:myInfo];
Which keeps the compiler/analyzer happy in non-ARC and works ok with
ARC enabled. If this isn't a convention then it should be IMO unless
there is another prefix used? allocDict would work, but this is as
bad or as good as new in this respect.
However, it’s hardly unusual to have a class method that
instantiates and returns some other kind of object. Dave’s use case
of a dictionary that describes metadata about the class seems
reasonable.
This is why I was talking about instance methods and fields:
because, generally, people introduce new classes because they
expect to create instances of them, and [[self superclass]
newDict] bypasses that in a way that might not be obvious.
I don’t see the problem here. Presumably the class is going to be
instantiated at some point,
This is the language I used, and is another source of confusion on
this. Apparently the language technically should be:
Presumably the class is going to be to be used to instantiate an
Object at some point which keeps everyone happy? lol
but the code Dave is working with is operating on metadata about
the class, so only class methods are involved in it.
Exactly!
All the Best
Dave
___
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: Objective-C Question
Le 12 mars 2013 à 20:15, Dave d...@looktowindward.com a écrit :
On 12 Mar 2013, at 18:50, Jens Alfke wrote:
On Mar 12, 2013, at 9:44 AM, John McCall rjmcc...@apple.com wrote:
However, that wouldn't be an idiomatic implementation. The usual
expectation is that allocating methods, like +new methods, construct an
object *of type self* (at least).
Are you just quibbling about the prefix “new-“? The specific method +new is
expected to create a new instance of the receiving class, yes. There may be
a convention (I can’t remember?) that class methods prefixed “new-” are
intended to do the same.
I'm not sure if its a convention, but it does make sense, for instance, I've
been code like this before.
-(NSDictionary) newDictForSomethingWithInfo:(Info*) theInfo
{
// returns an dictionary allocated and initialized
}
somewhere else in the same class:
myDict = [self newDictForSomethingWithInfo:myInfo];
Which keeps the compiler/analyzer happy in non-ARC and works ok with ARC
enabled. If this isn't a convention then it should be IMO unless there is
another prefix used? allocDict would work, but this is as bad or as good as
new in this respect.
According to the clang manual:
http://clang.llvm.org/docs/LanguageExtensions.html#related-result-types
The related result type can also be inferred for some methods. To determine
whether a method has an inferred related result type, the first word in the
camel-case selector (e.g., “init” in “initWithObjects”) is considered, and the
method will have a related result type if its return type is compatible with
the type of its class and if:
• the first word is “alloc” or “new”, and the method is a class method,
or
• the first word is “autorelease”, “init”, “retain”, or “self”, and the
method is an instance method.
So new prefixed class method should return an instance of the calling class,
but instance methods are just required to returned a retained object of any
kind.
-- 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: Objective-C Question
On 12 Mar 2013, at 19:38, Jean-Daniel Dupas wrote:
Le 12 mars 2013 à 20:15, Dave d...@looktowindward.com a écrit :
On 12 Mar 2013, at 18:50, Jens Alfke wrote:
On Mar 12, 2013, at 9:44 AM, John McCall rjmcc...@apple.com wrote:
However, that wouldn't be an idiomatic implementation. The
usual expectation is that allocating methods, like +new methods,
construct an object *of type self* (at least).
Are you just quibbling about the prefix “new-“? The specific
method +new is expected to create a new instance of the receiving
class, yes. There may be a convention (I can’t remember?) that
class methods prefixed “new-” are intended to do the same.
I'm not sure if its a convention, but it does make sense, for
instance, I've been code like this before.
-(NSDictionary) newDictForSomethingWithInfo:(Info*) theInfo
{
// returns an dictionary allocated and initialized
}
somewhere else in the same class:
myDict = [self newDictForSomethingWithInfo:myInfo];
Which keeps the compiler/analyzer happy in non-ARC and works ok
with ARC enabled. If this isn't a convention then it should be IMO
unless there is another prefix used? allocDict would work, but
this is as bad or as good as new in this respect.
According to the clang manual: http://clang.llvm.org/docs/
LanguageExtensions.html#related-result-types
The related result type can also be inferred for some methods. To
determine whether a method has an inferred related result type, the
first word in the camel-case selector (e.g., “init” in
“initWithObjects”) is considered, and the method will have a
related result type if its return type is compatible with the type
of its class and if if its return type is compatible with the type
of its class and if:
That's true (incompatible result type) in this case and in most
cases I've seen, so ok to use newDict in this case.
• the first word is “alloc” or “new”, and the method is a class
method, or
• the first word is “autorelease”, “init”, “retain”, or “self”,
and the method is an instance method.
So new prefixed class method should return an instance of the
calling class, but instance methods are just required to returned a
retained object of any kind.
Well, that's one rule that sucks and I've seen it disobeyed many
times. If that is the case, then how do you signal to the compiler/
analyzer that you are returning a retained object? Unless there is
another prefix to use, they I am going to continue ignore it too!
All the Best
Dave
PS.
This lets eveyone off the hook:
if its return type is compatible with the type of its class and if:
Just seen this:
That's true (incompatible result type) in this case and in most
cases I've seen, so ok to use newDict in this case.
___
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
Snapping windows while moving
What's the best way to go about snapping windows to screens and other windows while dragging the window? I've tried catching it in windowDidMove (only when the mouse is down), but that isn't called for every single movement of the mouse. I haven't been able to find anything equivalent to the old kEventWindowBoundsChanging with kWindowBoundsChangeUserDrag, which was exactly what was needed to do this. It needs to be available in 10.7 on up. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: Snapping windows while moving
On Mar 12, 2013, at 1:11 PM, Steve Mills wrote: What's the best way to go about snapping windows to screens and other windows while dragging the window? I've tried catching it in windowDidMove (only when the mouse is down), but that isn't called for every single movement of the mouse. I haven't been able to find anything equivalent to the old kEventWindowBoundsChanging with kWindowBoundsChangeUserDrag, which was exactly what was needed to do this. It needs to be available in 10.7 on up. Pretty sure you want to subclass and override constrainFrameRect:toScreen: but I can't recall off the top of my head whether this is called live for every movement. I believe it is. -- Seth Willits ___ 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: Snapping windows while moving
On Mar 12, 2013, at 15:29:53, Seth Willits sli...@araelium.com wrote: Pretty sure you want to subclass and override constrainFrameRect:toScreen: but I can't recall off the top of my head whether this is called live for every movement. I believe it is. Nope. It only seems to be called when the window is being created and *after* the mouse has been released during a move. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: Objective-C Question
On 13/03/2013, at 2:41 AM, Dave d...@looktowindward.com wrote: So, what is it? Wind up merchant or Moron? I don't think there's any need for this. If I caused offence, it was unintended (I sometimes have trouble anticipating how others might receive statements I make, that's just something I have to live with). The further discussion doesn't really convince me that you've really understood it, but if you have, great. Personally I have no stake in whether you succeed or not, so if you choose to ignore advice or insult the adviser, it makes no difference to me. --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
Re: Objective-C Question
On 13/03/2013, at 6:53 AM, Dave d...@looktowindward.com wrote: If that is the case, then how do you signal to the compiler/analyzer that you are returning a retained object? In general you shouldn't return a retained object (unless it's temporarily retained and will be autoreleased of course). If you are routinely doing this then your design is flawed. The reason it's hard to signal to the compiler that you're returning a retained object is that you shouldn't be doing it. When you have to do it, use the word 'new' in the method. Unless there is another prefix to use, they I am going to continue ignore it too! Again, no offence intended but when a person doesn't follow a rule because they think it doesn't apply to them, it's just a sign of inexperience and/or lack of understanding. Sorry, but there 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
Re: Another Gnarly Objective-C Question!
On 12 Mar 2013, at 2:08 AM, Graham Cox wrote: in a + method, [self class] === self. Once you've got that, you've got it. You're overthinking this. A class method is just an instance method of the class object. No magic at all. So all this confusion you've caused yourself about [super class] and so on is wholly unnecessary to correctly use class methods. To be very slightly pedantic, the only magic here is 'super' --- sending a message to super (which you can only do from a method implementation) is special syntax that searches for the method starting with the implementation's class's superclass, rather than at the receiver's actual class. Everything else is non-magic. (In general, that's been one of the strengths of ObjC: very little magic.) But since there's only one relevant implementation of +class (on NSObject), and it returns self, and self is the same object regardless of how the method implementation was found, [self class] and [super class] are equivalent. ___ 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
