ListBox ColumnWidths bug in Xojo 2016 r2.1

There seems to be a bug in listbox columnwidths in Xojo 2016r2.1.
I have a listbox with 10 columns and I want to have for the first 2 columns the width 1.5*,0.7*.
This worked up to 2016r1 (haven’t tested it in 2016r2). However in 2016r2.1 it seems to loose the integer part and converts 1.5*,0.7* to 5*,7* which produces ugly results. This happens on both Windows and OS-X.
If I assign the me.ColumnWidths in the Open event of the listbox, then it looks ok.

does it work with “150%,70%,” ?

Hi Jean, I’m not sure that it should work with % but if I put for example 15*,7*,10*,10*,10*,10*,10* it works. The problem is that the code that instead of 15*,7*,10*,10*,10*,10*,10* has already 1.5*,0.7* is broken…
It seems to not be able to hold decimals?!

(]FeedBack Case: 44890

You cannot even enter one non-integer value in the ColumnWidths field of the property editor of the IDE.

Unfortunately that should not work since comma is used as a separator between columns. Also don’t forget that it was working up to Xojo 2016r1 (don’t know about r2 though).
Does it work for you? Just try any listbox with more than 2 columns and try to enter in the columnwidths property 1.5*,0.7* and see what happens

No, it doesn’t work. As I wrote (note that I changed the text of my first post after two minutes) you cannot even enter one non-integer value like 1.5 (and this is with release v2 and v2.1).

Yes, sorry Eli… I had left the browser open in composing my reply for quite a few minutes and didn’t see your changed post…
Glad you could test it on release 2 and verified that it has the same behaviour there as well…

The documentation suggests that values for “*” must be integers, whereas values for “%” can be fractional. I suspect you were relying on undocumented behavior which has now been tightened down to conform to the original design.

Actually, it would make no sense to have fractions of pixels.

The LR says very clearly :

Which implies fractions are ONLY available for percentage.

It also states clearly that * values should be integers. No need to imply/infer.

In the release notes for 2016r2

44176 IDE » Inspector Invalid column width settings are not retained and rewritten to ones that are valid.

43193 IDE » Miscellaneous Column widths for desktop ListBoxes turn newlines into commas and generate a valid column widths expression.

From the docs at
A list of comma-separated values, with each value controlling the width of the associated column. A value can be an absolute value (in pixels), a percentage, a relative length expressed as i* where i is an integer, or an “*” that indicates “fill in the remaining width.” If you use percentages, you can use non-integer values to specify fractions of a percent, e.g., 43.52%. The percentage value can be greater than 100%.

Basically not a bug that you cant enter a floating point value
It should however truncate 1.5* to 1*

Thanks Tim, Michel and Norman. Didn’t see that in the documentation (although it should have been obvious).

True, unintentionally of course… It still is frustrating when something like this happens (behaviour changes even if it should) and breaks your code.

[quote=281746:@Norman Palardy]Basically not a bug that you cant enter a floating point value
It should however truncate 1.5* to 1*[/quote]
Norman it actually truncates it to 5 and not 1. So maybe that is a bug?