Re: Pasteboards and NSSecureCoding

[Quincey Morris]

On Dec 19, 2017, at 18:32 , Jeremy Hughes  wrote:
> 
>> On 20 Dec 2017, at 02:22, Jeremy Hughes > > wrote:
>> 
>> What I don’t like about [NSArray.self] is that it’s an artefact of bridging. 
>> I’m not actually using it in the encoder:
>> 
>> coder.encode(arrayOfInts, forKey: kArrayKey)
> 
> The declaration:
> 
> encode(_ object: Any?, forKey key: String)
> 
> seems to indicate that it encodes any object

Yeah, you’re right, it’s secure on the decoding side only. 

This “encode” method is @objc, as I think you already noted, which AFAIK means 
that if the value is an array, it’s going to be automatically bridged to a 
NSArray. I would also expect it to become NSArray*, but I can’t 
remember the rules, so I won’t go out on that limb. I also haven’t looked at 
secure decoding recently, so I don’t know why or if the absence of the element 
type matters when you’re securely decoding. It used to.

Note that the first parameter (“Any?”) doesn’t have to be an object in Swift, 
although an object reference is required for the Obj-C method underneath. If 
it’s a non-object in Swift, it’s actually passed as an opaque object that wraps 
the Swift value.

After a while, you start to feel you need a ouija board to figure this stuff 
out. As an alternative, if you are in control of both encoding and decoding, 
and don’t need Obj-C compatibility inside the archive, you might do better to 
use encode/decodeEncodable instead of encode/decodeObject. That takes type 
bridging out of the picture, and trill preserves Swift types.

The last piece of this is that you should use one of the “decodeTopLevel…” 
methods to decode the root object of your archive, for example 
“decodeTopLevelDecodable(_:forKey:)”. This enables the relatively new — only 5 
years old! — failable decoding mechanism, where an error is thrown at the top 
level if any of the decoding fails anywhere in the archive, distinguishing 
failure from an init?(coder:) method that merely returns nil to signify an 
optional value that isn’t present. (You use “failWithError” to supply an error 
if you need to fail the decoding.)

Putting all that together, you can use NSKeyedArchiver/Unarchiver to encode and 
decode more or less completely in the Swift domain (Codable), with proper error 
handling and no obscure messing around with the types.
___

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: 10.13 printing problem

[Jeremy Hughes]

> On 19 Dec 2017, at 18:03, Jeremy Hughes  wrote:
> 
> I have a problem printing an autolayout view in 10.13.2, and I’m wondering if 
> there is something wrong with my code or if Apple broke something in 10.13 or 
> a more recent update.
> 
> I’m using the same view class for printing and screen, but I have a separate 
> view object for printing.
> 
> I’m overriding printOperation(withSettings)
> 
> This is how it works:
> 
> 1. Create the view
> 2. Set up and activate constraints
> 3. Call view.layoutSubtreeIfNeeded()
> 4. Return NSPrintOperation(view: view, printInfo: printInfo)
> 
> After (2) the view frame is empty.
> After (3) the view frame is set correctly in 10.12.6, but is empty in 10.13.2
> 
> One difference between print and screen views is that the print view doesn’t 
> have a superview, but it is constrained by its children, and I am actually 
> setting its width and height explicitly:
> 
> pageConstraints.append(NSLayoutConstraint(item: view, attribute: .width, 
> relatedBy: .equal, toItem: nil, attribute: .notAnAttribute, multiplier: 1.0, 
> constant: viewWidth))
> 
> pageConstraints.append(NSLayoutConstraint(item: view, attribute: .height, 
> relatedBy: .equal, toItem: nil, attribute: .notAnAttribute, multiplier: 1.0, 
> constant: viewHeight))
> 
> In 10.12.6, calling view.layoutSubtreeIfNeeded causes the view’s frame to be 
> set to {0, 0, viewWidth, viewHeight}
> In 10.13.2 this doesn’t happen
> 
> I can set the frame manually, but it seems wrong that I should have to do 
> this. The consequence of the frame not being set is that nothing is printed!

