Re: UIView underlying rects for drawRect

[Roland King]

> 
> CALayer has a mechanism built in for the sort of thing you want to do. Read 
> up on -[CALayer display]. You should be able to override that, or implement 
> the corresponding delegate method in your UIView and perform management of 
> your custom bitmap there. I myself do this in one app to share one bitmap 
> between multiple layers for example.
> 
> The other thing worth investigating perhaps is whether CATiledLayer would 
> better suit your drawing needs, or if you could split your custom view up 
> into a series of sub-views, so you only need invalidate slices of one or two 
> of them.
> 
> Mike.

That’s what I was just trying. I made a subclass of CALayer() and overrode just 
display() to do absolutely nothing at all, except print ‘display()’. I then 
made a UIView subclass which overrides layerClass() to return the type and 
stuck one such view randomly in my NIB. The view is made, the layer is created 
.. and absolutely nothing else happens. I expected to get at least ONE call to 
display() as the view/layer starts dirty, but I don’t get even that. I even 
hooked up a button to call setNeedsDisplay on the view but that didn’t prompt 
it either. I overrode a bunch of other methods too to print but the only one 
which currently gets called is init(). 

I expected the UIView would drive at least an initial setNeedsDisplay on the 
layer, and a setNeedsDisplay on the view would end up being passed-through, but 
it doesn’t. Calling setNeedsDisplay on the actual layer object itself seems to 
work, but I did sort of expect the UIView to do some things with the layer 
automatically. Guess I was wrong and I will need to hook all those bits up for 
myself. 
___

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 to create an empty stack view in code

[Jonathan Hull]

You can just do [[NSStackView alloc] initwithFrame:]


> On Dec 6, 2015, at 6:23 AM, Dave  wrote:
> 
> Hi All,
> 
> How do I create an Empty Stack View in code? The only method I can find that 
> that creates a Stack View is stackViewWithViews and you can’t pass nil to 
> this. Do I have to pass an empty array or can I just do [[NSStackView alloc] 
> init]; ?
> 
> All the Best
> Dave
> 
> 
> ___
> 
> 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/jhull%40gbis.com
> 
> This email sent to jh...@gbis.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: ARC and IBOutlet - strong vs weak......

[Dave]

> On 5 Dec 2015, at 17:31, Alex Zavatone  wrote:
> 
> Weak.
> 
> There is only one reference to it, right?
> 

It seems that the actual answer is “it depends”……. But making them strong 
unless you specifically need to do otherwise seems like the best practise 
approach…..

Dave




___

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 to

[Dave]

Hi All,

I have a view that is made up for a Text View and a Small Icon like so:

NSView
NSImageView
NSTextField

If the User Clicks anywhere inside the base NSView, I’d like an Perform Click 
IBAction to be sent to the connected class (The Window Controller in this 
case). In the past, on iOS i’ve done this by using a transparent UIButton that 
has the same Frame Rect and the base NSView. When I tried to do with the same 
with an NSButton, I find that I can’t change the height in IB? 

On the Mac what is the best control to use to do this?

All the Best
Dave


___

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 to create an empty stack view in code

[Dave]

Hi,

I’m not sure what to use for the Frame though? The way this is setup is that I 
have a Stack View an empty Stack View in a NIB, as so:

@property (nonatomic,strong)IBOutlet NSStackView*   pLabelMainRowStackView; 
//Vertical

There is a then a Row Array which contains Column Arrays and each item in a 
Column Array is a Dictionary that contains the data for the Corresponding View.

So in code, I create a Column (Horizontal) Stack View, Create a New View for 
the Dictionary Item and add it to the newly created Stack View. When all 
Columns in the Array have been added, add the Column Stack view to the 
pLabelMainRowStackView Stack view.

All the Best
Dave

> On 6 Dec 2015, at 15:48, Jonathan Hull  wrote:
> 
> You can just do [[NSStackView alloc] initwithFrame:]
> 
> 
>> On Dec 6, 2015, at 6:23 AM, Dave  wrote:
>> 
>> Hi All,
>> 
>> How do I create an Empty Stack View in code? The only method I can find that 
>> that creates a Stack View is stackViewWithViews and you can’t pass nil to 
>> this. Do I have to pass an empty array or can I just do [[NSStackView alloc] 
>> init]; ?
>> 
>> All the Best
>> Dave
>> 
>> 
>> ___
>> 
>> 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/jhull%40gbis.com
>> 
>> This email sent to jh...@gbis.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: ARC and IBOutlet - strong vs weak......

[Gerd Knops]

