i have same issue !!
Hi guys,
Yes, I’m aware of this issue and have been pushing the engineers for a fix. I will bump this again for a prompt fix in an upcoming daily build. Sorry for the inconvenience…
Brent
thanks… would be really great.
I already started to use another pickerwheel… but it has his own bugs 
but thanks again, that even someone from corona looks into our questions and give a short answer !
Many thanks to all for the prompt replies. I will use a temporary fix until this is resolved in a daily build.
u have a temporary fix?? how does that looks like ?
I needed a shorter picker wheel. My temporary fix was to download the widget library from github
https://github.com/coronalabs/framework-widget
I deleted the from the widget_pickerWheel.lua the parts that were overriding the scaling:
function pickerWheel:scale()
and contraints
if _pickerWheel.xScale ~= 1.0 then…
if _pickerWheel.yScale ~= 1.0 then…
After that I just changed the rowHeight of the table.view that the pickerWheel uses for the columns from 40 (default) to a smaller value.
Any word on this … about to try to create a smaller picker wheel but don’t want to fight the fight before this issue is resolved by Corona.
Having solid widgets is really important … i struggle with the widgets on a regular basis.
Cheers
I find this a peculiar response. The documentation seems to indicate that what proddev and others are looking to do should be supported. Yet it does not work. So am i to take it from this response that the feature is not supported and that the documentation will be changed or that it is supposed to be supported but it is broken at this time and it should be fixed in some version of the future.
I can see your response as a temporary fix … i am just trying to understand what position Corona is going to take with respect to the widgets which seem a source of constant struggle for developers tying to use them
Is your recommendation to abandon the widget class delivered by Corona and go cowboy with the source as a starting point? If so why … because the widgets will never be supported?
Please clarify this mystifying response.
same here… the actual widget pickerwheel is working horrible
lots of updates , but always a new problem with it.
PLEASE fix that soon… and check that it REALLY works !
hi,
or anyone else who know !
how did u implemented the github source (its a lot of files
did u used all files or only the pickerwheel
a short step by step how to implement that WORKING Pickerwheel would be great.
im short before a release and less time for big experimenting.
otherwise i have to keep on my daily build 2154 still … as there it works !
thanks a lot
chris
1. We are aware of bugs with the PickerWheel and are working to fix them.
-
Take custom skins out of the equation for the moment… The widget.newPickerWheel does not have a width or height parameter. It does not permit resizing or scaling either. The width and height are determined by the graphics used to draw the widget. The unskinned version is fixed at 320px x 240px (or whatever it actually is). On iOS the pickerWheel can change width, but not height.
-
We do support custom skins either through creating your own theme sheet, or for the specific widget. It looks like since that’s documented, it should be working. Though there could be things in this next round of widget fixes that address finishing out the skinning issues. Unfortunately, I don’t have a list of what’s in the next round readily available or an ETA.
-
Corona Labs provides widgets to do a core set of functionality. We can’t make them omni-functional. There just are not enough engineering hours available to address every possible use case you can dream up for them. If you need a widget that turns purple on it’s own every 3rd Thursday, we simply are not going to provide that. Our goal is to get them close enough to emulate the native versions within reason. If you need something beyond that, you are more than welcome to grab the open sourced version and build it to your specific needs.
i think most of us talk not about so much great features in the pickerwheel.
JUST, that what is said, should work.
for example even in the latest daily build… when u scroll through a set of numbers.
it starts to gray out and also it jumps suddenly a few numbers over and lands on a random number.
ABSOLUTLY not Functional… i mean really NOT functional… did u ever tried urself to do something useful
with that?? its like offering a Car and than just to say… sorry… the wheels are flat, the windows are broken.
Thats what we offer you!! Wohhh.
Sorry to say, but thats EXACTLY whats happening
And Corona is an example of a great tool with lots of bugs… but at the same time increasing lots of new features.
like Adobe was before
I guess i speak in the name of ALL USers (even the one who like new features… (I ALSO DO))
FIX first all bugs in the list, make it 100% working and THAN do new features.
I also managed a big team of coders and now full responsible for my own apps, i cant understand your management.
to allow such bugs even to be published in a daily build! Before I would cut my hand before showing something just
mixed together and than hopefully it will work… but mention it as a cool feature in the documentation, daily builds etc.
I love Corona… really… but also totaly disagree with the way how u keep developing.
The Main Functions that are used are the same like 4 years ago… !!
so it should WORK… and all the new fancy features are for a FEW ppl…
I dont say dont do it… we all like new features… but step on ur own feets and fix first that what is announced as features
of corona.
Also dont please announce cool features (like ur example once for OSX) and NEVER bring it out in 2 years.
That kind a … hehe… look what we can do… but we dont give it to u.
sorry thats fake!
Please show this post to ur team… i am glad to discuss about.
and as I got adviced once, yes there are coming more competition to corona who look more for whats really requested
by the users and not by the team imagined it could be nice (whats most time only fit 50%)
greets
chris
I needed a shorter picker wheel. My temporary fix was to download the widget library from github
https://github.com/coronalabs/framework-widget
I deleted the from the widget_pickerWheel.lua the parts that were overriding the scaling:
function pickerWheel:scale()
and contraints
if _pickerWheel.xScale ~= 1.0 then…
if _pickerWheel.yScale ~= 1.0 then…
After that I just changed the rowHeight of the table.view that the pickerWheel uses for the columns from 40 (default) to a smaller value.
So I’m 90% through an app that uses the recommended universal config setting for a virtual 1200 x 800 screen, as I need to run on iPhone4/5, iPad and Android phones and tablets (all that works really well), and now need to put in a picker wheel for selecting time values. Now of course I find that it doesn’t really work at that resolution, only 640 x 320, and comes out so tiny to be unusable!
I see the documentation says it can’t be scaled (but it says that for all widgets and I’m happily scaling the switch control without problems) so take a look at the source code on GitHub. There I see the code that restricts the scaling but removing that doesn’t help as its obviously put there to prevent the control breaking!. The one parameter I could change in the code was the height of the cells which had a parameter value but got hard-wired to 40. So anything much larger than the default font didn’t fit.
At the very least the documentation should state more specifically the config limitation (but who codes for 640 x 320 anymore?). Yes i know it’s in the sample code but that’s not the point. This control is seriously limited as currently implemented and anyone trying to do a business app with it, as i am, is likely to come unstuck. I don’t have the time to work out what the problem is in the open source code, although using a custom skin with a larger image sheet ought to be possible … until you start reading other threads.
Rant over - but just don’t get me started on how much time I’ve had to spend converting apps to Graphics 2.0, partly because compatabliity mode is so broken but mainly because of ongoing support issues if I didn’t (facing the same prospect moving from Storyboard to Composer too).
Any word on this … about to try to create a smaller picker wheel but don’t want to fight the fight before this issue is resolved by Corona.
Having solid widgets is really important … i struggle with the widgets on a regular basis.
Cheers
I find this a peculiar response. The documentation seems to indicate that what proddev and others are looking to do should be supported. Yet it does not work. So am i to take it from this response that the feature is not supported and that the documentation will be changed or that it is supposed to be supported but it is broken at this time and it should be fixed in some version of the future.
I can see your response as a temporary fix … i am just trying to understand what position Corona is going to take with respect to the widgets which seem a source of constant struggle for developers tying to use them
Is your recommendation to abandon the widget class delivered by Corona and go cowboy with the source as a starting point? If so why … because the widgets will never be supported?
Please clarify this mystifying response.
same here… the actual widget pickerwheel is working horrible
lots of updates , but always a new problem with it.
PLEASE fix that soon… and check that it REALLY works !
hi,
or anyone else who know !
how did u implemented the github source (its a lot of files
did u used all files or only the pickerwheel
a short step by step how to implement that WORKING Pickerwheel would be great.
im short before a release and less time for big experimenting.
otherwise i have to keep on my daily build 2154 still … as there it works !
thanks a lot
chris