It seems wrong because you’re not supposed to have to set frames if you’re 
using auto layout.

> I don’t have previous versions of 10.13 that I can test on, so I don’t know 
> exactly when this got broken (or changed if it isn’t actually broken).

I think this is probably a bug in 10.13 (or 10.13.2), so maybe I should just 
file a bug report?

Unless someone can tell me why it isn’t a bug.

I can work around the problem by doing something like:

if view.frame.isEmpty
{
view.frame.origin = CGPoint(x: 0, y: 0)
view.frame.size = view.fittingSize 
}

after calling view.layoutSubtreeIfNeeded()

Jeremy

___

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: Pasteboards and NSSecureCoding

[Jeremy Hughes]

> On 20 Dec 2017, at 02:22, Jeremy Hughes  wrote:
> 
> What I don’t like about [NSArray.self] is that it’s an artefact of bridging. 
> I’m not actually using it in the encoder:
> 
> coder.encode(arrayOfInts, forKey: kArrayKey)

The declaration:

encode(_ object: Any?, forKey key: String)

seems to indicate that it encodes any object

But maybe it’s safe to assume that NSCoder will always encode/decode arrays as 
NSArrays, until it gets replaced with a Swift “Coder” class.

Jeremy

___

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: Pasteboards and NSSecureCoding

[Jeremy Hughes]

> On 20 Dec 2017, at 02:07, Quincey Morris 
>  wrote:
> 
> The class must be a kind of AnyClass, so you can’t specify a struct type. 
> Sorry I sent you off in the wrong direction on that.

That’s what I just concluded in an email I started writing.

>> The code I mentioned in my follow-up email seems to work:
>> 
>> let array = decoder.decodeObject(of: [NSArray.self], forKey: kArrayKey) as! 
>> [Int]
> 
> That will compile, but might not work. If you’re doing *secure* decoding then 
> the array of types must contain NSArray *and* the type of the elements in the 
> array. 
> 
> However, if you’re not doing secure decoding (and I don’t think you’re 
> required to, even if secure encoding was used to create the archive), then 
> [NSArray.self] should work.

It compiles and it seems to work. But, as I understand it, NSSecureCoding 
refers to decoding rather than encoding (there aren’t any special encoding 
functions) so I think I am doing secure decoding. I get an exception if I use 
an insecure decoding method, such as:

let array = decoder.decodeObject(forKey: kArrayKey) as! [Int]

What I don’t like about [NSArray.self] is that it’s an artefact of bridging. 
I’m not actually using it in the encoder:

coder.encode(arrayOfInts, forKey: kArrayKey)

Jeremy


___

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: Pasteboards and NSSecureCoding

[Quincey Morris]

> On Dec 19, 2017, at 17:38 , Jeremy Hughes  wrote:
> 
> let array = decoder.decodeObject(of: [[Int].self], forKey: kArrayKey) as! 
> [Int]
> 
> gives an error:
> 
> Cannot invoke 'decodeObject' with an argument list of type '(of: 
> [[Int].Type], forKey: String)’

The class must be a kind of AnyClass, so you can’t specify a struct type. Sorry 
I sent you off in the wrong direction on that.

> The code I mentioned in my follow-up email seems to work:
> 
> let array = decoder.decodeObject(of: [NSArray.self], forKey: kArrayKey) as! 
> [Int]

That will compile, but might not work. If you’re doing *secure* decoding then 
the array of types must contain NSArray *and* the type of the elements in the 
array. 

However, if you’re not doing secure decoding (and I don’t think you’re required 
to, even if secure encoding was used to create the archive), then 
[NSArray.self] should work.
___

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: Pasteboards and NSSecureCoding

[Jeremy Hughes]

> On 20 Dec 2017, at 01:25, Quincey Morris 
>  wrote:
> 
> You’ll have to figure out what type to use for the Ints. If they were 
> actually saved compatibly with Obj-C, the Ints will actually be NSNumbers, 
> and you’ll need to say “NSNumber.self”. If the Ints are stored opaquely as 
> Ints, I guess it would be Int.self. You should be able to figure out the 
> right type by trial and error, I’d say.
> 
> (Actually, if the array itself was saved opaquely, then you’ll need something 
> like [[Int].self], I guess. This is an area subject to automatic bridging, so 
> what you get depends on the exact code used to encode the archive.)