"weak" is also inherently incompatible with KVO, because no notification is 
sent when the weak reference goes away. And that'll wreak havoc, especially 
when you are using Cocoa Bindings.

Gerd

> On Dec 6, 2015, at 05:52, Dave  wrote:
> 
>> 
>> On 4 Dec 2015, at 18:04, Quincey Morris 
>>  wrote:
>> 
>> On Dec 4, 2015, at 06:16 , Dave > > wrote:
>>> 
>>> I asked about this on Twitter to an engineer on the IB team and he 
>>> confirmed that strong should be the default and that the developer docs are 
>>> being updated.
>> 
>> That sounds like a definitive answer. So you’re asking us because … why?
> 
> Because else where it says “weak” and when you create a Class where XCode 
> pre-generates outlet properties it uses weak as the attribute. Which tends to 
> suggest that they should be weak?
> 
>> Here’s how I understand the situation:
>> 
>> If you use a NSWindowController or NSViewController subclass to load the 
>> nib, the controller keeps strong references to all the top-level objects in 
>> the nib. That means all referenced objects in the nib stay alive, too — 
>> which is to say, all of them, since the nib is a hierarchy of references. 
>> (The only exceptions would be if relationships are changed directly by code, 
>> which is therefore not a good idea.)
>> 
>> So, from that point of view, it’d be fine for all outlets to be weak.
>> 
>> However, when windows close or views are swapped out, you don’t have control 
>> of the order of deallocation of the controllers, which means that the owner 
>> of an outlet may see the outlet go to nil if the controller is deallocated 
>> first.
>> 
>> If the outlet owner can tolerate its outlets becoming nil, then that’s fine 
>> too, and the outlets can be weak.
>> 
>> But sometimes is tricky to handle this without crashes. (That’s why, for 
>> example, it’s often useful to nil out the ‘delegate' property of some object 
>> that’s using the outlet owner. It prevents delegate methods being called and 
>> possible using a stale or nil reference to something.) It’s easier to make 
>> the outlets strong — not to keep them alive generally, but specifically to 
>> keep them alive as long as their owner.
>> 
>> That’s an easy answer, but if that happens to cause retain cycles, then you 
>> need to find a solution to *that* problem, which might be using a weak 
>> outlet after all, or dealing with the situation in some other. (Nil-ing out 
>> a strong delegate property also helps with this problem, often.)
>> 
>> Summary: it’s not so very complicated, but there’s no single answer that 
>> always works. "Always making your outlets strong, except when you are 
>> solving a reference cycle", sounds like a good rule of thumb.
>> 
> 
> Thanks for the brilliant explanation and I agree making them strong unless 
> they need to be otherwise seems like a good rule of thumb.
> 
> All the Best
> Dave
> 
> ___
> 
> 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/gerti-cocoadev%40bitart.com
> 
> This email sent to gerti-cocoa...@bitart.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

How to create an empty stack view in code

[Dave]

Hi All,

How do I create an Empty Stack View in code? The only method I can find that 
that creates a Stack View is stackViewWithViews and you can’t pass nil to this. 
Do I have to pass an empty array or can I just do [[NSStackView alloc] init]; ?

All the Best
Dave


___

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

Sheet segue from menu in OS X?

[Rick Mann]

Is it possible to have a sheet segue from a menu that's triggered on the 
current NSDocument subclass? Or do I have to do it old school with a message 
sent to first responder? My document can have more than one window.

TIA,


-- 
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: UIView underlying rects for drawRect

[Roland King]

> On 6 Dec 2015, at 20:18, Roland King  wrote:
> 
> 
>> 
>> CALayer has a mechanism built in for the sort of thing you want to do. Read 
>> up on -[CALayer display]. You should be able to override that, or implement 
>> the corresponding delegate method in your UIView and perform management of 
>> your custom bitmap there. I myself do this in one app to share one bitmap 
>> between multiple layers for example.
>> 
>> The other thing worth investigating perhaps is whether CATiledLayer would 
>> better suit your drawing needs, or if you could split your custom view up 
>> into a series of sub-views, so you only need invalidate slices of one or two 
>> of them.
>> 
>> Mike.
> 
> That’s what I was just trying. I made a subclass of CALayer() and overrode 
> just display() to do absolutely nothing at all, except print ‘display()’. I 
> then made a UIView subclass which overrides layerClass() to return the type 
> and stuck one such view randomly in my NIB. The view is made, the layer is 
> created .. and absolutely nothing else happens. I expected to get at least 
> ONE call to display() as the view/layer starts dirty, but I don’t get even 
> that. I even hooked up a button to call setNeedsDisplay on the view but that 
> didn’t prompt it either. I overrode a bunch of other methods too to print but 
> the only one which currently gets called is init(). 
> 
> I expected the UIView would drive at least an initial setNeedsDisplay on the 
> layer, and a setNeedsDisplay on the view would end up being passed-through, 
> but it doesn’t. Calling setNeedsDisplay on the actual layer object itself 
> seems to work, but I did sort of expect the UIView to do some things with the 
> layer automatically. Guess I was wrong and I will need to hook all those bits 
> up for myself. 

