{ "id": "61882", "key": "TIMOB-1250", "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": "1", "description": "A fix for this issue is checked into the tree and tested.", "name": "Fixed" }, "resolutiondate": "2011-04-17T01:55:38.000+0000", "created": "2011-04-15T02:47:42.000+0000", "priority": { "name": "Trivial", "id": "5" }, "labels": [ "classname", "tableviewrow" ], "versions": [], "issuelinks": [], "assignee": { "name": "rseagraves", "key": "rseagraves", "displayName": "Reggie Seagraves", "active": true, "timeZone": "America/Los_Angeles" }, "updated": "2011-04-17T01:55:38.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}
className setting for TableViewRow can cause crashing when\nscrolling. className should be the same name for rows that have the\nsame structural layout, as described by Don Thorpe in this ticket:\nhttp://developer.appcelerator.com/helpdesk/view/26271#c115691.\nHowever, currently we are forced to use unique className's for\nevery row regardless if the layout is the same. Otherwise, we get\nthe scroll crash as described in the above ticket.
Want to second this one. I am seeing all sorts of odd behavior\nwith table views as they are scrolling. I am using classname as it\nis intended, where classNames are unique per layout of a cell, not\ncontent. This was working on 1.3.0 and 1.3.2 (though in 1.3.2 I was\nhaving issues with imageViews laoding, that seem to have been\nresolved in 1.3.3)
I'd also like to throw another comment on this one. All of my\ntableviews crash when I use setData([]) to clear them and then\nattempt to repopulate the table with rows using tableView.setData\nagain, but only when I'm using 1.3.3 from head. This issue is not\npresent in 1.3.2 (RC1), though I was having other issues with\nrandom table crashing in that as well.
assigning but I think this has been fixed already
In github master as of August 2nd, I'm experiencing similar\nthings. When I have TableRowViews with an ImageView child and\nclassnames for rows with matching structure, the ImageViews often\nshow images from other rows.
I also experiencing the same things with Luke Melia in github\nmaster!
I found the bug in TiUIImageView.h
\n[self setImage_:[self scaleImageIfRequired:[imageView image]]];\nit reset the image url string with a UIImage* !!!!!
\nshould be
\n[imageView setImage:[self scaleImageIfRequired:[imageView\nimage]]];
-(void)setWidth:(id)width {
\n\nwidth = TiDimensionFromObject(width_);\nif (imageView != nil) {\n [self setImage_:[self scaleImageIfRequired:[imageView image]]];\n}
\n
\n}
\n-(void)setHeight:(id)height {
\n\nheight = TiDimensionFromObject(height_);\nif (imageView != nil) {\n [self setImage_:[self scaleImageIfRequired:[imageView image]]];\n}
\n
\n}
anybody commit this bug???????
I'm no longer seeing any of the crashes described and the image\nbehavior (if it still exists) belongs in a separate bug. Thom, can\nyou confirm?
Hey Stephen, I am unable to repro the crash. The image behavior\nis logged as \nhttps://appcelerator.lighthouseapp.com/projects/32238/tickets/1156-...
\nand now assigned to you.
I'm closing the crash as resolved.
OK, here some code to reproduce the issue. Scroll a bit up and\ndown and the layout will be messed up soon (log output: \"[WARN]\nOrphaned child found during proxy transfer!\"). Some more scrolling\nand the app will freeze.
\nAPI 1.4.0; iPhone SDK 4.0.1; Simulator
\n\nvar max = 100;\nvar data = [];\n\nfor (var c=0; c<max; c++) {\n \n var row = Ti.UI.createTableViewRow({\n className: 'feedlist',\n height: 'auto'\n });\n \n var textview = Ti.UI.createView({\n layout: 'vertical',\n height: 'auto'\n\n });\n\n var h1 = Ti.UI.createLabel({\n text: 'Title title title #'+c,\n height: 'auto'\n });\n textview.add(h1);\n \n var cre = Ti.UI.createLabel({\n text: 'Creator creator creator#'+c,\n height: 'auto',\n color: '#ccc'\n });\n textview.add(cre);\n\n row.add(textview);\n data[c] = row;\n}\n\nvar win = Ti.UI.createWindow();\nvar tableview = Ti.UI.createTableView();\ntableview.setData(data);\nwin.add(tableview);\nwin.open();
\n
thanks for the code gero - Back to you Stephen, console log\nattached (no crash log produced on device, app stays in a hung\nstate after a few scrolls)
No longer crashes, but there are serious redraw issues. Working\non it.
(from [790ec1961c1783718a283f91ff38ec500d37c2d6])\n[#1250 state:fixed-in-qa]: Fix for deadlock that\noccured when requesting a relayout while laying out. - Many\nclassName reuse speed improvements - Fixed draw problem caused by\nreproxying \nhttp://github.com/appcelerator/titanium_mobile/commit/790ec1961c178...
still have the following probilem, Luke Melia and I found, and I\nfound the bug in TiUIImageView.h, please check.
\n\"When I have TableRowViews with an ImageView child and same\nclassnames for rows with matching structure, the ImageViews often\nshow images from other rows.\"
lansea90 - does lighthouse ticket 1156 cover the behavior you\nare describing? if not, it may be worth logging a new ticket to\nmake sure the issue does not get lost.
\nIn this bug - I am no longer able to crash, but am seeing some\nscrolling performance issues as well as some redraw. I've opened\nticket 1693 to address the scroll performance and redraw.