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.
Brent
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!
Hi @csavalas,
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.
Brent
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!
Hey Brent, I’m getting (relatively) close to launch. Just wondering if you’re still considering fixing this in the near future or not. Cheers!
Hi @csavalas,
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.
Best regards,
Brent
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 
Hi @csavalas,
Yes, we’ll get rid of that previous clipping method (hopefully sooner than later) because it’s unreliable and unpredictable.
Thanks,
Brent
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!
For anyone who’s curious, it appears the clipping method has been replaced and now works correctly from what I can tell. I haven’t checked the source, but perhaps a mod can confirm?
Hi @csavalas,
Yes, we fixed the label clipping, but we did not implement your more advanced “pre-determination” function. We feel this is something that a user should implement themselves in the open-source widget library, if they desire this level of customization.
Best regards,
Brent
Awesome! I’d have to do more extensive testing, but it appears whatever you guys did works just fine, I don’t see any need for my “advanced” method lol
For anyone who’s curious, it appears the clipping method has been replaced and now works correctly from what I can tell. I haven’t checked the source, but perhaps a mod can confirm?
Hi @csavalas,
Yes, we fixed the label clipping, but we did not implement your more advanced “pre-determination” function. We feel this is something that a user should implement themselves in the open-source widget library, if they desire this level of customization.
Best regards,
Brent
Awesome! I’d have to do more extensive testing, but it appears whatever you guys did works just fine, I don’t see any need for my “advanced” method lol