ok I begin to see how it all works now. So if the layer is the view’s layer, 
instead of a separate totally custom layer you add to the layer, then the view 
sets some things on it but not everything. It turns off 
needsDisplayOnBoundsChange (which I had set on init in the layer) unless the 
view’s contentMode is redraw, which somewhat confused me. That causes the layer 
to call display() on itself on bounds change. However it doesn’t pass 
setNeedsDisplay() and setNeedsDisplayInRect() through to the underlying layer 
which I’d have expected. I assume it only calls those that if the layer is a 
normal UIView layer and not a custom one. 

I think as long as that’s the extent of its meddling with ‘its layer’, just 
setting a few properties when it starts up and adjusting the bounds for me, I 
can live with it. I’ll try out a few more things on the view to see if there 
are other things I need to be prepared to deal with, just having it manage the 
layer bounds automatically is helpful if that’s about all it does. 


___

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: ARC and IBOutlet - strong vs weak......

[Dave]

> On 4 Dec 2015, at 18:04, Quincey Morris  
> wrote:
> 
> On Dec 4, 2015, at 06:16 , Dave  > wrote:
>> 
>> I asked about this on Twitter to an engineer on the IB team and he confirmed 
>> that strong should be the default and that the developer docs are being 
>> updated.
> 
> That sounds like a definitive answer. So you’re asking us because … why?

Because else where it says “weak” and when you create a Class where XCode 
pre-generates outlet properties it uses weak as the attribute. Which tends to 
suggest that they should be weak?

> Here’s how I understand the situation:
> 
> If you use a NSWindowController or NSViewController subclass to load the nib, 
> the controller keeps strong references to all the top-level objects in the 
> nib. That means all referenced objects in the nib stay alive, too — which is 
> to say, all of them, since the nib is a hierarchy of references. (The only 
> exceptions would be if relationships are changed directly by code, which is 
> therefore not a good idea.)
> 
> So, from that point of view, it’d be fine for all outlets to be weak.
> 
> However, when windows close or views are swapped out, you don’t have control 
> of the order of deallocation of the controllers, which means that the owner 
> of an outlet may see the outlet go to nil if the controller is deallocated 
> first.
> 
> If the outlet owner can tolerate its outlets becoming nil, then that’s fine 
> too, and the outlets can be weak.
> 
> But sometimes is tricky to handle this without crashes. (That’s why, for 
> example, it’s often useful to nil out the ‘delegate' property of some object 
> that’s using the outlet owner. It prevents delegate methods being called and 
> possible using a stale or nil reference to something.) It’s easier to make 
> the outlets strong — not to keep them alive generally, but specifically to 
> keep them alive as long as their owner.
> 
> That’s an easy answer, but if that happens to cause retain cycles, then you 
> need to find a solution to *that* problem, which might be using a weak outlet 
> after all, or dealing with the situation in some other. (Nil-ing out a strong 
> delegate property also helps with this problem, often.)
> 
> Summary: it’s not so very complicated, but there’s no single answer that 
> always works. "Always making your outlets strong, except when you are solving 
> a reference cycle", sounds like a good rule of thumb.
> 

Thanks for the brilliant explanation and I agree making them strong unless they 
need to be otherwise seems like a good rule of thumb.

All the Best
Dave

___

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: UIView underlying rects for drawRect

[Mike Abdullah]

> On 6 Dec 2015, at 01:50, Roland King  wrote:
> 
> You thought CGContext had it, I thought CALayer had it, neither of them 
> appear to have it! 
> 
> AFAICT UIView is clearing the entire rectangle before drawing, so that idea 
> doesn’t work either. That was a good way to confirm I was on the wrong road 
> so thanks.

