Date   

Re: How to Correctly Resize Views with Manual Layout

Dave
 

HI,

Just a quick message to say I’ve now got it working well using resizeWithOldSuperviewSize.

Wanted to say thanks to everyone that helped.

All the Best
Dave

On 26 Sep 2018, at 18:16, Dave <dave@...> wrote:

Hi,

Ok, yes, that was a typo, I released it needed to be after I posted, I was about to post that I’ve I’ve actually concocted a test app got it working using the bounds rect as a base.

One thing I’ve noticed is that NSTextField doesn’t seem to Jive with isFlipped = YES, which seems odd and slightly annoying, anyone know why?

Thanks a lot.

All the Best
Dave


On 26 Sep 2018, at 18:03, Andy Lee via Groups.Io <aglee@...> wrote:

Two quick comments:

- You want to set the subview's frame relative to the superview's bounds, not its frame.
- You might want to experiment with a scratch app before making a lot of code changes at once in your existing app.  Or, if possible, make your code changes incrementally, relaunch the app, fiddle with window size, and see if the changes look right.

--Andy

On Wed, Sep 26, 2018, at 8:55 AM, Dave wrote:
Hi All,

I’ve started move over to using the correct Manual Layout Methods as per 
my recent posts. The methods are:

resizeWithOldSuperviewSize


WindowTrackerView .view Property
SubviewA

All views have isFlipped override and returning YES.


Given that I want SubviewA to be inset 10 pixels from the top, left and 
right of the Superview  and bottom to be the same as the superview, what 
code do I need to write?


For instance would the following work:

-(void) resizeWithOldSuperviewSize:(NSSize) theOldSuperviewSize
{
NSRect myRect;

[super resizeWithOldSuperviewSize: theOldSuperviewSize];

myRect.origin = self.superview.frame.origin.x + 10;
myRect.origin = self.superview.frame.origin.y + 10;
myRect.size.width = self.superview.frame.size.width - (10 *2);
myRect.size.height = self.superview.frame.size.height - 10;
self.frame = myRect;
}

I just want to be sure I’m on the right track before I start changing 
loads of code.

If anyone knows of a working example of using these methods, I’d be 
really grateful if they could point me to it!

Thanks in advance for any help.

All the Best
Dave











Re: NSMeasurementFormatter reversed

Gerriet M. Denkmann
 

On 26 Sep 2018, at 22:29, James Walker <list2@...> wrote:



On Sep 25, 2018, at 7:05 PM, Gerriet M. Denkmann <g@...> wrote:

NSMeasurementFormatter is a magical tool which converts all stuff just into the right form the user wants to see.

But what about the other way round?

I have a TextField labeled “Desired Temperature” the user enters “83.4” - what does the user want?
Boiling hot (using Celsius) or comfortably warm (Fahrenheit)?
Typing

defaults find Temperature

at the command line produces

Found 1 keys in domain 'Apple Global Domain': {
AppleTemperatureUnit = Fahrenheit;
}
Excellent find! Thanks a lot!

There seem to be 3 ways to get this info:

NSString *temp1 = [NSUserDefaults.standardUserDefaults stringForKey: @"AppleTemperatureUnit"];

NSString *temp2 = [ NSLocale.currentLocale objectForKey: @"kCFLocaleTemperatureUnitKey"];

FOUNDATION_EXPORT NSLocaleKey const NSLocaleTemperatureUnit;
NSString *temp3 = [ NSLocale.currentLocale objectForKey: NSLocaleTemperatureUnit];

Probably the first one (the one you found) is the best, i.e. most likely to work in future OS versions.

All work on macOS and iOS.
The first one returns nil in the Simulator

Gerriet.


Re: How to Correctly Resize Views with Manual Layout

Dave
 

Hi,

Ok, yes, that was a typo, I released it needed to be after I posted, I was about to post that I’ve I’ve actually concocted a test app got it working using the bounds rect as a base.

One thing I’ve noticed is that NSTextField doesn’t seem to Jive with isFlipped = YES, which seems odd and slightly annoying, anyone know why?

Thanks a lot.

All the Best
Dave

On 26 Sep 2018, at 18:03, Andy Lee via Groups.Io <aglee@...> wrote:

Two quick comments:

- You want to set the subview's frame relative to the superview's bounds, not its frame.
- You might want to experiment with a scratch app before making a lot of code changes at once in your existing app. Or, if possible, make your code changes incrementally, relaunch the app, fiddle with window size, and see if the changes look right.

--Andy

On Wed, Sep 26, 2018, at 8:55 AM, Dave wrote:
Hi All,

I’ve started move over to using the correct Manual Layout Methods as per
my recent posts. The methods are:

resizeWithOldSuperviewSize


