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.
We’re experiencing some issues with the scroll view widget with compatibility mode using build 2161.
Objects being inserted into the scroll view seem to get incorrectly positioned. We also seem to get some strange behaviour when attempting to scroll. Initially nothing is displayed, then scrolling brings the inserted object into view. If we then scroll above the limit in the “up” direction, the list will re-position to the middle instead of the top, which doesn’t seem right.
This is the very simple code we have tried this with:
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 :
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.
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.
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.
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.
Rob, all that Corona Labs had to do was to do what Atanas has done to fulfill those feature requests. No one asked for a full blown keyboard implementation with spell check etc. We all understand the difficulties of the native vs non-native. Not trying to undermine the amount of work Atanas has put in. It is huge but still if a one person could do it so could Corona Labs… Thankfully Atanas felt this was something he could tackle and results speak for themselves. I for one am very happy with what he was able to create and will be forever grateful. Consider that feature request closed!
I can’t tell what you are saying…will you guys eventually tackle openGL text fields or not?
And if I was to submit a feature request for nested tableView rows, based on your guess about where it would fall on the list, would it likely get done within a few months?
Dewey, let me first clear up the textField vs. Windows thing. Corona SDK is an OpenGL based product. On iOS, Mac OS-X, and Android the operating systems let you mix native objects and OpenGL in the same window. The native objects draw on top. On Windows, Microsoft wants people to use their DirectX graphics language/APIs. In an DirectX world, you can mix native and DirectX like you can on other OS’s, but Microsoft does not permit it with their implementation of OpenGL.
So our choice is to either build a text field/keyboard in OpenGL which would take the entire engineering team years to do right or have MSFT patch their OS’s to allow it which is very unlikely to happen. I don’t know enough about the Windows 8 Phone project we are working on to know how this will be solved, but it will not work back in win32 binaries that run on Windows XP, Vista, 7, 8 etc. So while I don’t like to use the term never, it’s very unlikely to happen.
When I said “this has to happen for Windows support”, **this** means “the entire engineering team working on it full time for over a year”.
Now for your tableView issue…
While entering a feature request is a required step to get engineering to consider this, there is a work around. The biggest issue with tableViews right now is that it’s really hard to change the height of the tableRow after it’s created. What I would recommend is to think a bit more abstractly about the problem. Since we can’t hide/show invisible rows and we can’t resize them, I would recommend (if the tableView doesn’t have hundreds of rows) that when you want to expand a row, that you could delete all of the rows and rebuild the tableView with the expanded rows in place. This should draw fast enough that it should be smooth.