Aha, that is very interesting to know.
> 
> So I implemented the code to capture setNeedsDisplayInRect(), drawRect() etc 
> and ensure only one contiguous rectangle goes to the setNeedsDisplayInRect at 
> a time, if there’s another one it waits until drawRect() finishes and then 
> queues that one up. The results were good until they weren’t and I’m really 
> at a loss to explain some of the oddities I saw. It was never going to be 
> stable enough for real use so that idea got tossed. 
> 
> Current workaround it not to take things off the back, it’s history, I don’t 
> really care, and the code moves the view along anyway so it quickly gets 
> clipped and every few minutes the view is moved to a new chunk of data (it’s 
> like a horizontal scroll view where only 1.5 screens wide of data is shown at 
> a time which are incrementally drawn and then moved to a new chunk every few 
> minutes with one single redraw). 
> 
> I think a better plan for this whole thing is to use a CALayer with a 
> persistent bitmap for the graph I’m drawing. 
> 
> Currently I’m seeing a new point come in, working out what that is in view 
> coordinates, calling setNeedsDisplayinRect() on that, then in drawRect I’m 
> converting back to time coordinates, padding out each side so I definitely 
> redraw the whole area cleared including the fuzzy edges of lines a point or 
> two over on the display, then drawing. This is probably nowhere near as 
> efficient as possible. 
> 
> If I use a CALayer with a bitmap I can put a point on the bitmap 
> asynchronously as soon as it comes in, one point, or one tiny line segment 
> from the previous point, I can do my own clearing when they expire and then 
> all I have to do is arrange the bitmap to be blitted onto the CALayer’s 
> content on a regular basis for update and sort out some full redraw stuff on 
> bounds change stuff. 
> 
> What’s the right way to synchronise the update of the content property of a 
> CALayer? I could do it every time I add a point, but that sounds a bit 
> unnecessary. Is this where I use CADisplayLink? Is there a recommended format 
> for the bitmap which eases the work the CPU/GPU has to do to transfer it to 
> and from the layer? 8 bit with alpha is all I really need for the plot but if 
> that’s going to trigger a huge conversion every time it’s run through 
> CGBitmapContextCreateImage() and stuffed on the layer I’ll use something 
> else. 

CALayer has a mechanism built in for the sort of thing you want to do. Read up 
on -[CALayer display]. You should be able to override that, or implement the 
corresponding delegate method in your UIView and perform management of your 
custom bitmap there. I myself do this in one app to share one bitmap between 
multiple layers for example.

The other thing worth investigating perhaps is whether CATiledLayer would 
better suit your drawing needs, or if you could split your custom view up into 
a series of sub-views, so you only need invalidate slices of one or two of them.

Mike.
___

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: ARC and IBOutlet - strong vs weak......

[Britt Durbrow]

Your reference is weak, old man… oh, wait, that’s kung-fu…. um….


Seriously - I always make my references strong unless I have a good reason not 
to (avoiding retain cycles is one such good reason). Weak references, while 
nice for what they do, do have some overhead and other drawbacks (like the lack 
of KVO compliance Gerd Knops mentioned).


> On Dec 6, 2015, at 7:15 AM, Dave  wrote:
> 
> 
>> On 5 Dec 2015, at 17:31, Alex Zavatone  wrote:
>> 
>> Weak.
>> 
>> There is only one reference to it, right?
>> 
> 
> It seems that the actual answer is “it depends”……. But making them strong 
> unless you specifically need to do otherwise seems like the best practise 
> approach…..
> 
> Dave
> 
> 
> 
> 
> ___
> 
> 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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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: How to

[Graham Cox]

> On 7 Dec 2015, at 2:45 AM, Dave  wrote:
> 
> On the Mac what is the best control to use to do this?


Just override -mouseDown: in the view and call [NSApp sendAction:toTarget:from:]



___

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: Need Help with Swift

[Stevo Brock]

So, as it turns out, when I went to start “cleaning things up”, things started 
to get ugly again.  In the end, given some other small design changes and the 
crazy amounts of time this was sucking up, I ended up just ripping it all out 
and going with straight-up classes and just subclassing and duplicating as 
necessary.

Thanks everyone for all your help.

-Stevo Brock
 Sunset Magicwerks, LLC
 www.sunsetmagicwerks.com
 818-478-9758

> On Dec 4, 2015, at 12:12 AM, Roland King  wrote:
> 
> 
>> On 4 Dec 2015, at 16:07, Stevo Brock  wrote:
>> 
>> This seems to do the trick.
>> 
>> I wasn’t able to just do ABC.class, as the “.class” wasn’t registered as 
>> valid.
>> 
>> What I ended up with was a static method on the class, and calling the 
>> static method, and voilà! Everything is working.
>> 
>> So now to clean things up…
>> 
>> Thanks guys so much for your help.  
> 
> well that’s just a whole bunch of ugly. Before you get TOO far, try and 
> optimized release build, make sure it doesn’t go optimize that out and break 
> it all again. You know these compilers love to leave the best until last.


___

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