[TIMOB-775] iPhone: zIndex in constructor doesn't seem to be respected

I've tried calling animate workaround as jhaynie suggested with no luck, please advise.

   var w = Ti.UI.createWindow({backgroundColor:'#fff'});
   
   var v1 = Ti.UI.createView({backgroundColor:'blue', height:60,width:320});
   w.add(v1);
   
   var v2 = Ti.UI.createView({backgroundColor:'pink', height:50,width:300});
   w.add(v2);
   
   
   var b = Ti.UI.createButton({
       title:'open',
       top:10,
       height:40,
       width:200
   });
   
   w.add(b);
   
   b.addEventListener('click', function()
   {
       v1.animate({zindex: 1});
   });
   
   w.open();
   

Here's the same code with zindex explicitly specified for the 2 views at launch:

   var w = Ti.UI.createWindow({backgroundColor:'#fff'});
   
   var v1 = Ti.UI.createView({backgroundColor:'blue', height:60,width:320,zindex:1});
   w.add(v1);
   
   var v2 = Ti.UI.createView({backgroundColor:'pink', height:50,width:300,zindex:2});
   w.add(v2);
   
   
   var b = Ti.UI.createButton({
       title:'open',
       top:10,
       height:40,
       width:200
   });
   
   w.add(b);
   
   b.addEventListener('click', function()
   {
       v1.animate({zindex: 100});
   });
   
   w.open();
   

I'm having this issue on iOS SDK 4.0.1, TiDev 1.2.1, TiSDK 1.4.0 on both iPhone and iPad builds.

What I'm seeing is that the zIndex constructor property IS being respected but any attempt to modify it programmatically is failing (which seems the opposite of what jhaynie is describing).

When I dump the zIndex values to the debug log for the views in question, I'm seeing that the property IS being set properly just not rendering properly.

Has this been reproduced? Is there a root cause? Etc.

Trying to determine if I need to come up with a hack-around for an app that's due for testing hand-off in about 3 weeks.

Thanks!

@Jean-Etienne - Please update if you find a fix/hack-around.

@k00k: Right now the only solution I've found is to remove the zIndex'd components from their container view/window and then immediately add them back. But it's tetchy at best as I've had a couple of situations where the app freezes up after a few remove()/add() cycles and becomes completely unresponsive.

I couldn't get the animation of the zIndex to do anything.

For now I'm leaving it be... in my case I'm simulating overlapping folder tabs at the top of the UI so, the overlap can be simulated with artwork swapping if absolutely necessary... tho, that immediately makes me feel like I'm back in HTML3 table-layout land... shiver.

If I come up with something else, I'll let you know.

@jhaynie, @Nolan or @Blain: you guys have a line of sight on this?

Has there been any progress on this issue? I'm currently having to write helper methods in all of my component wrappers to do this very ugly .remove()/.add() cycling and I think it may be contributing to my app being a bit unstable. See lock-ups or UIView related crashes after remove/add processes happening fairly regularly in the simulator.

Also, I'm having to do hide/show cycling to deal with a similar issue where some components won't resize their width/height until I've hidden them, resized them and then shown them. Since this occurs quite a bit with iPad orientation changing and I have some elements that can't be left-right, top-bottom anchored (i.e. I have to explicitly resize them to make them work in the given layout) this is becoming problematic too.

Hoping to have this app out to beta testers on October 1 on iPad/iPhone deployments.

thanks,
Etienne

(from [48efc48d8a2d072fbe5347247fb3748a809cc582]) [#775 status:fixed-in-qa] [#1426 status:fixed-in-qa] [#1416 status:fixed-in-qa] zIndex sorting must happen in the parent of the view whose zIndex changed. http://github.com/appcelerator/titanium_mobile/commit/48efc48d8a2d072fbe5347247fb3748a809cc582"> http://github.com/appcelerator/titanium_mobile/commit/48efc48d8a2d0...

(from [6a5a8a1cd4fe1e05fbfcfb076d3a1bdb9238d27b]) [#775 status:fixed-in-qa] [#1426 status:fixed-in-qa] [#1416 status:fixed-in-qa] zIndex sorting must happen in the parent of the view whose zIndex changed. http://github.com/appcelerator/titanium_mobile/commit/6a5a8a1cd4fe1e05fbfcfb076d3a1bdb9238d27b"> http://github.com/appcelerator/titanium_mobile/commit/6a5a8a1cd4fe1...

@jhaynie, is this in the continuous builds? Assuming so, but wanted to ask before I test it...

And is this related to issue 1501 wherein the only way to change an objects size (w/o using an animation) is to show/hide cycle it? I'm dealing with this one specifically when resizing elements after an orientation change on iPad.

Thanks, Etienne

The Jhayne is due to automation. 'Twas me.

This fix, which as of this posting is in the continuous build, only fixes the zIndex issue.

provided code does change zindex, back to you Blain 1.5.0.62c1cae

a sample from #2183 (duped against this)

Running on master as of 10/24, zIndex seems broken.

Here's the test case. Pink should be on top.

var window = Ti.UI.createWindow();
var view1 = Ti.UI.createView({

    backgroundColor:'pink',
    zIndex:20,
    width:200,
    height:30,
    top:10,
    left:10
    

});

var view2 = Ti.UI.createView({

    backgroundColor:'blue',
    zIndex:11,
    width:200,
    height:30,
    top:15,
    left:15
    

});

var view3 = Ti.UI.createView({

    backgroundColor:'red',
    zIndex:12,
    width:200,
    height:30,
    top:20,
    left:20
    

});

window.add(view1);
window.add(view2);
window.add(view3);
window.open();

(from [483124c7082e31db4e80b3de4739f7eeb703da27]) [#2183 state:fixed-in-qa] [#775 state:fixed-in-qa] [#2092 state:fixed-in-qa] [#1426 state:fixed-in-qa] [#1416 state:fixed-in-qa] This time, zIndex is fixed for sure! Really now! Honest! http://github.com/appcelerator/titanium_mobile/commit/483124c7082e31db4e80b3de4739f7eeb703da27"> http://github.com/appcelerator/titanium_mobile/commit/483124c7082e3...

Duplicate of #2183 as per Thom, above.