Re: A Stack of Editors
Keary, You made me question what I thought I knew, so I went back and changed my method returning the number of rows (views) to log its operation so I could make sure it was returning 16 as it should. And of course I found it was returning 0. What I previously didn’t know is that the table loads its data as soon as you set the data source property. It never occurred to me the table data would be loaded before execution of windowDidLoadFromNib ever finished, so I was creating stuff in the wrong order. Once I rearranged that function body to set the table’s delegate and data source last, after creating everything else including all the demo views, everything worked as expected. So thanks for the good advice! -- Charles On Sunday, October 5, 2014 at 9:51, Keary Suska wrote: > On Oct 4, 2014, at 8:49 PM, Charles Jenkins (mailto:cejw...@gmail.com)> wrote: > > Sometimes the most obvious issue is the culprit--is the delegate outlet set? > If so, are any other delegate methods being called? Note that you might not > get a call for certain delegate methods if there is no data to show--i.e. if > the table view doesn't otherwise believe it has data to show, either via > bindings or data source methods. ___ 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
Obtaining class of key at runtime
I have a class with below interface:
@interface MyData : NSObject
@property (readwrite, strong) NSString *urlToParse;
@property (readwrite, strong) MappingElement *titleElement;
- (instancetype)initWithPlist:(NSString *)plistPath;
Its implementation is like this:
- (instancetype)initWithPlist:(NSString *)plistPath
{
if (self = [super init]) {
NSDictionary *plistData = [[NSDictionary alloc]
initWithContentsOfFile:plistPath];
[self setValuesForKeysWithDictionary:plistData];
}
return self;
}
#pragma mark KVC related methods
- (void)setValue:(id)value forKey:(NSString *)key
{
NSLog(@"key class: ",[key class]); // it is printing nil, prints
correct value if key is initialized in init method
}
Now there are two scenarios:
Scenario 1: Do not initialize instance variables in initWithPlist method
In this case if I try to log class of key in setValue:forKey method,
it prints nil
Scenario 2: Initialize instance variables in initWithPlist method
In this case if I try to log class of key in setValue:forKey method,
it prints NSString and then MappingElement.
Is there any way to achieve the same result in 'Scenario 1', may be by
using any API from objective c runtime?
Kindly suggest.
___
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: Obtaining class of key at runtime
> On Oct 6, 2014, at 7:43 AM, Devarshi Kulshreshtha > wrote: > > Scenario 1: Do not initialize instance variables in initWithPlist method > > In this case if I try to log class of key in setValue:forKey method, > it prints nil That doesn't make any sense — it's illegal to pass a nil key to setValue:ForKey:. Who is calling this method? > Is there any way to achieve the same result in 'Scenario 1', may be by > using any API from objective c runtime? Again, who is supposed to be calling setValue:forKey: if your init method isn't calling it? And why do you want to know the class of the key if it's clearly declared as NSString already? It's always going to be a string. —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: Obtaining class of key at runtime
Scenario 1: Do not initialize instance variables in initWithPlist method
>
> In this case if I try to log class of key in setValue:forKey method,
> it prints nil
>
>
> That doesn't make any sense — it's illegal to pass a nil key to
> setValue:ForKey:. Who is calling this method?
This method is automatically called, since I am invoking
setValuesForKeysWithDictionary: in init method.
> Is there any way to achieve the same result in 'Scenario 1', may be by
> using any API from objective c runtime?
>
>
> Again, who is supposed to be calling setValue:forKey: if your init method
> isn't calling it?
> And why do you want to know the class of the key if it's clearly declared as
> NSString already? It's always going to be a string.
Actually I am indirectly trying to identify class of property, through
key parameter, the NSLog statement added within - setValue: forKey: is
wrong, I was trying to do something like this:
- (void)setValue:(id)value forKey:(NSString *)key
{
NSLog(@"key class: ",[[self valueForKey:key] class]); // it is
printing nil, prints correct value if key is initialized in init
method
}
___
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: Obtaining class of key at runtime
> On Oct 6, 2014, at 10:12 AM, Devarshi Kulshreshtha
> wrote:
>
> Scenario 1: Do not initialize instance variables in initWithPlist method
>
>>
>> In this case if I try to log class of key in setValue:forKey method,
>> it prints nil
>>
>>
>> That doesn't make any sense — it's illegal to pass a nil key to
>> setValue:ForKey:. Who is calling this method?
>
> This method is automatically called, since I am invoking
> setValuesForKeysWithDictionary: in init method.
>
>> Is there any way to achieve the same result in 'Scenario 1', may be by
>> using any API from objective c runtime?
>>
>>
>> Again, who is supposed to be calling setValue:forKey: if your init method
>> isn't calling it?
>> And why do you want to know the class of the key if it's clearly declared as
>> NSString already? It's always going to be a string.
>
> Actually I am indirectly trying to identify class of property, through
> key parameter, the NSLog statement added within - setValue: forKey: is
> wrong, I was trying to do something like this:
>
> - (void)setValue:(id)value forKey:(NSString *)key
> {
>NSLog(@"key class: ",[[self valueForKey:key] class]); // it is
> printing nil, prints correct value if key is initialized in init
> method
> }
Assuming your values are objects, then of course this is going to return nil
during -init*, the value hasn’t been set yet.
The ‘value’ passed is the incoming value, and you would probably want to check
its class instead, if you do this at all.
But honestly this entire exercise seems to be exactly what NSCoding is designed
for. Why not use that instead?
>
> ___
>
> 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/david.duncan%40apple.com
>
> This email sent to david.dun...@apple.com
--
David Duncan
___
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
Photo Extension and Orientation Change
I'm working on a app with a photo extension written in Swift. I'm trying to handle rotations intelligently in both the app and the extension. In the app, like an obedient developer, I implemented viewWillTransitionToSize:withTransitionCoordinator: to handle rotations. Everything works beautifully. To support iOS 7 devices, I overwrote the old willRotateToInterfaceOrientation, willAnimateRotationToInterfaceOrientation, and didRotateToInterfaceOrientation. That also works beautifully. Well, in the photo extension on iOS 8 I used the exact same superclass that implements the exact same orientation change methods. ViewWillTransition... is not called at all, but the deprecated methods are being called. So, what am I doing wrong that a component of iOS 8 is calling methods that were deprecated at the same time that it was first introduced, but is not calling the method that I am supposed to use with the latest version. I should mention that there is some subtle stuff in my rotation code that prevents me from using the deprecated methods correctly in iOS 8, so I can't just fall back on them knowing that they are in there in both versions of the OS. Any insight on this? Has anyone else tried to use viewWillTransition... in a photo extension specifically (Googling indicates that it may work in other extension types, such as Today)? -- Daniel Blakemore Pixio Software ___ 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