The array is saved as an array of Ints, not NSNumbers

coder.encode(arrayOfInts, forKey: kArrayKey)

Jeremy

___

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: Pasteboards and NSSecureCoding

[Jeremy Hughes]

Thanks, Quincey.

> That looks like Swift 3 code. The current version of the function is like 
> this:
> 
>> @nonobjc func decodeObject(of classes: [AnyClass]?, forKey key: String) -> 
>> Any?

@nonobjc means this is Swift-specfic then?

The init function I’m using is marked as @objc:

@objc required init(coder decoder: NSCoder)
{
}

> On 20 Dec 2017, at 01:25, Quincey Morris 
>  wrote:
> 
> so you’d specify [NSArray.self, .self] for the first parameter. 
> (Note, it’s a Swift-specific wrapper function, not just a direct API 
> translation.)
> 
> You’ll have to figure out what type to use for the Ints. If they were 
> actually saved compatibly with Obj-C, the Ints will actually be NSNumbers, 
> and you’ll need to say “NSNumber.self”. If the Ints are stored opaquely as 
> Ints, I guess it would be Int.self. You should be able to figure out the 
> right type by trial and error, I’d say.
> 
> (Actually, if the array itself was saved opaquely, then you’ll need something 
> like [[Int].self], I guess. This is an area subject to automatic bridging, so 
> what you get depends on the exact code used to encode the archive.)

let array = decoder.decodeObject(of: [[Int].self], forKey: kArrayKey) as! [Int]

gives an error:

Cannot invoke 'decodeObject' with an argument list of type '(of: [[Int].Type], 
forKey: String)’

The code I mentioned in my follow-up email seems to work:

let array = decoder.decodeObject(of: [NSArray.self], forKey: kArrayKey) as! 
[Int]

Presumably as! would throw an exception if it’s not an array of Ints, so that 
does get checked (and using as? with a failable initializer would presumably be 
better).

If I replace [NSArray.self] with [Array.self] I get an error:

Ambiguous reference to member 'decodeObject(of:forKey:)’

I’ve also tried [Array.self], which gives a different error:

Cannot invoke 'decodeObject' with an argument list of type '(of: 
[Array.Type], forKey: String)’

Jeremy



___

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: Pasteboards and NSSecureCoding

[Jeremy Hughes]

It seems that I can write:

let array = decoder.decodeObject(of: [NSArray.self], forKey: kArrayKey) as! 
[Int]

But shouldn't I be able to specify that this is an array of Ints, and not just 
an array of anything?

I should probably avoid force unwrapping - this ought to be a failable 
initializer, right?

Jeremy

--


> On 20 Dec 2017, at 01:09, Jeremy Hughes  wrote:
> 
> The release notes for 10.13 say:
> 
> If your application is linked on macOS 10.13 SDK or later, classes that 
> return NSPasteboardReadingAsKeyedArchive from 
> readingOptionsForType:pasteboard: must support secure coding, and will be 
> decoded with a coder that requires secure coding.
> 
> So I’m updating some of my classes to support NSSecureCoding, and I’m having 
> trouble figuring out how I should decode an array of Ints.
> 
> Previously, I had:
> 
> let array = decoder.decodeObject(forKey: kArrayKey) as! [Int]
> 
> I think that I need to replace that with something like:
> 
> let array = decoder.decodeObject(of: allowedClasses, forKey: kArrayKey) as! 
> [Int]
> 
> but I can’t work out how to define allowedClasses.
> 
> In a previous discussion, Quincey Morris wrote:
> 
>> The solution is to fall back to an explicit NSSet object:
>> 
>>  let classes = NSSet (objects: NSArray.self, MyElementClass.self)
>>  let myArray = coder.decodeObjectOfClasses (classes, forKey: “myArray”)
> 
> So I’ve tried:
> 
> let allowedClasses = NSSet(objects: NSArray.self, Int.self)
> 
> But I get an error: Cannot invoke 'decodeObject' with an argument list of 
> type '(of: NSSet, forKey: String)’
> 
> I also think there should be a way of doing this that uses Array and Set 
> rather than NSArray and NSSet
> 
> Jeremy
> 
> 

