Re: Value of type '[AnyObject]!' has no member 'Generator'
> On 4 Oct 2015, at 13:48, Rick Mann wrote:
>
> Why won't this compile?
>
> let devices = AVCaptureDevice.devices() // OKAY
> for device in devices
> {
> print("Device: \(device)")
>
> for f in device.formats // no member "Generator"
> {
> print(" format: \(f)")
> }
> }
>
> Each of the loops' collections is of type [AnyObject]! But for the
> device.formats, I get
>
> AppDelegate.swift:25:13: Value of type '[AnyObject]!' has no member
> 'Generator'
>
> Also, command-clicking on device() takes me to a Swift interface file.
> Command-clicking on formats takes me to an Objective-C header.
>
> If I put a ! after device.formats, it compiles.
>
> --
> Rick Mann
> rm...@latencyzero.com
>
Apply the usual swift technique and break it down into more than one line then
go look at the types of each variable.
let ff = device.formats
let pp = ff!
option-click on each of those variables and you’ll quickly see the ‘!!’ on the
first one and hence why you have to explicitly unwrap it to get it into a
[AnyObject] which has a generator.
___
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
Value of type '[AnyObject]!' has no member 'Generator'
Why won't this compile?
let devices = AVCaptureDevice.devices() // OKAY
for device in devices
{
print("Device: \(device)")
for f in device.formats // no member "Generator"
{
print(" format: \(f)")
}
}
Each of the loops' collections is of type [AnyObject]! But for the
device.formats, I get
AppDelegate.swift:25:13: Value of type '[AnyObject]!' has no member
'Generator'
Also, command-clicking on device() takes me to a Swift interface file.
Command-clicking on formats takes me to an Objective-C header.
If I put a ! after device.formats, it compiles.
--
Rick Mann
rm...@latencyzero.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: NSView - trouble setting next responder on 10.10 - works okay on 10.9
On Oct 3, 2015, at 07:42 , Jonathan Mitchell wrote: > > The responder chain is, as you know, very flexible. I’m not accusing you of mistreating the responder chain, I’m accusing you of mistreating event handling. :) Event handling is based on the idea of hierarchical containment, so that a view controller is expected to handle only actions from its own view’s sub-hierarchy. You’re trying to route actions from elsewhere into the view controller “container”. (iOS already has this concept of view controller containment, that parallels the view containment hierarchy.) I suggest you consider breaking your view controllers apart into two objects. One, a “view responder” would be a NSResponder subclass that you insert into the responder chain just below the window controller. The other, an actual NSViewController subclass, would be inserted into the responder chain wherever the frameworks want, or possibly not at all pre-10.10. Ideally, all of the business logic would be moved from its current home in the view controller to the view responder, including the action messages. All that’d be left in the view controller would be the outlets (if any), and the viewDidLoad logic necessary to prepare the view itself (and also to create the view responder, and insert it in the responder chain). Alternatively, you could keep all the local-to-view logic in the view controller, and put only the trans-view logic in the view responder, but this may get a bit messy if both share the same custom data structures. This shouldn’t involve much change to existing code. Each object in the pair would have a reference to the other. Except for the responder chain setup, the main difference in code would be that your view responder would reference outlets as self.viewController.myOutlet, instead of self.myOutlet. If you have view controller bindings in the NIBs, you can change them to bind through to the view responder, or (if there are too many to change) define derived properties in the view controller that mirror the real properties in the view responder. ___ 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: NSView - trouble setting next responder on 10.10 - works okay on 10.9
> On 3 Oct 2015, at 03:40, Quincey Morris > wrote: > > On Oct 2, 2015, at 15:03 , Jonathan Mitchell wrote: > > “When a view is assigned” sounds to me an awful lot like “when > [NSViewController setView:] is called”. You might have more success moving > the super call to the beginning of your method, if you haven’t tried that > already. Moving the call site makes no difference. The posted code is padded out with test logic. > > At a different level, though, I’d recommend you don’t do what you’re doing. > My Apple tea-leaf reading instincts tell me that pretty soon you won’t have > the choice of where to insert the view controller in the responder chain, so > your methodology may not have long term survival prospects. I would say this has occurred already. Looks as if you cannot reassign an 10.10 NSViewController -view’s next responder. > > Unfortunately, the problem you’re trying to solve is awkward to deal with. > Your intention makes perfect sense, but it happens to be in direct conflict > with the design of the responder chain. Your solution only works if there’s > only *one* view controller (for a given action message) below the window > controller. If there were multiple candidate view controllers, it’d be > ambiguous which one should receive the action vs. which one would receive it. > If there’s only one candidate, it’s straightforward for the window controller > to know or be told which view controller handles which action message. The responder chain is, as you know, very flexible. I used the FOSS XSViewController component to manage the responder chain. This has a distinct design, placing the view controller responders above the views and below the window. It has worked well for me and you can choose which controllers to insert into the the chain and which to omit, It however looks like it really doesn’t fly with the 10.10+ NSViewController changes. > I think you’re better off, long term, in simply putting the/an action method > in the window controller, and letting the window controller call the view > controller action method directly. (You’d also need the view controller to > have a ‘canDoAction’ method, so that the window controller could query it > during interface validation, if you want to keep your view controller logic > partitioned neatly.) The target app is basically a form processor and has ~300 nibs swapping in and out of a single document window. The view hierarchy is just too deep to let the window controller redirect the actions. Plus I have used the responder chain in preference to a constructing a second network of -delegate references (a custom action sender class enables interaction between the action sender and the eventual action receiver). Ahh well, looks like there might some bullet biting ahead… Thanks for the FWIW J ___ 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
