Re: Quickie about constraints

[Kyle Sluder]

On Aug 15, 2014, at 8:44 PM, Ben Kennedy  wrote:
> 
>> On 15 Aug 2014, at 8:17 pm, Graham Cox  wrote:
>> 
>> What I really want is that part of my view hierarchy to be free to use 
>> -setFrame:, but other parts use the autolayout constraints normally.
> 
> Can't you simply set translatesAutoresizingMaskIntoConstraints = NO on the 
> views in question?  Then you should be free to manipulate such views' frames 
> at will without interfering in any related constraints.

Not sure if you’ve got this backwards, or are unaware of a certain frameworks 
bug.

Views whose translatesAutoresizingMaskIntoConstraints property is set to YES 
can be positioned via -setFrame:. Views whose property is set to NO must be 
positioned via constraints.

Theoretically, you could still use -setFrame: to position views whose 
translatesAutoresizingMask property is set to NO (and I believe Apple even said 
that you could), but it turns out that Auto Layout evaluates *every* view in 
the window and sets and un constrained variables to zero. That means that if a 
layout pass happens to occur at any point, your view will effectively disappear 
as its frame is set to NSZeroRect.

I filed this a long time ago, but I doubt it will ever get fixed. :(

--Kyle Sluder
___

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: Quickie about constraints

[Ben Kennedy]

On 15 Aug 2014, at 8:17 pm, Graham Cox  wrote:

> What I really want is that part of my view hierarchy to be free to use 
> -setFrame:, but other parts use the autolayout constraints normally. 

Can't you simply set translatesAutoresizingMaskIntoConstraints = NO on the 
views in question?  Then you should be free to manipulate such views' frames at 
will without interfering in any related constraints.

b


___

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: Quickie about constraints

[Graham Cox]

On 15 Aug 2014, at 7:39 pm, Jonathan Mitchell  wrote:

> 
> On 15 Aug 2014, at 04:55, Graham Cox  wrote:
> 
>> I ask because I'm having trouble getting part of my interface working with 
>> autolayout, though other parts work fine. Since the part that doesn't work 
>> works just fine with struts-and-springs, and has done for a long time, I'm 
>> wondering if I can use a mix of autolayout and the 'old way' in a single 
>> window, specifically, in two different panes of a split view.
> 
> You should be okay. The layout system will convert autoresizing masks into 
> constraints for any views that don’t support Auto Layout.
> 
> https://developer.apple.com/library/mac/releasenotes/UserExperience/RNAutomaticLayout/#//apple_ref/doc/uid/TP40010631-CH1-SW22
> 
> Jonathan


OK, I understand that autoresizing masks are converted, but one key issue is 
that I've read (in comments here) that when using constrants, I shouldn't use 
-setFrame: on a view, but instead modify the constraints. Using -setFrame: is a 
key part of what my old code does, and that works fine with struts and springs. 
If these are translated to constraints, it may be that things work OK until I 
call -setFrame:, at which point it blows up.

What I really want is that part of my view hierarchy to be free to use 
-setFrame:, but other parts use the autolayout constraints normally. The object 
is to avoid rewriting working code that has been functional for a decade, and 
so introducing a whole bunch of new bugs that will need a load of time to 
eliminate that I just don't have. There may be no general solution, but since 
the particular view is the content of a scroller, it might be possible to come 
up with a special case for this, because it seems constraints can't cross 
"scroller barriers", and that might therefore allow me to isolate the use of 
-setFrame: to this particular case.

--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: When would I use this (im)mutable property pair setup? (Misunderstanding advanced KVO)

[Quincey Morris]

(reposted for formatting)

On Aug 15, 2014, at 16:24 , Daryle Walker  wrote:

> As I’m stripping out the NSDocument stuff, I realize that I need some sort of 
> global object to hold each window(-controller) as I create them, otherwise 
> ARC will purge them soon after creation.  The application delegate seems like 
> a good option, as it’s my only other custom class and Apple uses it to store 
> the window in sample projects with a single window.  I read a neat technique 
> at , and I’m wondering if I would ever 
> need it and should switch to something easier.

It’s the right idea, but the wrong implementation.

> @property (nonatomic, copy) NSSet * windowControllers;
> @property (nonatomic, readonly) NSMutableSet *  mutableWindowControllers;

Make the “windowControllers” property ‘readonly’ too. Although it’s feasible to 
allow the entire set to be changed via the setter, there are other ways to do 
this (e.g. removeAll + add), and you’re unlikely to need to do that anyway. The 
‘copy’ property “pretends” that the implementation is something other than it 
is.

> - (NSSet *)windowControllers
> {
>return [NSSet setWithSet:_windowControllers];
> }

It’s simpler to ‘return _windowControllers;’. Or, better, use ‘@synthesize 
windowControllers = _mutableWindowControllers;'

Since the return value is type ‘NSSet*’, the client can’t use the pointer to 
mutate the collection. (You can typically assume the client won’t do something 
hacky, like cast the pointer back to a NSMutableSet*. If you can’t assume that, 
you’ve got bigger problems.)

> - (void)setWindowControllers:(NSSet *)windowControllers
> {
>[_windowControllers setSet:windowControllers];
> }
> 
> You don’t need this, if you make the “windowControllers” property ‘readonly’, 
> as I recommended above.
> 
> - (void)addWindowControllersObject:(PrBrowserController *)controller
> {
>[_windowControllers addObject:controller];
> }
> 
> - (void)addWindowControllers:(NSSet *)controllers
> {
>[_windowControllers unionSet:controllers];
> }
> 
> - (void)removeWindowControllersObject:(PrBrowserController *)controller
> {
>[_windowControllers removeObject:controller];
> }
> 
> - (void)removeWindowControllers:(NSSet *)controllers
> {
>[_windowControllers minusSet:controllers];
> }

These are correct, though you only need one of the ‘add…’ and one of the 
‘remove…’ methods. Although it’s not wrong to implement both of each, it’s 
overkill for a set that’s not going to be very large. It’s typical to implement 
only the 1st and 3rd of these. (Keep in mind, you’re unlikely to want to add a 
*set* of window controllers at once.)

Note that these are the KVC “mutable unordered accessors” described here:


https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/KeyValueCoding/Articles/AccessorConventions.html

This means it’s safe to expose these methods publicly. Or you can keep them 
private, and let clients use “mutableWindowControllers” for all their mutation 
needs. This is a matter of taste only.

> - (void)intersectWindowControllers:(NSSet *)controllers
> {
>[_windowControllers intersectSet:controllers];
> }

No, you don’t need this, or any other accessors. If you do everything else 
right, any client invocation of (say) ‘[myAppDelegate.mutableWindowControllers 
intersectSet: controllers];’ will get automatically translated into a 
combination of ‘add…’ and ‘remove…’ methods *and will be KVO-compliant*. Your 
code isn’t KVO compliant.

> @synthesize mutableWindowControllers = _windowControllers;

No, this is wrong and dangerous. You’re handing out a mutable reference to your 
private ivar, thus allowing clients to run rampant on your property’s integrity.

Instead, you should implement it like this:

- (NSMutableSet*) mutableWindowControllers {
return [self mutableSetValueForKey: “windowControllers”];
}

This returns a proxy object, so your underlying set stays private, and any 
mutation that a client applies to the proxy is actually applied to your 
underlying data via your accessors (the ‘add…’ and ‘remove…’ methods) *and* is 
KVO compliant.

Finally, my preference is to use a NSArray metaphor for this sort of thing, 
rather than a NSSet metaphor. Yes, the collection of window controllers is 
unordered, but NSSet uses ‘isEqual:’ equality rather than pointer equality to 
distinguish between members. By default, it’s the same thing, but the reliance 
on *not* having a customized ‘isEqual:’ for your window controller classes is a 
hidden fragility in your implementation.

Again, because you’re not going to have a very big collection of window 
controllers, performance and efficiency of the underlying (set vs array) 
representation is not a significant issue.


___

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-d

NSWindowController

[Raglan T. Tiger]

I subclass NSWindowController.

___

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

When would I use this (im)mutable property pair setup? (Misunderstanding advanced KVO)

[Daryle Walker]

As I’m stripping out the NSDocument stuff, I realize that I need some sort of 
global object to hold each window(-controller) as I create them, otherwise ARC 
will purge them soon after creation.  The application delegate seems like a 
good option, as it’s my only other custom class and Apple uses it to store the 
window in sample projects with a single window.  I read a neat technique at 
, and I’m wondering if I would ever need 
it and should switch to something easier.

//==In the header file===
@interface PrairieAppDelegate : NSObject 

// unrelated declarations...

@property (nonatomic, copy) NSSet * windowControllers;
@property (nonatomic, readonly) NSMutableSet *  mutableWindowControllers;

@end

//=

I put the implementation methods in the source file:

//==In the implementation file===
#pragma mark Private interface

@interface PrairieAppDelegate () {
NSMutableSet *  _windowControllers;
}

@end

@implementation PrairieAppDelegate

#pragma mark Initialization

- (id)init
{
if (self = [super init]) {
_windowControllers = [[NSMutableSet alloc] init];
}
return self;
}

// No explicit dealloc.

#pragma mark Property getters & setters

// trim unrelated property accessors...

- (NSSet *)windowControllers
{
return [NSSet setWithSet:_windowControllers];
}

- (void)setWindowControllers:(NSSet *)windowControllers
{
[_windowControllers setSet:windowControllers];
}

- (void)addWindowControllersObject:(PrBrowserController *)controller
{
[_windowControllers addObject:controller];
}

- (void)addWindowControllers:(NSSet *)controllers
{
[_windowControllers unionSet:controllers];
}

- (void)removeWindowControllersObject:(PrBrowserController *)controller
{
[_windowControllers removeObject:controller];
}

- (void)removeWindowControllers:(NSSet *)controllers
{
[_windowControllers minusSet:controllers];
}

- (void)intersectWindowControllers:(NSSet *)controllers
{
[_windowControllers intersectSet:controllers];
}

@synthesize mutableWindowControllers = _windowControllers;

#pragma mark NSApplicationDelegate overrides
//…

//=

My window-controller class instances put themselves in the set on “init” and 
remove themselves on “dealloc”.  I originally had “mutableWindowControllers" 
private to the implementation file, but the window-controller instances 
couldn’t insert themselves with only “windowControllers" public.  That makes 
sense if I had an actual NSSet; but then what are these mutator methods 
actually supposed to do?  When would they ever be called?  Do I have to move 
them to the header file?

Should I get rid of them and stick to just a mutable-set property?  (Delete the 
current “windowControllers” and rename the mutable variant.)  But the text 
seemed like that would mess up KVO in a different way.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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: NSPopupButton, bindings, and item state

[Keary Suska]

On Aug 15, 2014, at 8:58 AM, Jonathan Taylor  
wrote:

>>> After being impressed with bindings for an NSTableView, I’m looking at what 
>>> I can do for a standalone NSPopupButton, in the hope of reducing the amount 
>>> of glue code I have. The button isn’t just a simple one though, I need to:
>>> - Include separator items
>>> - Disable (grey out) some items
>>> - Select multiple items (it’s configured as a pull-down menu)
>>> 
>>> It’s not obvious to me that there’s a way of doing any of those things with 
>>> bindings (though the multiple-selected-items might work somehow through the 
>>> array controller). Can anyone advise on whether there is any hope for this 
>>> approach, or do I have to accept that this is more than the bindings are 
>>> intended to help with?
>> 
>> Short answer, yes. With some hackery you could get separator items, but the 
>> multiple checked state will likely require as much work as your glue code. 
>> So I wold say the best approaches are a 50/50 between bindings and glue. 
>> That is, you could use bindings for content, but manually handle state, or 
>> use bindings for state, and manually handle content. Doing both is probably 
>> an exercise in futility.
> 
> Thanks for confirming! Out of interest, could you describe the hackery you 
> have in mind for separators? It might still be helpful to bind the menu item 
> titles to an array.

This thread gives a couple of approaches, depending on how you need the menu 
constructed: 
http://www.cocoabuilder.com/archive/cocoa/275031-nspopupbutton-bindings-separator-items.html

> As for manually handing state (if I were to use bindings for content), would 
> the NSMenuDelegate method menu:updateItem:atIndex:shouldCancel: be the 
> appropriate place to determine which items are checked, enabled, etc? In my 
> all-manual version, I keep track of when the user checks/unchecks individual 
> items through an action on the NSMenuItem. I'm going to have to do something 
> else if the item list is bound to an array - any suggestions about the most 
> appropriate place to identify when the selection changes?

As long as you can hook your delegate in on time, sure. I think that 
NSPopupButton keeps the same NSMenu instance throughout it's lifetime, but if 
not, the delegate approach won't work.

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


___

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 tableView:viewForTableColumn:row:

[Quincey Morris]

On Aug 15, 2014, at 14:09 , Laurent Daudelin  wrote:

> Now, I implement *tableView:viewForTableColumn:row:*. Based on an array of
> dictionaries, I set the various UI items in the tableCellView that I get
> calling *makeViewWithIdentifier:owner:* passing the tableColumn identifier
> that is set to my custom tableViewCell subclass. Everything works but as I
> download stuff associated with each row and update the appropriate
> dictionary, the tableview starts flickering. Inserting an NSLog() at the
> beginning of *tableView:viewForTableColumn:row:* reveals that the method is
> called several times per second. NOTE: I am not calling *reloadData* or
> *reloadDataForRowIndexes:columnIndexes:* at *ANY* place in my code.
> 
> How is that possible? Is it possible that the NSProgressIndicator is
> causing this? Otherwise, what am I missing?

My guess is that it’s the data updates that are leading to this, rather than 
the progress indicator. However, you can test it easily enough — (1) try the 
download without updating the dictionaries, and (2) try the download with the 
progress indicator hidden.

*How* are you updating the data that the table view sees? Are there bindings 
involved? Is there an objectValue -> underlying dictionary binding, or a cell 
view element -> objectValue binding?


___

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

Problem with tableView:viewForTableColumn:row:

[Laurent Daudelin]

I've just created a new OS X project from Xcode 5.1.1. Simple project, one
window, one tableview set to use NSTableCellView. I have a few UI items in
the table cell view. Nothing fancy, a couple of NSTextFields and an
NSProgressIndicator.

Now, I implement *tableView:viewForTableColumn:row:*. Based on an array of
dictionaries, I set the various UI items in the tableCellView that I get
calling *makeViewWithIdentifier:owner:* passing the tableColumn identifier
that is set to my custom tableViewCell subclass. Everything works but as I
download stuff associated with each row and update the appropriate
dictionary, the tableview starts flickering. Inserting an NSLog() at the
beginning of *tableView:viewForTableColumn:row:* reveals that the method is
called several times per second. NOTE: I am not calling *reloadData* or
*reloadDataForRowIndexes:columnIndexes:* at *ANY* place in my code.

How is that possible? Is it possible that the NSProgressIndicator is
causing this? Otherwise, what am I missing?

-Laurent.
-- 
Laurent Daudelin laur...@nemesys-soft.com
AIM/iChat/Skype:*LaurentDaudelin*  http://www.nemesys-soft.com/
Logiciels Nemesys 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

Re: How unique does WebView's -groupName have to be?

[Jens Alfke]

> On Aug 15, 2014, at 9:49 AM, Kyle Sluder  wrote:
> 
> You should probably be using the new API.

…unless you want to support customers who haven't upgraded to 10.10. Which I 
imagine is true of a lot of developers.

(Me, I can't consider using iOS 8 or OS X 10.10 features for at least another 
year.)

—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: How unique does WebView's -groupName have to be?

[Kyle Sluder]

On Fri, Aug 15, 2014, at 10:42 AM, Daryle Walker wrote:
> I use a “[[NSUUID UUID] UUIDString]” to make every instance’s name
> unique.  But the reference docs plus some sample code just use the XIB’s
> name.  Am I overthinking it?  What is this name for?  Can we get away
> with multiple WebView instances within the same app having the same ID?

It's worth noting that WKWebView, which replaces WebView in OS X 10.10,
does not have a groupName property at all.

https://developer.apple.com/library/prerelease/Mac/documentation/WebKit/Reference/WKWebView_Ref/index.html

You should probably be using the new API.

--Kyle Sluder

___

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

How unique does WebView's -groupName have to be?

[Daryle Walker]

I use a “[[NSUUID UUID] UUIDString]” to make every instance’s name unique.  But 
the reference docs plus some sample code just use the XIB’s name.  Am I 
overthinking it?  What is this name for?  Can we get away with multiple WebView 
instances within the same app having the same ID?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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: NSPopupButton, bindings, and item state

[Jonathan Taylor]

>> After being impressed with bindings for an NSTableView, I’m looking at what 
>> I can do for a standalone NSPopupButton, in the hope of reducing the amount 
>> of glue code I have. The button isn’t just a simple one though, I need to:
>> - Include separator items
>> - Disable (grey out) some items
>> - Select multiple items (it’s configured as a pull-down menu)
>> 
>> It’s not obvious to me that there’s a way of doing any of those things with 
>> bindings (though the multiple-selected-items might work somehow through the 
>> array controller). Can anyone advise on whether there is any hope for this 
>> approach, or do I have to accept that this is more than the bindings are 
>> intended to help with?
> 
> Short answer, yes. With some hackery you could get separator items, but the 
> multiple checked state will likely require as much work as your glue code. So 
> I wold say the best approaches are a 50/50 between bindings and glue. That 
> is, you could use bindings for content, but manually handle state, or use 
> bindings for state, and manually handle content. Doing both is probably an 
> exercise in futility.

Thanks for confirming! Out of interest, could you describe the hackery you have 
in mind for separators? It might still be helpful to bind the menu item titles 
to an array.

As for manually handing state (if I were to use bindings for content), would 
the NSMenuDelegate method menu:updateItem:atIndex:shouldCancel: be the 
appropriate place to determine which items are checked, enabled, etc? In my 
all-manual version, I keep track of when the user checks/unchecks individual 
items through an action on the NSMenuItem. I'm going to have to do something 
else if the item list is bound to an array - any suggestions about the most 
appropriate place to identify when the selection changes?
___

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: NSPopupButton, bindings, and item state

[Keary Suska]

On Aug 15, 2014, at 5:23 AM, Jonathan Taylor  
wrote:

> After being impressed with bindings for an NSTableView, I’m looking at what I 
> can do for a standalone NSPopupButton, in the hope of reducing the amount of 
> glue code I have. The button isn’t just a simple one though, I need to:
> - Include separator items
> - Disable (grey out) some items
> - Select multiple items (it’s configured as a pull-down menu)
> 
> It’s not obvious to me that there’s a way of doing any of those things with 
> bindings (though the multiple-selected-items might work somehow through the 
> array controller). Can anyone advise on whether there is any hope for this 
> approach, or do I have to accept that this is more than the bindings are 
> intended to help with?

Short answer, yes. With some hackery you could get separator items, but the 
multiple checked state will likely require as much work as your glue code. So I 
wold say the best approaches are a 50/50 between bindings and glue. That is, 
you could use bindings for content, but manually handle state, or use bindings 
for state, and manually handle content. Doing both is probably an exercise in 
futility.

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


___

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

NSPopupButton, bindings, and item state

[Jonathan Taylor]

After being impressed with bindings for an NSTableView, I’m looking at what I 
can do for a standalone NSPopupButton, in the hope of reducing the amount of 
glue code I have. The button isn’t just a simple one though, I need to:
- Include separator items
- Disable (grey out) some items
- Select multiple items (it’s configured as a pull-down menu)

It’s not obvious to me that there’s a way of doing any of those things with 
bindings (though the multiple-selected-items might work somehow through the 
array controller). Can anyone advise on whether there is any hope for this 
approach, or do I have to accept that this is more than the bindings are 
intended to help with?

Thanks for any suggestions
Jonny
___

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: Stuck in Swift

[Gerriet M. Denkmann]

On 14 Aug 2014, at 19:24, Roland King  wrote:

>> 
>> class AppDelegate: NSObject
>> {
>>  dynamic var statusString : String?  //  bound to some TextField
>> 
>>  let someThing = SomeClass( myStatusHandler )< this 
>> creates strange error messages
>> 
>>  func myStatusHandler( s: String )
>>  {
>>  statusString = s
>>  }
>> }
>> 
>> class SomeClass
>> {
>>  private let statusHandler:  (String) -> Void
>> 
>>  init( statusHandler: (String) -> Void ) 
>>  {
>>  self.statusHandler = statusHandler
>>  }
>> }
>> 
>> Gerriet.
>> 
> 
> 
> What you’re doing there doesn’t make much sense to me. myStatusHandler is an 
> instance method (or whatever it’s called in Swift). You’re trying to assign 
> it outside the context of an actual instance, there’s no ‘self’ at that 
> point. I don’t really know what the type of myStatusHander is at the point 
> you’re trying to assign it, probably something which takes an AppDelegate and 
> returns a (String)->Void function, or something like that, ie 
> (AppDelegate)->(String)->Void. Whatever it is it’s not a (String)->Void 
> function. 
> 
> if you write an init() method and put it in there there’s context for it, 
> self exists
> 
> class AppDelegate: NSObject
> {
>   dynamic var statusString : String?  //  bound to some TextField
>   let someThing : SomeClass?
> 
>   func myStatusHandler( s: String )
>   {
>   statusString = s
>   }
> 
>   override init()
>   {
>   super.init()
>   someThing = SomeClass( self.myStatusHandler )
>   }
> }
> 
> class SomeClass
> {
>   private let statusHandler:  (String) -> Void
> 
>   init( statusHandler: (String) -> Void )
>   {
>   self.statusHandler = statusHandler
>   }
> }
> 
> let a = AppDelegate();
> a.someThing
> 
> and yes you have to do the little let someThing: SomeClass? dance so you can 
> use super.init() before using myStatusHandler. 
> 
> I’m almost entirely sure there’s a far better way to do what you’re trying to 
> do which doesn’t involve quite this much ugly. Not loving this syntax yet, 
> really, just not getting into it and I’m not even trying anything hard. 

Thanks a lot: doing it your way it works perfectly.

Kind regards,

Gerriet.


___

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: Quickie about constraints

[Jonathan Mitchell]

On 15 Aug 2014, at 04:55, Graham Cox  wrote:

> I ask because I'm having trouble getting part of my interface working with 
> autolayout, though other parts work fine. Since the part that doesn't work 
> works just fine with struts-and-springs, and has done for a long time, I'm 
> wondering if I can use a mix of autolayout and the 'old way' in a single 
> window, specifically, in two different panes of a split view.

You should be okay. The layout system will convert autoresizing masks into 
constraints for any views that don’t support Auto Layout.

https://developer.apple.com/library/mac/releasenotes/UserExperience/RNAutomaticLayout/#//apple_ref/doc/uid/TP40010631-CH1-SW22

Jonathan
___

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