On 4/25/13 6:35 PM, "Rick Mann" wrote:
>On Apr 25, 2013, at 18:30 , Charles Srstka
>wrote:
>
>> Pinning *is* what you want. Do each of "Pin Leading/Trailing/Top/Bottom
>>Edge To Superview", and then the height and width constraints should
>>become deletable.
>
>Sorry, I misunderstood. Yes, I had
On Apr 25, 2013, at 8:35 PM, Rick Mann wrote:
> On Apr 25, 2013, at 18:30 , Charles Srstka wrote:
>
>> Pinning *is* what you want. Do each of "Pin Leading/Trailing/Top/Bottom Edge
>> To Superview", and then the height and width constraints should become
>> deletable.
>
> Sorry, I misundersto
On Apr 25, 2013, at 18:30 , Charles Srstka wrote:
> Pinning *is* what you want. Do each of "Pin Leading/Trailing/Top/Bottom Edge
> To Superview", and then the height and width constraints should become
> deletable.
Sorry, I misunderstood. Yes, I had already pinned the
Leading/Trailing/Top/Bo
On Apr 25, 2013, at 6:50 PM, Rick Mann wrote:
> No, pinning is not what I want. That's what I'm trying to avoid. IB in
> insisting on pinning the width and the height.
>
> I think it assumes the NSImageWell MUST have a static size, rather than allow
> it to resize. I'm able to put an NSView wi
IB adds constraints to both the NSImageView and its superview. I believe
that this is why deleting a constraint causes it to come back (it's in two
views).
Here's what I recommend:
- Delete the NSImageView which will also delete the associated constraints.
- Drag a new NSImageView to the window (i
On 26/04/2013, at 12:07 AM, James Montgomerie wrote:
> If you have quite simple requirements, a CAShapeLayer might work.
I found that CAShapeLayer is not very good when it is scaled up significantly,
e.g. in a view that gets zoomed by more than 4x or so. It depends on its size -
because th
No, pinning is not what I want. That's what I'm trying to avoid. IB in
insisting on pinning the width and the height.
I think it assumes the NSImageWell MUST have a static size, rather than allow
it to resize. I'm able to put an NSView without this problem.
On Apr 25, 2013, at 16:48 , Caylan L
I put an NSImageView into a window. I want the NSImageView's frame to always
fill the window content frame.
When I dropped it in, IB gave it a width and height constraint that I can't
edit. I sized it to fit the window, and it also added leading and trailing
space constraints.
I explicitly set
On Apr 25, 2013, at 1:32 PM, Oleg Krupnov wrote:
> All in all I come to personally find delegates more elegant and honest than
> blocks for callbacks. Am I alone here? :)
Possibly. :)
> I always find it more difficult to read code with blocks, because it takes me
> an effort to understand the
I ran into a very similar problem. Recently, I put my view hierarchy into
an NSTabView. When it's in the inactive tab, I get lots of "Unable to
simultaneously satisfy constraints" errors. When the view hierarchy is in
the active tab, there are no errors. I use auto layout in most of my views
accept
Hi Jens,
On Apr 25, 2013, at 18:10 , Jens Alfke wrote:
> On Apr 25, 2013, at 1:20 AM, Oleg Krupnov wrote:
>
>> This breaks encapsulation of objects with block properties (e.g.
>> MyAnimation.completionBlock)
>
> I understand the problem you're describing (and yes, I've had a couple of
> memo
>
> On the other hand, delegates add the problem that they desiccate the code for
> dealing with the results from the code for setting up the request in the
> first place. I would consider that a much much much higher penalty than
> having to a bit careful about retain cycles.
>
You are cor
> I understand the problem you're describing (and yes, I've had a couple of
> memory leaks resulting from it) but I don't understand how you think it's
> breaking encapsulation.
The encapsulation is broken by the fact that you can't place whatever code you
need in the callback block and have t
On 25 Apr 2013, at 20:48, Oleg Krupnov wrote:
>
>
> Yes, this is jumping through hoops, and even then you are not entirely safe.
> How about referencing ivars from blocks? How about referencing other objects
> that may in their turn reference self etc.? You have to keep it all in mind
> and
Yes, this is jumping through hoops, and even then you are not entirely safe.
How about referencing ivars from blocks? How about referencing other objects
that may in their turn reference self etc.? You have to keep it all in mind and
constantly fight with the side-effects by adding more crappy
On 25 Apr 2013, at 18:35, Lee Ann Rucker wrote:
>> It's easier to just use the __weak attribute, if you're using ARC:
>
> Ah, so that's when you get to use it. Well, a couple hundred files written
> over the course of 7 years isn't going to be ARC any time soon, nice as it
> might be.
Luck
On Apr 25, 2013, at 10:21 , Kevin Perry wrote:
> Actually no—autosaving-in-place means exactly that changes are always saved
> to the main document file, hence "in place". There is only ever a single file
> per document, even when quitting.
Oops, I obviously got too focused on the "autosave el
> It's easier to just use the __weak attribute, if you're using ARC:
Ah, so that's when you get to use it. Well, a couple hundred files written over
the course of 7 years isn't going to be ARC any time soon, nice as it might be.
___
Cocoa-dev mailing
Figured there must be something like that :) We have complicated reasons for
doing it with classes (C++ is involved) and since I'm at home hitting reload on
the WWDC ticket site I don't have the docs available.
- Original Message -
From: "Torsten Curdt"
To: "Lee Ann Rucker"
Cc: "Oleg
On Apr 25, 2013, at 9:54 AM, Lee Ann Rucker wrote:
> MyWeakRef *weakRef = [MyWeakRef weakRefFromObject:self];
>
> ^() = {
> Foo *wself = [weakRef originalObject];
> // wself may be nil, that's cool because we only want to doStuff if 'self'
> is still around.
> [wself doStuff];
> }
It's eas
> MyWeakRef *weakRef = [MyWeakRef weakRefFromObject:self];
>
> ^() = {
> Foo *wself = [weakRef originalObject];
> // wself may be nil, that's cool because we only want to doStuff if 'self'
> is still around.
> [wself doStuff];
> }
How is that different from
__typeof__(self) __weak wself
On Apr 25, 2013, at 10:05 AM, Quincey Morris
wrote:
>> I can't begin to count the number of times I've opened documents, edited
>> them in some way, not intending to save those changes. Maybe I just needed
>> to, say, find an image in a particular layer of some image editing app, so I
>> hid
On Apr 25, 2013, at 09:10 , Steve Mills wrote:
> Saving in place is not something most users expect, because it hasn't been
> done that way on all the common platforms.
Uh, you can't make statements like that without citing evidence. Have you
surveyed most users on this point? There are plenty
> My point remains: blocks are dangerous and there is no easy way to
> ensure they are safe. You can't avoid referencing "self" in blocks,
> because it is the very point of almost every callback block. So you
> have to every time to remind yourself to jump through hoops to avoid
> the retain cycle
On Apr 25, 2013, at 7:10 AM, Pax <45rpmli...@googlemail.com> wrote:
> I am writing a program that I hope to get into the App Store. During
> testing, all went well - no errors, no crashes, nothing to be concerned
> about. Having Archived it, and exported a Developer ID-signed Application
> (
On 24 Apr, 2013, at 21:46 , Antonio Nunes wrote:
> I have an NSSearchField, and a menu bar submenu with the standard Find items.
> When the search field receives some input, it performs its action and an
> array controller is filled with search results. Now, while the search field
> is the fir
On Apr 25, 2013, at 1:20 AM, Oleg Krupnov wrote:
> This breaks encapsulation of objects with block properties (e.g.
> MyAnimation.completionBlock)
I understand the problem you're describing (and yes, I've had a couple of
memory leaks resulting from it) but I don't understand how you think it's
On Apr 25, 2013, at 11:01:08, Jerry Krinock
wrote:
> "PDFpen 6.0.2 is now available from Smile. This update includes an option to
> turn off autosave and versions."
Good. More apps need to offer that ability.
> H. Two bug fixes after Autosave and Versions was adopted with great
> fanfa
On 2013 Apr 24, at 11:38, Steve Mills wrote:
> Like the way TextEdit does it; you see the change take place, but then it
> instantly blinks back to the way it was before. It's *very* un-Mac-like and
> feels extremely half-baked.
On the contrary, I would suspect that it has been fully baked t
Using blocks with ARC just requires more discipline, that's all. It isn't
to be avoided, just carefully thought about at the appropriate times.
On Thu, Apr 25, 2013 at 6:07 AM, Oleg Krupnov wrote:
> The compiler indeed warns, but only for ARC projects, and for non-ARC
> projects it perfectly all
Forgive me for having two questions in flight at once. This is an entirely
separate issue - and this might not even be the right forum for it. I can't
find a sandbox / app store forum to ask though.
My app should be able to launch itself at start up - but the helper app doesn't
seem to work.
If you have quite simple requirements, a CAShapeLayer might work.
You'll need to create a CGPath to give it to render. On iOS, UIBezierPath can
help with creating the CGPath if you don't want to drop to the CGPath API (no
such luck on Mac - NSBezierPath can't be trivially converted to a CGPath
Have you looked at CorePlot ?
Sent from my iPhone
On 2013/04/25, at 22:50, Marcel Weiher wrote:
>> So I was looking for a graphics library in the Developer Docs that serves
>> both Mac-Apps and iOS-Apps.
>>
>> I found references to polylines in a MapKit.
>> There is of course Quartz2D and O
> So I was looking for a graphics library in the Developer Docs that serves
> both Mac-Apps and iOS-Apps.
>
> I found references to polylines in a MapKit.
> There is of course Quartz2D and OpenGL.
>
> So which of these libraries or perhaps there is another I have not heard of
> yet is best at
I am writing a program that I hope to get into the App Store. During testing,
all went well - no errors, no crashes, nothing to be concerned about. Having
Archived it, and exported a Developer ID-signed Application (for further
testing), I find myself facing a rather annoying problem. My prog
The compiler indeed warns, but only for ARC projects, and for non-ARC
projects it perfectly allows blocks to create retain cycles without
any warnings, even Xcode's Analyze doesn't help.
Besides, I'm afraid the compiler is not always capable to detect all
such dangerous situations even with ARC on
On 25 Apr 2013, at 11:40, Diederik Meijer | Ten Horses
wrote:
> I don't agree, blocks are very powerful.
>
> I am using Xcode 4.6 and in a project that uses ARC it was throwing warnings
> when a block reference to a property caused a retain cycle. This is how I
> found it and why I mentioned
I don't agree, blocks are very powerful.
I am using Xcode 4.6 and in a project that uses ARC it was throwing warnings
when a block reference to a property caused a retain cycle. This is how I found
it and why I mentioned it in another thread in the first place.
I haven't tested it extensively,
On 25 Apr 2013, at 09:34, Oleg Krupnov wrote:
> Tom, I disagree, because unlike other objects with strong refs, or say
> @property(retain), the strong refs in blocks are created implicitly
> and it's just too easy to let them slip out of attention. There is no
> direct command to create the stro
Tom, I disagree, because unlike other objects with strong refs, or say
@property(retain), the strong refs in blocks are created implicitly
and it's just too easy to let them slip out of attention. There is no
direct command to create the strong ref, unlike @property(retain). All
you do is *mention*
On 25 Apr 2013, at 09:20, Oleg Krupnov wrote:
> Blocks in Obj-C seem convenient and powerful but in fact they are very
> dangerous because they retain all objects referenced from the block
> and thereby can implicitly create circular references.
>
> If you are not vigilant about every object yo
Blocks in Obj-C seem convenient and powerful but in fact they are very
dangerous because they retain all objects referenced from the block
and thereby can implicitly create circular references.
If you are not vigilant about every object you mention in the block,
you can create one, two or more cyc
42 matches
Mail list logo
