Back-to-front sequencing of CPViews (or use CALayers)?

[dms-scott]

Hi all,

First post, apologies in advance if I'm miss some delicate point of
cap/obj-j forum protocol :)

Playing around with the FloorPlan demo raised a curious behavior that
I'm trying to defeat.

I have noticed that when one of the FurnitureView (: CPView) objects
is nominated to be the active EditorView (: CPView) element, it gets
moved to the visible 'front' (in addition to the green selection halo,
etc).

However, on deselecting the active element (by say, clicking into the
empty apartment FloorPlanView (: CPView), the last selected object is
still the topmost visible object, hiding even elements that were
dragged into the apartment later (and having previously held the
topmost visibility).

I would like to know how to preserve this top-to-bottom layering, such
that once the selected element is deselected, it falls back behind
those objects that were previously atop it.

It occurs to me to call setNeedsDisplay:YES, on them, but even at
that, I'm not sure how to retrieve/preserve the original, intended
layer sequence.

And if the solution is "Convert the CPView types to CALayer types,"
then what is the workaround for the encodeWithCoder/initWithCoder
calls that are not available in CALayer?

Gratefully,
dms-scott

[Ross Boucher]

Actually, this was a design choice in the FloorPlan demo. It specifically chooses to move the view to the front.

See these lines in EditorView.j:

[[furnitureView superview] addSubview:self];
[[furnitureView superview] addSubview:furnitureView];

The first is adding the circular rotater dongle. The second is moving the existing furniture element forward. If you wanted to change the way this works, you could insert the editor dongle behind the existing index of the furniture view like this:

[[furnitureView superview] insertSubview:self relative:CPWindowBelow toView:furnitureView];

Which would keep the existing order intact. Alternatively, you could remember the position, and then restore it when you are finished editing.

-Ross

> --
>
> You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
> To post to this group, send email to objec...@googlegroups.com.
> To unsubscribe from this group, send email to objectivej+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/objectivej?hl=en.
>
>

[dms-scott]

Hi Ross,

Thanks for the comments on FloorPlan.

I'm interested in the latter option you suggest- capturing the
position and restoring it. Would that look something like this?

var savedIndex = [[[furnitureView superview] subviews]
indexOfObjectIdenticalTo:self];

...

[[furnitureView superview] _insertSubview:self
atIndex:savedIndex];

I've been playing around with _insertSubview: atIndex: and it's not
responding as expected. That is to say, it's not repainting the
inserted view behind the others with a higher (z-)index..

dms-scott

[dms-scott]

Hi all,

Just wanted to add my resolution to this thread:

I eventually realized while browsing some source one night that the
core of my problem was that the index passed to insertSubview:atIndex:
was actually the integer index of the CPArray of layers, NOT the raw z-
index of HTML fame. I was trying to send a specific (and inevitably
out-of-range) value to atIndex: and of course, it was just throwing it
in at index 0.

I eventually created a separate array to track my intended z-indexes,
then loop through with comparator checks to find the first one I can
call insertSubview:positioned:CPBehindWindow on:

-(BOOL)layersBehind:(CPView)aView
{
CPLog.debug("Comparing view "+ [aView name] + " to view "+ [self
name]);
if (aView == nil) return NO;
return indexZ < [aView indexZ];
}

Hopefully this performs well-enough under scale: I just didn't see
another way to insert a layer with an intended (or even relative) "z-
index"..

dms-scott