Ah you’re right! Now it makes sense. Never noticed this. I guess it’s one of those details that becomes great as soon as you notice them.
You’re the best!!! Only reason I brought it up here again is because I thought this was fixed based on the update notes in the daily build. I think I misunderstood what I saw there. Not to worry. When you get around to doing this it’ll be good. I don’t see this as one of the urgent ones to tackle. Thanks for all your hard work.
Thank you for compiling this list Ksan, much appreciated. We’ve found another bug to add there.
Our app uses a SQLite database and renders a Widget.newTableView using the
entries. However, whenever we try to delete a row using event.target.index , the
number is off by 1 when the app is built for iOS.
Everything works perfectly in the simulator, but once it’s built for iOS the wrong row is
being deleted. We haven’t tested for Android yet so there may be an issue there
as well. Included in this post is a zip file with the test project.
We submitted a bug report to Corona 2 weeks ago (#29090) but unfortunately
haven’t heard back yet. We cannot ship until this bug is fixed or find another workaround.
Best regards,
moflaherty
Interesting one. I tested it on Android and IOS out of curiosity. The issue does not seem to occur on my Android device (running old 2.2 OS ) and Simulator is ok as you indicate. On IOS I do see the problem. You can put this in the spreadsheet yourself actually. It is open for edits by all. I will try to see if there might be a workaround (no promises). All the best!
Edit : don’t want to pull this thread much off topic but I think your code had some avoidable complexities (no offense). Specifically your deleteRow button causing the tableView to be removed, recreated and reloaded from your underlying db where you remove the record with an SQL call is possibly causing some issues here. You probably did find a bug that somehow affects IOS and not Android but there is a workaround and it is how I think many would code this anyways. I literally cropped your code until I got down to the core of what was needed and fixed it. Now it works on IOS. See attached main.lua.zip .
Please start a new thread if you have questions and I’ll be happy to assist as best as I can. Cheers.
I got a message that bug nr 26164 is fixed, but it is not. Thats the behavior with 2013.2099 …
Hey Mike,
I reopened the bug and i’m looking at it now.
Alex
ok, thank you!
Seems there is bleed between rows when you have noLines = true. I have thing similar to “Pull to refresh” behind the table and its visible between the rows.
[lua]
display.setStatusBar( display.HiddenStatusBar )
local widget = require( “widget” )
local function onRowRender( event )
local rowTitle = display.newText( event.row, “Row row row your boat”, display.contentWidth/2, event.row.contentHeight * 0.5, nil, 14 )
end
local tableView = widget.newTableView {
onRowRender = onRowRender,
noLines = true --<----<----<----
}
local rowColor = {default = { 1, 0, 0 }}
tableView:insertRow{rowColor = rowColor, rowHeight = 40}
tableView:insertRow{rowColor = rowColor, rowHeight = 40}
tableView:insertRow{rowColor = rowColor, rowHeight = 40}
[/lua]
Yup. I see this one as well.
Hey guys,
That’s known, it’s in the works at the moment. It will come together with a new property for tables allowing you to set the indentation of the separator line.
alex
Very good, thanks for the update.
This is great!!! Thanks much for the continued efforts. Please try and get these fixes to us in smaller batches though. Lets not wait months and months for a big batch of widget fixes. Baby steps… 
I don’t see this on the bug/request list, but has anyone figured out a way to “expand” a tableView row…you know, with the little folder-toggle triangle to show sub-items for that row??
For example, each row represents an invoice, and when you tap an invoice, I’d like to show the line-items for the invoice under that row, and have other (non expanded) invoice rows move down accordingly. I did find that the onTap/onRelease events CAN change the height of the row, but the other rows below are not moving properly in response.
If no one has figured this out yet, then I’ll just implement a fly-in dialog instead…ugly but I’m not sure how else to solve it??
@dgaedcke, I haven’t seen anyone do this yet. There was a recent thread on the same topic with some nice images showing what it could look like. Just to check if you are referring to the same capability please see the image in the link below :
http://forums.coronalabs.com/topic/42807-nested-tableview/
I think this would require some modification of the tableView code. At the very least, onRowTouch currently ignores touches on a category row. We would need this to be changed so that we can detect touches on the category field. We could of course insert an invisible rectangle with a touch listener to trap the category touches but that would be a little crude. Sounds like a nice coding challenge to do this with the current capabilities of tableView.
Meanwhile, what you could consider is displaying just your categories on a tableView inserting them in as non-categories. onRowTouch you can send your user to another scene with another tableView that only loads the child records for the chosen category in the previous scene. Depending on how many categories and child rows per category you are dealing with this might be a cleaner approach. Just thought. All the best.
@ksan – Thanks!! That’s good info and feedback
Ideally, the customer wanted to be able to “expand” and view several categories (top level items) at the same time but I’ve got too much on my plate to attempt customizing the newTableView object while CL is in the process of improving it at the same time…
Guess I’m stuck for a bit but that’s ok—I have plenty more to work on elsewhere…oh well.
I agree its not the best time to mod tableView itself with so much in motion. I will take this offline and try to put together another one of my “Lets all get together to build a yadayada” threads about it. Let me give it a shot first.
The current version of tableView doesn’t support those nested views. This will need to be a feature request.
Rob
Like this one? http://forums.coronalabs.com/topic/41661-widget-for-text-input/ 
was the “official” response to that one yet thankfully, we now have a willing and able member of community stepping up to build that which Corona Labs declined to “tackle” despite the overwhelming number of votes.
Let me put it simply… Till I see evidence otherwise, I have no confidence that the feature request system plays any role whatsoever in terms of how Corona Labs management make resource allocation decisions. Its just a waste of time for us. Corona Labs will implement whatever it chooses and we have to live with that. Feature request system is an illusion of democracy in play but in effect its nothing but a pacifier. It just doesn’t work.
There is a difference Kerem. Our reluctance to do the text thing is two fold, but both come down to building a full keyboard support in OpenGL would consume our entire team for a couple of years to make it happen. This has to happen for Window’s support. The code I wrote for the tutorial is a work around at best. I’m happy to see you guys take it further.
The tableView is something that can happen fully within our existing framework and would not take a team a long time to do. Feature requests are based on the resources and time needed and doing text the way it needs done and adding this feature to the tableView are not on the same scale.
Rob
Rob,
For accuracy sake, widget.newEditField started out as loosely based on the widget.newSearchField design in general and by now is way beyond that - if you wish, you can join the testing so you can get more familiar with the implementation and possibly help out in the future to make it better.
Best
Atanas