WindowTrackerView .view Property
SubviewA

All views have isFlipped override and returning YES.


Given that I want SubviewA to be inset 10 pixels from the top, left and
right of the Superview and bottom to be the same as the superview, what
code do I need to write?


For instance would the following work:

-(void) resizeWithOldSuperviewSize:(NSSize) theOldSuperviewSize
{
NSRect myRect;

[super resizeWithOldSuperviewSize: theOldSuperviewSize];

myRect.origin = self.superview.frame.origin.x + 10;
myRect.origin = self.superview.frame.origin.y + 10;
myRect.size.width = self.superview.frame.size.width - (10 *2);
myRect.size.height = self.superview.frame.size.height - 10;
self.frame = myRect;
}

I just want to be sure I’m on the right track before I start changing
loads of code.

If anyone knows of a working example of using these methods, I’d be
really grateful if they could point me to it!

Thanks in advance for any help.

All the Best
Dave





Re: How to Correctly Resize Views with Manual Layout

Andy Lee
 

Two quick comments:

- You want to set the subview's frame relative to the superview's bounds, not its frame.
- You might want to experiment with a scratch app before making a lot of code changes at once in your existing app. Or, if possible, make your code changes incrementally, relaunch the app, fiddle with window size, and see if the changes look right.

--Andy

On Wed, Sep 26, 2018, at 8:55 AM, Dave wrote:
Hi All,

I’ve started move over to using the correct Manual Layout Methods as per
my recent posts. The methods are:

resizeWithOldSuperviewSize


WindowTrackerView .view Property
SubviewA

All views have isFlipped override and returning YES.


Given that I want SubviewA to be inset 10 pixels from the top, left and
right of the Superview and bottom to be the same as the superview, what
code do I need to write?


For instance would the following work:

-(void) resizeWithOldSuperviewSize:(NSSize) theOldSuperviewSize
{
NSRect myRect;

[super resizeWithOldSuperviewSize: theOldSuperviewSize];

myRect.origin = self.superview.frame.origin.x + 10;
myRect.origin = self.superview.frame.origin.y + 10;
myRect.size.width = self.superview.frame.size.width - (10 *2);
myRect.size.height = self.superview.frame.size.height - 10;
self.frame = myRect;
}

I just want to be sure I’m on the right track before I start changing
loads of code.

If anyone knows of a working example of using these methods, I’d be
really grateful if they could point me to it!

Thanks in advance for any help.

All the Best
Dave




Re: NSMeasurementFormatter reversed

James Walker
 

On Sep 25, 2018, at 7:05 PM, Gerriet M. Denkmann <g@...> wrote:

NSMeasurementFormatter is a magical tool which converts all stuff just into the right form the user wants to see.

But what about the other way round?

I have a TextField labeled “Desired Temperature” the user enters “83.4” - what does the user want?
Boiling hot (using Celsius) or comfortably warm (Fahrenheit)?
Typing

defaults find Temperature

at the command line produces

Found 1 keys in domain 'Apple Global Domain': {
AppleTemperatureUnit = Fahrenheit;
}

I’m not sure if you can get that with NSUserDefaults, maybe you have to use CFPreferences.


Re: UITableViewCell with UITextField

Gerriet M. Denkmann
 

On 26 Sep 2018, at 20:21, Alex Zavatone via Groups.Io <zav@...> wrote:

Try adding nonatomic and strong to your property.

@property (nonatomic, strong) IBOutlet UITextField *textField;

Also, did you set the XIB in the storyboard to your subclass and drag the UITextField to your property?
I found a solution without an extra xib file: just using a Prototype Cell in the tableView.

Class: MyTableViewCell
Style: Custom
Identifier: “Cell with TextField”

The Prototype Cell has in it’s Connections Inspector an Outlet named “textField”;
Control-Drag from the empty circle at the right to the UITextField.

This Control-Dragging from the Connections Inspector was a new trick (for me). Took me a while to find this.



On Sep 26, 2018, at 4:25 AM, Gerriet M. Denkmann <g@...> wrote:



On 26 Sep 2018, at 14:30, Alex Zavatone via Groups.Io <zav@...> wrote:

Use an XIB for the subclass of tableViewCell, create a UIOutlet property for the UITextField, assign the subclass to the XIB’s class and wire up the UIOutlet property to the UITextField. Don’t forget to give the UITableViewCell an Identifier keyword.

Make sure to set the tableView to register the subclass for the cell if needed. I can dig up my working source, but it will be about 8 hours.

@interface TextTableCell : UITableViewCell
@property IBOutlet UITextField *textField;
@end


TableCellView.xib

File’s Owner = TextTableCell
Outlet textField = UITextField

