{ "id": "61407", "key": "TIMOB-775", "fields": { "issuetype": { "id": "1", "description": "A problem which impairs or prevents the functions of the product.", "name": "Bug", "subtask": false }, "project": { "id": "10153", "key": "TIMOB", "name": "Titanium SDK/CLI", "projectCategory": { "id": "10100", "description": "Titanium and related SDKs used in application development", "name": "Client" } }, "fixVersions": [ { "id": "11225", "name": "Release 1.5.0", "archived": true, "released": true, "releaseDate": "2010-12-14" } ], "resolution": { "id": "3", "description": "The problem is a duplicate of an existing issue.", "name": "Duplicate" }, "resolutiondate": "2011-04-15T02:36:12.000+0000", "created": "2011-04-15T02:36:07.000+0000", "priority": { "name": "Low", "id": "4" }, "labels": [ "ios", "iphone", "rplist", "zindex" ], "versions": [], "issuelinks": [], "assignee": { "name": "jhaynie", "key": "jhaynie", "displayName": "Jeff Haynie", "active": false, "timeZone": "America/Los_Angeles" }, "updated": "2017-03-03T05:36:12.000+0000", "status": { "description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.", "name": "Closed", "id": "6", "statusCategory": { "id": 3, "key": "done", "colorName": "green", "name": "Done" } }, "components": [ { "id": "10206", "name": "iOS", "description": "iOS Platform" } ], "description": "{html}
if you call it later in animate, works but if you put in\nconstructor, seems to be ignored.
I've tried calling animate workaround as jhaynie suggested with\nno luck, please advise.
\n\nvar w = Ti.UI.createWindow({backgroundColor:'#fff'});\n\nvar v1 = Ti.UI.createView({backgroundColor:'blue', height:60,width:320});\nw.add(v1);\n\nvar v2 = Ti.UI.createView({backgroundColor:'pink', height:50,width:300});\nw.add(v2);\n\n\nvar b = Ti.UI.createButton({\n title:'open',\n top:10,\n height:40,\n width:200\n});\n\nw.add(b);\n\nb.addEventListener('click', function()\n{\n v1.animate({zindex: 1});\n});\n\nw.open();
\n
Here's the same code with zindex explicitly specified for the 2\nviews at launch:
\n\nvar w = Ti.UI.createWindow({backgroundColor:'#fff'});\n\nvar v1 = Ti.UI.createView({backgroundColor:'blue', height:60,width:320,zindex:1});\nw.add(v1);\n\nvar v2 = Ti.UI.createView({backgroundColor:'pink', height:50,width:300,zindex:2});\nw.add(v2);\n\n\nvar b = Ti.UI.createButton({\n title:'open',\n top:10,\n height:40,\n width:200\n});\n\nw.add(b);\n\nb.addEventListener('click', function()\n{\n v1.animate({zindex: 100});\n});\n\nw.open();
\n
I'm having this issue on iOS SDK 4.0.1, TiDev 1.2.1, TiSDK 1.4.0\non both iPhone and iPad builds.
\nWhat I'm seeing is that the zIndex constructor property IS being\nrespected but any attempt to modify it programmatically is failing\n(which seems the opposite of what jhaynie is describing).
\nWhen I dump the zIndex values to the debug log for the views in\nquestion, I'm seeing that the property IS being set properly just\nnot rendering properly.
\nHas this been reproduced? Is there a root cause? Etc.
\nTrying to determine if I need to come up with a hack-around for\nan app that's due for testing hand-off in about 3 weeks.
\nThanks!
@Jean-Etienne - Please update if you find a fix/hack-around.
@k00k: Right now the only solution I've found is to remove the\nzIndex'd components from their container view/window and then\nimmediately add them back. But it's tetchy at best as I've had a\ncouple of situations where the app freezes up after a few\nremove()/add() cycles and becomes completely unresponsive.
I couldn't get the animation of the zIndex to do anything.
\nFor now I'm leaving it be... in my case I'm simulating\noverlapping folder tabs at the top of the UI so, the overlap can be\nsimulated with artwork swapping if absolutely necessary... tho,\nthat immediately makes me feel like I'm back in HTML3 table-layout\nland... shiver.
\nIf I come up with something else, I'll let you know.
\n@jhaynie, @Nolan or @Blain: you guys have a line of sight on\nthis?
Has there been any progress on this issue? I'm currently having\nto write helper methods in all of my component wrappers to do this\nvery ugly .remove()/.add() cycling and I think it may be\ncontributing to my app being a bit unstable. See lock-ups or UIView\nrelated crashes after remove/add processes happening fairly\nregularly in the simulator.
\nAlso, I'm having to do hide/show cycling to deal with a similar\nissue where some components won't resize their width/height until\nI've hidden them, resized them and then shown them. Since this\noccurs quite a bit with iPad orientation changing and I have some\nelements that can't be left-right, top-bottom anchored (i.e. I have\nto explicitly resize them to make them work in the given layout)\nthis is becoming problematic too.
\nHoping to have this app out to beta testers on October 1 on\niPad/iPhone deployments.
\nthanks,
\nEtienne
(from [48efc48d8a2d072fbe5347247fb3748a809cc582])\n[#775\nstatus:fixed-in-qa] [#1426 status:fixed-in-qa] [#1416\nstatus:fixed-in-qa] zIndex sorting must happen in the parent of the\nview whose zIndex changed. \nhttp://github.com/appcelerator/titanium_mobile/commit/48efc48d8a2d0...
(from [6a5a8a1cd4fe1e05fbfcfb076d3a1bdb9238d27b])\n[#775\nstatus:fixed-in-qa] [#1426 status:fixed-in-qa] [#1416\nstatus:fixed-in-qa] zIndex sorting must happen in the parent of the\nview whose zIndex changed. \nhttp://github.com/appcelerator/titanium_mobile/commit/6a5a8a1cd4fe1...
@jhaynie, is this in the continuous builds? Assuming so, but\nwanted to ask before I test it...
\nAnd is this related to issue 1501 wherein the only way to change\nan objects size (w/o using an animation) is to show/hide cycle it?\nI'm dealing with this one specifically when resizing elements after\nan orientation change on iPad.
\nThanks, Etienne
The Jhayne is due to automation. 'Twas me.
\nThis fix, which as of this posting is in the continuous build,\nonly fixes the zIndex issue.
provided code does change zindex, back to you Blain\n1.5.0.62c1cae
a sample from #2183 (duped against this)
\nRunning on master as of 10/24, zIndex seems broken.
\nHere's the test case. Pink should be on top.
\nvar window = Ti.UI.createWindow();
\nvar view1 = Ti.UI.createView({
\nbackgroundColor:'pink',\nzIndex:20,\nwidth:200,\nheight:30,\ntop:10,\nleft:10
\n
\n});
\nvar view2 = Ti.UI.createView({
\nbackgroundColor:'blue',\nzIndex:11,\nwidth:200,\nheight:30,\ntop:15,\nleft:15
\n
\n});
\nvar view3 = Ti.UI.createView({
\nbackgroundColor:'red',\nzIndex:12,\nwidth:200,\nheight:30,\ntop:20,\nleft:20
\n
\n});
\nwindow.add(view1);
\nwindow.add(view2);
\nwindow.add(view3);
\nwindow.open();
(from [483124c7082e31db4e80b3de4739f7eeb703da27])\n[#2183 state:fixed-in-qa] [#775\nstate:fixed-in-qa] [#2092 state:fixed-in-qa] [#1426\nstate:fixed-in-qa] [#1416 state:fixed-in-qa] This time, zIndex is\nfixed for sure! Really now! Honest! \nhttp://github.com/appcelerator/titanium_mobile/commit/483124c7082e3...
Duplicate of #2183 as per Thom, above.