___

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: Pasteboards and NSSecureCoding

[Quincey Morris]

On Dec 19, 2017, at 17:09 , Jeremy Hughes  wrote:
> 
> In a previous discussion, Quincey Morris wrote:
> 
>> The solution is to fall back to an explicit NSSet object:
>> 
>>  let classes = NSSet (objects: NSArray.self, MyElementClass.self)
>>  let myArray = coder.decodeObjectOfClasses (classes, forKey: “myArray”)
> 
> So I’ve tried:
> 
> let allowedClasses = NSSet(objects: NSArray.self, Int.self)

That looks like Swift 3 code. The current version of the function is like this:

> @nonobjc func decodeObject(of classes: [AnyClass]?, forKey key: String) -> 
> Any?


so you’d specify [NSArray.self, .self] for the first parameter. 
(Note, it’s a Swift-specific wrapper function, not just a direct API 
translation.)

You’ll have to figure out what type to use for the Ints. If they were actually 
saved compatibly with Obj-C, the Ints will actually be NSNumbers, and you’ll 
need to say “NSNumber.self”. If the Ints are stored opaquely as Ints, I guess 
it would be Int.self. You should be able to figure out the right type by trial 
and error, I’d say.

(Actually, if the array itself was saved opaquely, then you’ll need something 
like [[Int].self], I guess. This is an area subject to automatic bridging, so 
what you get depends on the exact code used to encode the archive.)

___

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: Creating NSTableView programmatically

[Richard Charles]