View UIView contains
TextTableCell
Content View
UITextField


MyTableViewController

- (void)viewDidLoad
{
[super viewDidLoad];
UINib *nib = [ UINib nibWithNibName: @"TableCellView" bundle: nil ];
[ self.tableView registerNib: nib forCellReuseIdentifier: kTextCell ];
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;
{
NSLog(@"%s will dequeueReusableCellWithIdentifier: \"%@\"",__FUNCTION__, cellId);
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier: cellId forIndexPath: indexPath];
}


Result:

[tableView:cellForRowAtIndexPath:] will dequeueReusableCellWithIdentifier: "Cell with TextField"
*** Terminating app due to uncaught exception ‘NSUnknownKeyException', reason: '[<NSObject 0x6000032aeb80> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key textField.'

0 CoreFoundation 0x000000010251129b __exceptionPreprocess + 331
1 libobjc.A.dylib 0x0000000101a51735 objc_exception_throw + 48
2 CoreFoundation 0x0000000102510e09 -[NSException raise] + 9
3 Foundation 0x000000010147e0b4 -[NSObject(NSKeyValueCoding) setValue:forKey:] + 292
4 UIKitCore 0x0000000105176ada -[UIRuntimeOutletConnection connect] + 109
5 CoreFoundation 0x00000001024fcddd -[NSArray makeObjectsPerformSelector:] + 317
6 UIKitCore 0x00000001050906d1 -[UINib instantiateWithOwner:options:] + 1814
7 UIKitCore 0x00000001052ded16 -[UITableView _dequeueReusableViewOfType:withIdentifier:] + 611


I guess my TableCellView.xib is not quite right (or rather: absolutely messed up).
How to fix this?

Gerriet.






Re: UITableViewCell with UITextField

Alex Zavatone
 

Try adding nonatomic and strong to your property.

@property (nonatomic, strong) IBOutlet UITextField *textField;

Also, did you set the XIB in the storyboard to your subclass and drag the UITextField to your property?

On Sep 26, 2018, at 4:25 AM, Gerriet M. Denkmann <g@...> wrote:



On 26 Sep 2018, at 14:30, Alex Zavatone via Groups.Io <zav@...> wrote:

Use an XIB for the subclass of tableViewCell, create a UIOutlet property for the UITextField, assign the subclass to the XIB’s class and wire up the UIOutlet property to the UITextField. Don’t forget to give the UITableViewCell an Identifier keyword.

Make sure to set the tableView to register the subclass for the cell if needed. I can dig up my working source, but it will be about 8 hours.

@interface TextTableCell : UITableViewCell
@property IBOutlet UITextField *textField;
@end


TableCellView.xib

File’s Owner = TextTableCell
Outlet textField = UITextField

View UIView contains
TextTableCell
Content View
UITextField


MyTableViewController

- (void)viewDidLoad
{
[super viewDidLoad];
UINib *nib = [ UINib nibWithNibName: @"TableCellView" bundle: nil ];
[ self.tableView registerNib: nib forCellReuseIdentifier: kTextCell ];
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;
{
NSLog(@"%s will dequeueReusableCellWithIdentifier: \"%@\"",__FUNCTION__, cellId);
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier: cellId forIndexPath: indexPath];
}


Result:

[tableView:cellForRowAtIndexPath:] will dequeueReusableCellWithIdentifier: "Cell with TextField"
*** Terminating app due to uncaught exception ‘NSUnknownKeyException', reason: '[<NSObject 0x6000032aeb80> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key textField.'

0 CoreFoundation 0x000000010251129b __exceptionPreprocess + 331
1 libobjc.A.dylib 0x0000000101a51735 objc_exception_throw + 48
2 CoreFoundation 0x0000000102510e09 -[NSException raise] + 9
3 Foundation 0x000000010147e0b4 -[NSObject(NSKeyValueCoding) setValue:forKey:] + 292
4 UIKitCore 0x0000000105176ada -[UIRuntimeOutletConnection connect] + 109
5 CoreFoundation 0x00000001024fcddd -[NSArray makeObjectsPerformSelector:] + 317
6 UIKitCore 0x00000001050906d1 -[UINib instantiateWithOwner:options:] + 1814
7 UIKitCore 0x00000001052ded16 -[UITableView _dequeueReusableViewOfType:withIdentifier:] + 611


I guess my TableCellView.xib is not quite right (or rather: absolutely messed up).
How to fix this?

Gerriet.




How to Correctly Resize Views with Manual Layout

Dave
 

Hi All,

I’ve started move over to using the correct Manual Layout Methods as per my recent posts. The methods are:

resizeWithOldSuperviewSize


WindowTrackerView .view Property
SubviewA

All views have isFlipped override and returning YES.


Given that I want SubviewA to be inset 10 pixels from the top, left and right of the Superview and bottom to be the same as the superview, what code do I need to write?


For instance would the following work:

-(void) resizeWithOldSuperviewSize:(NSSize) theOldSuperviewSize
{
NSRect myRect;

[super resizeWithOldSuperviewSize: theOldSuperviewSize];

myRect.origin = self.superview.frame.origin.x + 10;
myRect.origin = self.superview.frame.origin.y + 10;
myRect.size.width = self.superview.frame.size.width - (10 *2);
myRect.size.height = self.superview.frame.size.height - 10;
self.frame = myRect;
}

I just want to be sure I’m on the right track before I start changing loads of code.

If anyone knows of a working example of using these methods, I’d be really grateful if they could point me to it!

Thanks in advance for any help.

All the Best
Dave


Re: UITableViewCell with UITextField

Gerriet M. Denkmann
 

On 26 Sep 2018, at 14:30, Alex Zavatone via Groups.Io <zav@...> wrote:

Use an XIB for the subclass of tableViewCell, create a UIOutlet property for the UITextField, assign the subclass to the XIB’s class and wire up the UIOutlet property to the UITextField. Don’t forget to give the UITableViewCell an Identifier keyword.

Make sure to set the tableView to register the subclass for the cell if needed. I can dig up my working source, but it will be about 8 hours.

@interface TextTableCell : UITableViewCell
@property IBOutlet UITextField *textField;
@end


TableCellView.xib

File’s Owner = TextTableCell
Outlet textField = UITextField

View UIView contains
TextTableCell
Content View
UITextField


MyTableViewController

- (void)viewDidLoad
{
[super viewDidLoad];
UINib *nib = [ UINib nibWithNibName: @"TableCellView" bundle: nil ];
[ self.tableView registerNib: nib forCellReuseIdentifier: kTextCell ];
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;
{
NSLog(@"%s will dequeueReusableCellWithIdentifier: \"%@\"",__FUNCTION__, cellId);
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier: cellId forIndexPath: indexPath];
}


Result:

[tableView:cellForRowAtIndexPath:] will dequeueReusableCellWithIdentifier: "Cell with TextField"
*** Terminating app due to uncaught exception ‘NSUnknownKeyException', reason: '[<NSObject 0x6000032aeb80> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key textField.'

0 CoreFoundation 0x000000010251129b __exceptionPreprocess + 331
1 libobjc.A.dylib 0x0000000101a51735 objc_exception_throw + 48
2 CoreFoundation 0x0000000102510e09 -[NSException raise] + 9
3 Foundation 0x000000010147e0b4 -[NSObject(NSKeyValueCoding) setValue:forKey:] + 292
4 UIKitCore 0x0000000105176ada -[UIRuntimeOutletConnection connect] + 109
5 CoreFoundation 0x00000001024fcddd -[NSArray makeObjectsPerformSelector:] + 317
6 UIKitCore 0x00000001050906d1 -[UINib instantiateWithOwner:options:] + 1814
7 UIKitCore 0x00000001052ded16 -[UITableView _dequeueReusableViewOfType:withIdentifier:] + 611


I guess my TableCellView.xib is not quite right (or rather: absolutely messed up).
How to fix this?

Gerriet.


Re: UITableViewCell with UITextField

Alex Zavatone
 

Use an XIB for the subclass of tableViewCell, create a UIOutlet property for the UITextField, assign the subclass to the XIB’s class and wire up the UIOutlet property to the UITextField. Don’t forget to give the UITableViewCell an Identifier keyword.

Make sure to set the tableView to register the subclass for the cell if needed. I can dig up my working source, but it will be about 8 hours.

On Sep 26, 2018, at 2:25 AM, Gerriet M. Denkmann <g@...> wrote:

iOS 12, Xcode 10

I have a subclass of UITableViewController.

The UITableView should use UITableViewCells with UITextFields (for data entry).

So I created MyTableViewCellWithTextField which has:
@property IBOutlet UITextField *textField;
Changed the class of the Prototype Cell to MyTableViewCellWithTextField
added a UITextField to the ContentView and tried to connect the outlet to this textField.

But no luck.

So I have to do:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;
{
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier: cellId forIndexPath: indexPath];

UITextField *badHack = cell.contentView.subviews.firstObject;
badHack.keyboardType = …
badHack. placeholder = …
badHack. text = …
}

But I have a nagging feeling that this is *not* quite the right way.

What should I do instead ?

Gerriet.




UITableViewCell with UITextField

Gerriet M. Denkmann
 

iOS 12, Xcode 10

I have a subclass of UITableViewController.

The UITableView should use UITableViewCells with UITextFields (for data entry).

So I created MyTableViewCellWithTextField which has:
@property IBOutlet UITextField *textField;
Changed the class of the Prototype Cell to MyTableViewCellWithTextField
added a UITextField to the ContentView and tried to connect the outlet to this textField.

But no luck.

So I have to do:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;
{
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier: cellId forIndexPath: indexPath];

UITextField *badHack = cell.contentView.subviews.firstObject;
badHack.keyboardType = …
badHack. placeholder = …
badHack. text = …
}

But I have a nagging feeling that this is *not* quite the right way.

What should I do instead ?

Gerriet.


NSMeasurementFormatter reversed

Gerriet M. Denkmann
 

NSMeasurementFormatter is a magical tool which converts all stuff just into the right form the user wants to see.

But what about the other way round?

I have a TextField labeled “Desired Temperature” the user enters “83.4” - what does the user want?
Boiling hot (using Celsius) or comfortably warm (Fahrenheit)?

So my app does:

if ( NSLocale.currentLocale.usesCelsius ) ….

The problem: I can’t find such a property.

Or:
NSMeasurement *raw = [measurementFormatter measurementFromString: “83.4” for: NSUnitTemperature];
NSMeasurement *m = [raw measurementByConvertingToUnit: NSUnitTemperature.celsius];

No luck either.

So:

NSMeasurement *trySome = [[NSMeasurement alloc] initWithDoubleValue: 83.4 unit: NSUnitTemperature.celsius ];
NSString *trialResult = [measurementFormatter stringFromMeasurement: trySome];

BOOL usesCelsius = …trialResult resembles somehow “83.4” …;
This is rather error prone; what if the actual user-input was 83.399999999 ?

There clearly must be a much better way.

Gerriet.


Re: Temperatur etc. from Locale

Gerriet M. Denkmann
 

On 24 Sep 2018, at 20:41, Andy Lee via Groups.Io <aglee@...> wrote:

I haven’t played with it myself, but maybe NSMeasurementFormatter?
Excellent. Just what I needed.

Contrary to my expectations Celsius/Fahrenheit is *not* part of Locale, but set in System Preferences → Language & Region → Temperature.

I can’t find “rounds per minute”, but probably I can make my own from NSUnitAngle.revolutions and
NSUnitDuration.minutes.

fr_FR "2,6 km" "2,6 km" "2,6 kilomètres"
de_DE "2,6 km" "2,6 km" "2,6 Kilometer"
en_IE "2.6km" "2.6 km" "2.6 kilometres"
zh_ZH "2.6公里" "2.6公里" "2.6公里"
th_TH "2.6กม." "2.6 กม." "2.6 กิโลเมตร"
en_US “1.6mi" "1.6 mi" "1.6 miles"

Kind regards,

Gerriet.


Re: Temperatur etc. from Locale

Andy Lee
 

I haven't played with it myself, but maybe NSMeasurementFormatter?

--Andy

On Sep 24, 2018, at 2:35 AM, Gerriet M. Denkmann <g@...> wrote:

I want to know, given a certain NSLocale (e.g. NSLocale.currentLocale), how to represent:

Temperature (K, °C or whatever)
Distance (km, miles, furlongs, lightyears, … )
Speed (m/sec, km/h, …)
Frequency (rpm, U/min, Hz, … )

The only thing I did find out is that my locale uses NSLocaleMeasurementSystem = Metric .

Is the Locale the right place to look for this information?

There is Unicode Common Locale Data Repository, which claims to be used by “Apple (macOS, iOS, watchOS, tvOS, and several applications; Apple Mobile Device Support”.

But I did not find anything about temperature etc.

Gerriet.





Temperatur etc. from Locale

Gerriet M. Denkmann
 

I want to know, given a certain NSLocale (e.g. NSLocale.currentLocale), how to represent:

Temperature (K, °C or whatever)
Distance (km, miles, furlongs, lightyears, … )
Speed (m/sec, km/h, …)
Frequency (rpm, U/min, Hz, … )

The only thing I did find out is that my locale uses NSLocaleMeasurementSystem = Metric .

Is the Locale the right place to look for this information?

There is Unicode Common Locale Data Repository, which claims to be used by “Apple (macOS, iOS, watchOS, tvOS, and several applications; Apple Mobile Device Support”.

But I did not find anything about temperature etc.

Gerriet.


Re: More Layout Questions

Dave
 

Hi,

It’s not so much it can’t handle it, its that it takes way to long to do the design in  Xcode/Interface Builder and what I am doing is not that difficult but there is a lot of it. Also their is a lot of documentation, I could never find anything actually helped me to do the design for a game. After 3 separate attempts that took around 12 days, I managed to get it working with a few glitches, then I came to modify it, and it was sheer hell. In the end I gave up and decided to do the layout myself.

Cheers
Dave

On 22 Sep 2018, at 17:54, Gary L. Wade <garywade@...> wrote:

When you find a use case it doesn’t handle, consider the various container views available, and if those don’t help, definitely write a radar.  Apple is always improving things, and if you report such a case, it helps everyone.

On Sep 22, 2018, at 7:54 AM, Keary Suska <cocoa-dev@...> wrote:

Honestly, that means using autolayout because that “is thew way Cocoa works these days” but I sympathize with a strong desire to avoid it, as well as there being a number of use cases it simply can’t handle.



Re: More Layout Questions

Dave
 

HI,

Thanks for this, I did something like this a long while back and must have confused the “Display” path with the “Layout” path, thanks for putting me on the right track again. The its written it will be very easy to change what I have already to do it the way you describe below.

Honestly, that means using autolayout because that “is thew way Cocoa works these days” but I sympathize with a strong desire to avoid it, as well as there being a number of use cases it simply can’t handle.

The amount of time it was taking to make the board for the game I am working on to work was ridiculous for the return. The number of constraints was enormous and it was really slow when resizing. Add to this that as soon as you wanted to change something it sometimes meant re-doing *lots* of constraints and still it wasn’t 100%. It’s not Auto-Layout itself, the underlying technology is really good and I’d love to use it, but the tools we have for creating the Layouts in the first place are just horrible and unforgiving. I think a lot of it is due to having everything shoved into one giant all-purpose window/tab in Interface Builder. IMO its needs a specialist window that is designed specifically for Auto-Layout generation.

Where you put resize logic probably best depends on who knows the most about how views should be laid out. For a super view that auto resizes subviews, its -resizeSubviewsWithOldSize: method is called anytime its frame changes. That is a better place to perform resizing on subviews, since it will be called by any method that changes the view's frame. If you want each subview to manage itself, you would override -resizeWithOldSuperviewSize: in the view. IMHO, it makes more sense for the superviews to manage their subviews so you avoid a bunch of subclasses that do nothing but self-resizing.
I’m in two minds on this, a lot of the work can be done in a View Base Class that the subviews inherit from, this means that each subview has minimum extra code, but you can override it if you want to. I’m actually working on a number of games that use (mostly) a common board, each Game-App, and I can pull in Custom Views for the Games if I like, just by either adding or replacing a View in the Hierarchy and can be done in IB with no or minimal code changes.


Thanks again for your help.

All the Best
Dave

On 22 Sep 2018, at 16:54, Keary Suska <cocoa-dev@...> wrote:

On Sep 22, 2018, at 5:29 AM, Dave <dave@...> wrote:

Hi,

I’m confused then! The “layout” method has been around a lot longer than Auto Layout and it worked in conjunction with the Auto-Resizing options (defined in the Size Pane in IB). I assumed that in order to customise my layout I would override “layout” as done in the past, is this not the case?
This is incorrect: “layout” methods were added when autolayout was introduced in Lion (10.7). Before that, you used “frame” and “display” methods, and it was generally the responsibility of the superview to resize its subviews when its frame changes.

You seem to be saying that If I want to layout my views myself, I don’t override the layout method or use setNeedsLayout?
Yes.

I could change the name of the method from “layout" to (say) “layoutView” for instance and instead of calling “setNeedsLayout” call “layoutView” on the subviews. However, at the moment when the window is resized, it initially calls “layout” in the WindowTracker view, do I still override this and “layoutView” on its subviews?

The only other way of handling I can think of is to override setFrame and do the layout there, does that sound like a better approach?
Where you put resize logic probably best depends on who knows the most about how views should be laid out. For a super view that auto resizes subviews, its -resizeSubviewsWithOldSize: method is called anytime its frame changes. That is a better place to perform resizing on subviews, since it will be called by any method that changes the view's frame. If you want each subview to manage itself, you would override -resizeWithOldSuperviewSize: in the view. IMHO, it makes more sense for the superviews to manage their subviews so you avoid a bunch of subclasses that do nothing but self-resizing.

I’m just trying to find a decent way of laying out my views that’s fits into the way Cocoa works these days…..
Honestly, that means using autolayout because that “is thew way Cocoa works these days” but I sympathize with a strong desire to avoid it, as well as there being a number of use cases it simply can’t handle.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

On 21 Sep 2018, at 17:28, Quincey Morris <quinceymorris@...> wrote:

On Sep 21, 2018, at 08:07 , Dave <dave@...> wrote:

I’m not sure what you mean, my storyboard file has Auto Layout DISABLED and there are no constraints anywhere in the project. Also, all the old-type layout options are off in the Size Panel in IB.
I mean that if you have disabled auto-layout, then you shouldn’t be trying to use auto-layout. Implementing the “layout” method comes under the heading of “trying to use auto-layout”, as the documentation says.

It may be possible that “layout” gets called anyway (it would have no effect unless you overrode it to do something), but the behavior isn’t documented in that case. You can’t rely on it to behave in any meaningful way.


Re: Refactoring existing Core Data entity classes?

Chris Hanson
 

That should be reasonable, I don’t recall whether you’ll need to create a mapping model or not to actually migrate the existing store.

It does mean that all of the instances will wind up shoved into a single table in the underlying database, that’s a tradeoff you have to decide on for your particular case; it depends how disjoint the subentities really are. If they have a sufficiently strong is-a relationship with each other that you want to be able to iterate over all the objects in the database to update them then (1) you probably don’t have all that many instances :) and (2) they probably aren’t all that disjoint.

  -- Chris

On Sep 22, 2018, at 7:09 PM, Steve Christensen <punster@...> wrote:

So, a little background. The model on the server has a number of types that inherit from a common class that contains a number of common properties. The original authors of the iOS app created a bunch of Core Data entities that flatten the hierarchy since the json includes both Common and specific properties. This becomes a pain in some cases because I can’t say, “fetch all the Common class instances” so I can perform operations on the common properties.

At this point I am expecting to manually edit the class files to separate out the Common properties (the CD model file is set for manual class file maintenance). I want to figure out what I need to do to migrate the existing store so that the Common properties get associated with the Common class in the model and any “moving around” within the store happens correctly.

If I can just create a new model version, create a Common entity containing its properties, change all the subclasses to inherit from Common and remove the shared properties from those entities in the model and Core Data will take care of the details at runtime then that’s the best case. Being an occasional pessimist I’m not expecting the best case which is why I was asking for details. I haven’t run across a discussion of somebody doing this sort of thing before.

Steve


On Sep 22, 2018, at 6:54 PM, Chris Hanson <cmhanson@...> wrote:

If you put the entities themselves in an inheritance relationship, Xcode will generate code reflecting that.

I would only do this for “strongly” related entities though since entity inheritance implies table sharing. (Unlike EOF, Core Data doesn’t let you choose whether or not to share storage when using inheritance.)

For example, if I were modeling a blog, I might give both BlogEntry and BlogComment entities a timestamp attribute, but I wouldn’t have a BlogObject parent entity for both. However, I might have a BlogText parent entity with BlogEntryText and BlogCommentText subentities, since each subentity is likely to be virtually identical except for the relationship between it and a BlogEntry or BlogComment. Make sense?

 -- Chris

On Sep 22, 2018, at 6:34 PM, Steve Christensen <punster@...> wrote:

Hi Chris,

Thanks, that’s good to know for the easy path. What about the case where I want to update the model to reflect the class hierarchy? Based on what the Common superclass will handle, I can see that it would be more convenient to request instances of Common to perform certain operations rather than iterating over all the subclasses.

Steve

PS: Regarding SuperClock!, I hope you’re not waiting on any updates. ;)


On Sep 22, 2018, at 11:45 AM, Chris Hanson <cmhanson@...> wrote:

On Sep 21, 2018, at 9:26 PM, Steve Christensen via Groups.Io <punster@...> wrote:

Is this possible using just a new model version and/or mapping model, or does it require something more involved?

In fact you don’t even need a new model version, you can just refactor the code.

We made sure that Core Data’s concept of entity inheritance is independent of class hierarchy, so you don’t actually need to create a parent entity that corresponds to the Common class if you don’t want to be able to have a query return instances of both Entity1 and Entity2.

This only works if you’re not using code generation. Xcode’s Core Data code generation (whether invoked automatically or manually) does assume entity and class hierarchies are the same, and will only use NSManagedObject as a parent class for base entities, not some other class you specify. This is one reason we allow category/extension-only code generation: It lets you maintain the class hierarchy you want, while still letting Xcode generate the accessor declarations.

 -- Chris

PS - I’m still using SuperClock on my vintage Macs. :)



