I’ve arrived at a solution that appears to work, although there is still an
element I do not understand. First I corrected some calculation errors, so that
the view sizes/centres/margins are now always calculated correctly, but that’s
not the point. The issue was that after zooming the container
On 5 Apr 2014, at 12:40 am, Keary Suska wrote:
> I came across a situation of using undo with sets and it seemed like I needed
> some extra tests to implement undo properly.
Maybe a set isn't the right model? Either an object is a member or it isn't -
Undo should maintain that correctly on a
On Apr 3, 2014, at 8:22 PM, Varun Chandramohan
wrote:
> Interestingly, the static code analysis find the call of "retain" as a leak.
> How do I address this issue? What is correct way to rewrite this code to make
> static analyser understand that I will be releasing the resource? If I
> remove
On 2014 Apr 04, at 06:40, Keary Suska wrote:
> is Core Data smart enough to do these tests itself for undo support, or
> should I do these tests myself before calling willchange/didchange?
I think the answer is “yes”. I’ve used Core Data with trees in complicated
object graphs and never done
Hi have a view that contains another view. The containerview (parent) can be
scaled. The scaling is done by settings scaleUnitSquareToSize to the
appropriate value. I’m trying to keep the contained view (subview, or content
view) centred in the containerview. When the scale of the containerview
I came across a situation of using undo with sets and it seemed like I needed
some extra tests to implement undo properly. For instance, testing for the
existence of an object before adding, since it seems like the undo will remove
the existing object and lead to hard-to-identifty bugs.
So then
