-
I’m afraid not. I got far enough that I figured indies could run with it (as you have) or ask for more (some did and that progressed it a bit.)
-
Thank you. That really means a lot. It’s so good to get feedback like this. I guess I will actually rewrite it from scratch once iOS7 settles down and gives me a guide. (Unless Corona Labs’ Widget dudes don’t beat me to it!)
Are you kidding? Your sample code is amazing. It has opened so many doors for me. The pinch zoom, rotate code is at the heart of my festival grounds map tab. It is so versatile and it was almost drop in and run. Thank you so much for all your contributions. You rock!!!
On the topic of search bar, may I humbly suggest not to do it as an extended WidgetDemo but simply a single storyboard scene with a single scrollView with a single tableView sample? This way it will be much easier for simple folks like me to understand and re-use. The widgetDemo itself was a complicated piece of code so to extract the search piece out of it isn’t everyone’s cup of tea. Just my humble opinion.
Anyways, lets start a new thread on this rather than pulling this further off-topic. Can’t wait to see what you come up with.
Best regards & thanks,
Kerem
Thank you 
Hey, maybe I’ll write it up as a tutorial, like the pinch-zoom…
Those will be in the Code Exchange. I probably wrote what you’re thinking of, so take a look at my collection:
http://springboardpillow.blogspot.co.uk/2012/04/sample-code.html
Ta. I’ve found this :
http://developer.coronalabs.com/code/improved-widgetdemo-sample
But is there a complete zip to download so I know I have everything?!
MANY THANKS!!!
I’d suggest this one, as it’s the only post I’ve updated since Widgets 2.0 became available:
http://developer.coronalabs.com/code/reorder-table-view-items
Thanks will take a look. It’s a shame Corona didn’t give us some decent boiler plate widget templates like this.
I get the feeling, and I’m not trying to be negative here as I love what Corona are doing, that the widget 2.0 library is not yet ready for a heavy duty business app implementation.
Tbh, I think they did. There’s a lot of work which goes into the Widgets and the WidgetDemo sample. Just IMHO.
The Widget demo is a good starting point but it’s a shame they didn’t go the extra mile and show how to do the stuff you had to work out. Still thanks all the same, its really appreciated 
I select edit then delete and row and do done. Then I get
stack traceback:
[C]: ?
/Users/rupert/Downloads/ReorderTable/widgets.lua:186: in function ‘refreshListData’
/Users/rupert/Downloads/ReorderTable/widgets.lua:376: in function </Users/rupert/Downloads/ReorderTable/widgets.lua:359>
?: in function ‘dispatchEvent’
/Users/rupert/Downloads/ReorderTable/tab2.lua:118: in function ‘_onRelease’
?: in function ‘?’
?: in function <?:1052>
?: in function <?:218>
I’ve updated the widgets.lua - it should work now. Let me know if there’s any problems. Sorry about that…
wow, horacebury, this is pretty nice work. Im trying to remove rows ‘related’ to the deleted row and have similar code I feel like I am unauthorized to access via event.parent.parent:_deleteRow(index) - but it works. Now I am noticing all the work you have done in recalibrating the list, scrolls and all.
Do you feel like this is a gap fix until the Corona folks add similar support for the parent access and cleanup? I am thinking this route is a lot of ‘under the hood’ work.
Thoughts?
@horacebury, wow! That demo was amazing. Thanks much for sharing your code as always!
Do you happen to by any chance have an updates version of your tableView search sample? That was an amazing piece of code as well.
wow, horacebury, this is pretty nice work. Im trying to remove rows ‘related’ to the deleted row and have similar code I feel like I am unauthorized to access via event.parent.parent:_deleteRow(index) - but it works. Now I am noticing all the work you have done in recalibrating the list, scrolls and all.
Do you feel like this is a gap fix until the Corona folks add similar support for the parent access and cleanup? I am thinking this route is a lot of ‘under the hood’ work.
Thoughts?
Tbh, I don’t feel like I did that much under the hood work, though there certainly is some.
I think calling this a gap fix is being hard on the CoronaLabs guys who are building the Widgets library. There is always going to be something that devs want to do which isn’t part of the provided API. Even Apple’s standard popup menus etc sometimes get rebuilt from scratch by because they don’t quite work the way a developer needs. CoronaLabs are doing everything from scratch! I’m grateful that we have the power and flexibility in Corona to do whatever we like.
Having had a tinker with Widgets 2.0 and the native controls I’m thinking I’m going to just use the Widget Candy library instead. OK at the mo it doesn’t have the picker wheel but I think it’ll save a LOT of work in the long run.
Without trying to sound too negative I think Corona’s implementation of widgets is still lacking, at least there’s too many gotcha’s for it to be useful for me.
Oh wow. I’ve actually forgotten about that one. I haven’t updated that, no. However, it wouldn’t be too bad to just replace the Widget1.0 references with Widget2.0 references. To update the code there isn’t actually much work, just not sure I’ve got the time right now.
What’s lacking, specifically? Maybe you should list everything in the Feature Request section.
I’m writing a proper, full-on utility app right now and I did take a look at widget Candy but turned back to Corona because I can’t see that Candy has been updated in a while and their demo videos don’t show much which correlates with Apple style functionality. They implemented draggable windows… I don’t understand why.
My litmus test has always been the UK Train Times app https://itunes.apple.com/gb/app/uk-train-times/id306687757?mt=8
Does your API allow you to build that with minimal effort? If not, how much extra work is required? My answer, a number of times, has always been Corona has the least amount of work.
The other issue is that creating a Corona library which provides handles into all of the Apple-provided controls would be a lot of work and would, of course, not provide anything at all for Android. It would be nice to have, but at the end of the day it would probably be better as a plugin.
I was a Pro user so had access to the latest builds but now I’m just a starter user so any issues with the Widgets 2.0 I encounter are potential road blocks. I know, you pay for what you get.
The hoops you have to jump through with the tableView to get it to behave like a native control, for me, is a pain. The WC lib has a lot of the stuff built in so will save me work.
It’s horses for courses and each to their own. For me, for what I’m trying to do with this specific app means that WC is a better fit. For another app I’m writing Widgets 2.0 is better.
Yeah, I’ve found that building on top of the ScrollView is a better starting point as TableView really is an end use.
I had to do a lot to produce a TableView-like control which allows reordering of items, which is build on ScrollView.
Yes and it was great work, but with a few simple lines I can get a workable tableView with WC so I can get on with writing the real part of the app rather than firefighting W2.0
As I said, they both have their uses.