Re: Refactoring existing Core Data entity classes?

Steve Christensen
 

So, a little background. The model on the server has a number of types that inherit from a common class that contains a number of common properties. The original authors of the iOS app created a bunch of Core Data entities that flatten the hierarchy since the json includes both Common and specific properties. This becomes a pain in some cases because I can’t say, “fetch all the Common class instances” so I can perform operations on the common properties.

At this point I am expecting to manually edit the class files to separate out the Common properties (the CD model file is set for manual class file maintenance). I want to figure out what I need to do to migrate the existing store so that the Common properties get associated with the Common class in the model and any “moving around” within the store happens correctly.

If I can just create a new model version, create a Common entity containing its properties, change all the subclasses to inherit from Common and remove the shared properties from those entities in the model and Core Data will take care of the details at runtime then that’s the best case. Being an occasional pessimist I’m not expecting the best case which is why I was asking for details. I haven’t run across a discussion of somebody doing this sort of thing before.

Steve

On Sep 22, 2018, at 6:54 PM, Chris Hanson <cmhanson@...> wrote:

If you put the entities themselves in an inheritance relationship, Xcode will generate code reflecting that.

I would only do this for “strongly” related entities though since entity inheritance implies table sharing. (Unlike EOF, Core Data doesn’t let you choose whether or not to share storage when using inheritance.)

