I’ve noticed this is every build of corona sdk I’ve tried.
When the text string of a column label exceeds a certain length, it is arbitrarily cut off at around the 5 character mark. For simplicity, I have posted a screenshot of the built-in Widget demo where the month label string “May” is modified to “1234567890ab”, and displays “1234567890ab” CORRECTLY in the pickerwheel. In the second screenshot, the string is modified to “1234567890abc” (adding one more character ‘c’), and the text displayed in the pickerwheel is “12345”, arbitrarily cutoff at the 5 character mark.
Let me know if I can be of any assistance should you require more details.
There is, in fact, code for this within the widget. However, I am considering removing it, as its behavior is unreliable and inconsistent.
Until that point (if I decide to remove this “feature”), you could download and use the open-source widget code, and remove the code block which causes it. I can even point out the lines you should remove, if this is your decision.
Hi Brent. Thanks for the reply. Even if I decide not to go down the open source widget path, I would definitely be curious to see the code that causes it. If you could point me in the right direction, that’d be great! What is the intended purpose of the code in question?
I believe this code dates back to an older version of widgets, but it remains in there. The idea was that labels should not exceed the column width, but in discussion with the team, we feel that the user/developer should be in control of this design aspect. I’ll keep you posted on what our decision is regarding this…
Cool, I wouldn’t see an issue if the labels were correctly cutoff at the column width, and not prematurely as they are now. Where can I see the code portion you were referring me to in your earlier post? Thanks
OK, do you have the open-source widget library downloaded and implemented in your project? If so, look for the “widgetLibrary” folder and, inside it, the “widget_pickerWheel.lua” file. Search for a line like this:
[lua]
local textWidth = rowTitle.contentWidth
[/lua]
Then, comment out that line and all following lines up to the next “end” (so, about 8-9 lines). That should turn off the clipping thing and your labels will simply be clipped by the column’s boundaries.
Thanks Brent, I replaced the code after the line you referenced with what follows below, so that the string remains as long as it can be, while still cutting off in between characters as you guys were intending
local textWidth = rowTitle.contentWidth local rowlabelLength=string.len(row.\_label) while textWidth \> columnWidth do --cap the text rowlabelLength=rowlabelLength-1 row.\_label = row.\_label:sub(1, rowlabelLength ) rowTitle.text = row.\_label textWidth = rowTitle.contentWidth end
Feel free to use it or something similar if you like, I myself will continue to use the remote widget library so I dont have to keep updating it, but this has been interesting. Thanks!
Thanks for sharing your method. Just curious, are you seeing any performance issues? The “while” loop can be on the slower side (in Lua perspective) and the labels are going to be updated via this loop every time they come into view on the picker. I’m just curious if you’ve tested your code on devices (and if possible on slightly older devices). Most likely it will work just fine, but some testing would confirm so.
No problem Brent, I did test on an android device with no performance issues, but you made me think of another concern, so I rewrote the method. In the case of a very long row label, there will be a lot of unnecessary iterations with the previous method because it starts at the length of the row label and works backward. In the method below, the iterations start at 1 and only continue until the width becomes too large, eliminating the potential for a long loop with large string values. In the case of a string that does fit, no action is taken at all, so there shouldn’t be any significant performance hit. Also, the ‘while’ has been replaced with ‘for’.
local textWidth = rowTitle.contentWidth if textWidth \> columnWidth-5 then local tempText = "" local rowlabelLength = string.len(row.\_label) for i=1, rowlabelLength do --incrementally increase tempText string... tempText = row.\_label:sub(1, i ) rowTitle.text = tempText textWidth = rowTitle.contentWidth --until it is too wide, then break the loop if textWidth \> columnWidth-5 then row.\_label = row.\_label:sub(1, i-1 ) rowTitle.text = row.\_label break end end end
@Brent fyi, I’ve tested the above code in the simulator and on a couple of devices and noticed no performance hiccups. I hope you guys will consider implementing something like this, or removing the current truncation logic, as the way it currently functions is less than desirable. Cheers!
Thanks for the reminder on this. I would go ahead and use the label-clipping code that you wrote. I don’t feel that this is an implementation that we will add because it may cause confusion for those who use longer labels and do not understand why (unless they inspect the widget framework code) their labels are being clipped. Ultimately, we feel that the user is responsible for making their labels fit within the column bounds.
Hi Brent, that’s totally fine if you won’t be using my specific clipping method, but I would however strongly suggest removing the existing clipping implementation you guys are currently using. To refresh your memory, the method you guys have in there now arbitrarily clips the label to only a few characters if deemed too long, which is even more confusing for developers. If not my method, I’d suggest taking it out all together, and leave the responsibility for label lengths to the developers as you said… just my two cents
Oh ok, great, that was actually what I was asking about initially, any idea on how far down the pipeline it is for the engineers to delete those few lines? I’m only asking because I want to use official widget code only for various reasons. Thanks!
There is, in fact, code for this within the widget. However, I am considering removing it, as its behavior is unreliable and inconsistent.
Until that point (if I decide to remove this “feature”), you could download and use the open-source widget code, and remove the code block which causes it. I can even point out the lines you should remove, if this is your decision.
Hi Brent. Thanks for the reply. Even if I decide not to go down the open source widget path, I would definitely be curious to see the code that causes it. If you could point me in the right direction, that’d be great! What is the intended purpose of the code in question?
I believe this code dates back to an older version of widgets, but it remains in there. The idea was that labels should not exceed the column width, but in discussion with the team, we feel that the user/developer should be in control of this design aspect. I’ll keep you posted on what our decision is regarding this…