> Eric Matecki - Combatants Project on GitHub
> 
> File Combatants.m
> 
> /*
>  Create and return an array of all the combatants that are not selected
>  */
> - (NSArray *) arrangeObjects: (NSArray*)iObjectsToArrange
> {
> printf("Targets::ArrangeObject()\n”);

This smells like C++ which is okay but kind of looks like you need more 
practice with Objective-C.

> unsigned int  scCount = (unsigned int)[selectedCombatants  count];
> 
> if( (scCount == 0)  ||  (selectedCombatants == nil) )
> // second test effectively redundant, but...
> {
> printf("no objects to arrange\n");
> return  [super  arrangeObjects: iObjectsToArrange];   
> }
> 
> /*
>  Create and return an array of all the combatants that are not selected
>  */

Oh dear, why are you doing this? The method arrangeObjects: returns an array 
containing objects filtered using the receiver's filter predicate and sorted 
according to the receiver’s sortDescriptors. This includes the selection. By 
excluding the selection you have changed the semantics of -[NSArrayController 
arrangeObjects:] for apparently no good reason.

> NSMutableArray*  arrangedObjects = [NSMutableArray  arrayWithCapacity: 
> [iObjectsToArrange  count] - scCount];
> 
> NSEnumerator*  objectEnumerator = [iObjectsToArrange  objectEnumerator];
> id  item;
> while( item = [objectEnumerator nextObject] )
> {
> if (![selectedCombatants  containsObject: item])
> {
> printf("%s\n", [[item  name]  UTF8String]);
> [arrangedObjects  addObject: item];
> }
> }
> return  [super  arrangeObjects: arrangedObjects];
> }

I agree with Quincey Morris, subclassing NSArrayController is generally a bad 
idea. It is apparent you need a lot more practice with Objective-C and the 
Cocoa frameworks before you should ever need to do something like this.

A great place to start is with Cocoa Programming for Mac OS X (4th Edition) by 
Aaron Hillegass if you are doing Objective-C. One of the things Aaron tells you 
right up front is “Beginning Cocoa programmers are often eager to create 
subclasses of NSString and NSMutableArray. Don’t. Stylish Objective-C 
programmers almost never do. Instead, they use NSString and NSMutableArray as 
parts of larger objects, a technique known as composition.”

I hope this helps.

--Richard Charles

___

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

Pasteboards and NSSecureCoding

[Jeremy Hughes]

The release notes for 10.13 say:

If your application is linked on macOS 10.13 SDK or later, classes that return 
NSPasteboardReadingAsKeyedArchive from readingOptionsForType:pasteboard: must 
support secure coding, and will be decoded with a coder that requires secure 
coding.

So I’m updating some of my classes to support NSSecureCoding, and I’m having 
trouble figuring out how I should decode an array of Ints.

Previously, I had:

let array = decoder.decodeObject(forKey: kArrayKey) as! [Int]

I think that I need to replace that with something like:

let array = decoder.decodeObject(of: allowedClasses, forKey: kArrayKey) as! 
[Int]

but I can’t work out how to define allowedClasses.

In a previous discussion, Quincey Morris wrote:

> The solution is to fall back to an explicit NSSet object:
> 
>   let classes = NSSet (objects: NSArray.self, MyElementClass.self)
>   let myArray = coder.decodeObjectOfClasses (classes, forKey: “myArray”)

So I’ve tried:

let allowedClasses = NSSet(objects: NSArray.self, Int.self)

But I get an error: Cannot invoke 'decodeObject' with an argument list of type 
'(of: NSSet, forKey: String)’

I also think there should be a way of doing this that uses Array and Set rather 
than NSArray and NSSet

Jeremy


___

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: Data, enumerateBytes: separate blocks?

[Quincey Morris]

On Dec 19, 2017, at 14:57 , Daryle Walker  wrote:
> 
> What are the hoops/bridges required?

I think I was referring to what Wim Lewis said, which is that you can create 
DispatchData values (or perhaps dispatch_data_t objects), but you’re going to 
have to forcibly cast from dispatch_data_t to its superclass, and then bridge 
that to Data.

However, if you’re going to the trouble of creating DispatchData values, you 
may as well use those directly, rather than bridging across to Data. The 
decision may depend on exactly which APIs you need to use to process the data.

___

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: Data, enumerateBytes: separate blocks?

[Daryle Walker]

> On Nov 28, 2017, at 3:54 PM, Quincey Morris 
>  wrote:
> 
> I believe that there is one more little piece to this that’s more recent. 
> Since (after that 10.9 change) the NSData class had to become (publicly) 
> aware that subclasses might contain discontiguous data, the opportunity arose 
> for Cocoa to leverage this in other scenarios, where dispatch_data_t (aka 
> DispatchData in Swift) wasn’t involved. That’s good in general, as a 
> performance enhancement for code that cares to enumerate the block ranges, 
> but it happens behind the scenes.
> 
> By contrast, AFAIK the only mechanism for 3rd party code to *forcibly* create 
> NSData objects with discontiguous data buffers is via 
> dispatch_data_t/DispatchData. For that reason, it might make more sense for 
> Daryle to work in the DispatchData domain rather than the plain Data domain. 
> However, as you say, there’s a bridge involving some simple hoops available 
> if necessary.

What are the hoops/bridges required?

— 
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: Creating NSTableView programmatically

[Quincey Morris]

On Dec 19, 2017, at 02:24 , Eric Matecki  wrote:
> 
> When I select a row in a NSTableView, that selection doesn't "make it" all 
> the way to update the controller...

I masochistically downloaded your project, and I think it’s a perfect example 
of why not to do this. There is so much glue code that it's impossible to tell 
whether your code is any more than locally correct (that is, beyond whether 
each line of code does what it purports to do). But all that aside…

— I think it’s a tragic mistake to subclass a NSArrayController. The class is a 
largely inscrutable black box of glue code, and any code that you add is thrown 
into the black hole. (I admit this is only an opinion. Others may love this 
kind of self-inflicted pain.)

— I think it’s *probably* a mistake to use NSArrayControllers *at all* in this 
project, where you’re trying to implement a specific UI. A NSArrayController is 
a generalized collection of behaviors intended to be used to support a large 
generality of UI designs in a NIB file. That level of generality isn’t 
necessary when you’re writing UI code directly, without using NIBs. It’s the 
equivalent of using a dictionary with string keys to represent properties, 
instead of declaring the actual properties you want.

— Your actual problem is that selection doesn’t work because you didn’t connect 
up the right pieces to make it work. For example, I fixed it for the first 
table by adding one line of code in the “buildGUI” method:

>   [combatantsTable bind: @"content"  toObject: self.combatantsController  
> withKeyPath: @"arrangedObjects"  options: 0]; // existing code
>   [combatantsTable bind: @"selectionIndexes" toObject: 
> self.combatantsController withKeyPath: @"selectionIndexes" options: 0]; // 
> added code


IOW, the array controller doesn’t know what the current selection is unless you 
tell it. I didn’t try to fix any of the other tables, but presumably they have 
the same problem.

___

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

10.13 printing problem

[Jeremy Hughes]

I have a problem printing an autolayout view in 10.13.2, and I’m wondering if 
there is something wrong with my code or if Apple broke something in 10.13 or a 
more recent update.

I’m using the same view class for printing and screen, but I have a separate 
view object for printing.

I’m overriding printOperation(withSettings)

This is how it works:

1. Create the view
2. Set up and activate constraints
3. Call view.layoutSubtreeIfNeeded()
4. Return NSPrintOperation(view: view, printInfo: printInfo)

After (2) the view frame is empty.
After (3) the view frame is set correctly in 10.12.6, but is empty in 10.13.2

One difference between print and screen views is that the print view doesn’t 
have a superview, but it is constrained by its children, and I am actually 
setting its width and height explicitly:

pageConstraints.append(NSLayoutConstraint(item: view, attribute: .width, 
relatedBy: .equal, toItem: nil, attribute: .notAnAttribute, multiplier: 1.0, 
constant: viewWidth))

pageConstraints.append(NSLayoutConstraint(item: view, attribute: .height, 
relatedBy: .equal, toItem: nil, attribute: .notAnAttribute, multiplier: 1.0, 
constant: viewHeight))

In 10.12.6, calling view.layoutSubtreeIfNeeded causes the view’s frame to be 
set to {0, 0, viewWidth, viewHeight}
In 10.13.2 this doesn’t happen

I can set the frame manually, but it seems wrong that I should have to do this. 
The consequence of the frame not being set is that nothing is printed!

I don’t have previous versions of 10.13 that I can test on, so I don’t know 
exactly when this got broken (or changed if it isn’t actually broken).

Jeremy

___

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: Creating NSTableView programmatically

[Eric Matecki]

On 19/12/2017 11:24, Eric Matecki wrote:

Hello all,

No I didn't abandon all hope, I was just busy :)

Thanks to all the replies, I got a lot further, but still didn't reach my 
destination...

Now I have a nice window, looking almost exactly like the NIB created one.

Most things works, except the most fundamental one.
When I select a row in a NSTableView, that selection doesn't "make it" all the 
way to update the controller...

The code/project is now available here : 
https://gitlab.com/CocoaMusings/Combatants

Any suggestion(s) is appreciated.

Eric M.


I just noticed that the preview in gilab doubled-up some dashes in front of 
some methods.
I checked by cloning the repo in another folder, and they aren't there...
Just a display error from gitlab.

--
Keep intel OUTSIDE my Mac !
Hiii !!! I can see Intel chips creeping around my G5 !

Eric M.
___

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: Creating NSTableView programmatically

[Eric Matecki]

Hello all,

No I didn't abandon all hope, I was just busy :)

Thanks to all the replies, I got a lot further, but still didn't reach my 
destination...

Now I have a nice window, looking almost exactly like the NIB created one.

Most things works, except the most fundamental one.
When I select a row in a NSTableView, that selection doesn't "make it" all the 
way to update the controller...

The code/project is now available here : 
https://gitlab.com/CocoaMusings/Combatants

Any suggestion(s) is appreciated.

Eric M.

--
Keep intel OUTSIDE my Mac !
Hiii !!! I can see Intel chips creeping around my G5 !

Eric M.
___

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