For example, if I were modeling a blog, I might give both BlogEntry and BlogComment entities a timestamp attribute, but I wouldn’t have a BlogObject parent entity for both. However, I might have a BlogText parent entity with BlogEntryText and BlogCommentText subentities, since each subentity is likely to be virtually identical except for the relationship between it and a BlogEntry or BlogComment. Make sense?

-- Chris

On Sep 22, 2018, at 6:34 PM, Steve Christensen <punster@...> wrote:

Hi Chris,

Thanks, that’s good to know for the easy path. What about the case where I want to update the model to reflect the class hierarchy? Based on what the Common superclass will handle, I can see that it would be more convenient to request instances of Common to perform certain operations rather than iterating over all the subclasses.

Steve

PS: Regarding SuperClock!, I hope you’re not waiting on any updates. ;)


On Sep 22, 2018, at 11:45 AM, Chris Hanson <cmhanson@...> wrote:

On Sep 21, 2018, at 9:26 PM, Steve Christensen via Groups.Io <punster@...> wrote:

Is this possible using just a new model version and/or mapping model, or does it require something more involved?
In fact you don’t even need a new model version, you can just refactor the code.

We made sure that Core Data’s concept of entity inheritance is independent of class hierarchy, so you don’t actually need to create a parent entity that corresponds to the Common class if you don’t want to be able to have a query return instances of both Entity1 and Entity2.

This only works if you’re not using code generation. Xcode’s Core Data code generation (whether invoked automatically or manually) does assume entity and class hierarchies are the same, and will only use NSManagedObject as a parent class for base entities, not some other class you specify. This is one reason we allow category/extension-only code generation: It lets you maintain the class hierarchy you want, while still letting Xcode generate the accessor declarations.

-- Chris

PS - I’m still using SuperClock on my vintage Macs. :)


Re: Refactoring existing Core Data entity classes?

Chris Hanson
 

If you put the entities themselves in an inheritance relationship, Xcode will generate code reflecting that.

I would only do this for “strongly” related entities though since entity inheritance implies table sharing. (Unlike EOF, Core Data doesn’t let you choose whether or not to share storage when using inheritance.)

For example, if I were modeling a blog, I might give both BlogEntry and BlogComment entities a timestamp attribute, but I wouldn’t have a BlogObject parent entity for both. However, I might have a BlogText parent entity with BlogEntryText and BlogCommentText subentities, since each subentity is likely to be virtually identical except for the relationship between it and a BlogEntry or BlogComment. Make sense?

  -- Chris

On Sep 22, 2018, at 6:34 PM, Steve Christensen <punster@...> wrote:

Hi Chris,

Thanks, that’s good to know for the easy path. What about the case where I want to update the model to reflect the class hierarchy? Based on what the Common superclass will handle, I can see that it would be more convenient to request instances of Common to perform certain operations rather than iterating over all the subclasses.

Steve

PS: Regarding SuperClock!, I hope you’re not waiting on any updates. ;)


On Sep 22, 2018, at 11:45 AM, Chris Hanson <cmhanson@...> wrote:

On Sep 21, 2018, at 9:26 PM, Steve Christensen via Groups.Io <punster@...> wrote:

Is this possible using just a new model version and/or mapping model, or does it require something more involved?

In fact you don’t even need a new model version, you can just refactor the code.

We made sure that Core Data’s concept of entity inheritance is independent of class hierarchy, so you don’t actually need to create a parent entity that corresponds to the Common class if you don’t want to be able to have a query return instances of both Entity1 and Entity2.

This only works if you’re not using code generation. Xcode’s Core Data code generation (whether invoked automatically or manually) does assume entity and class hierarchies are the same, and will only use NSManagedObject as a parent class for base entities, not some other class you specify. This is one reason we allow category/extension-only code generation: It lets you maintain the class hierarchy you want, while still letting Xcode generate the accessor declarations.

  -- Chris

PS - I’m still using SuperClock on my vintage Macs. :)



681 - 700 of 1460