2021r3.1 WebListbox ColumnWidths not correct widths

I have a WebListbox with 22 columns on and the ColumnWidths is not working correctly. I’ve tried setting the ColumnWidths both in the IDE and alternately in the Shown event and I do not get the expected ColumnWidths at runtime. I’ve tried both of the following for the ColumnWidths values:

Me.ColumnWidths = "225,90,90,120,225,185,185,150,185,150,250,185,225,600,225,185,100,75,75,150,225,*"

Me.ColumnWidths = "225,90,90,120,225,185,185,150,185,150,250,185,225,600,225,185,100,75,75,150,225,75"

I’ve searched the Forum for an answer and the problem I seem to be having was occurring in 2020r1 and the solution was supposed to be to set ColumnWidths in the Shown Event, but that doesn’t work when I try it.

I do have ColumnWidths working in another WebListbox but the total ColumnWidths does not exceed the size of the Listbox when shown. The expected behavior is that if the ColumnWidths exceed the size of the listbox you can scroll the excess width. The thing is I can scroll but none of the widths are correct.

Is there a solution to this I just haven’t found it?

Found this:
66793 - Set width of column of a weblistbox
62938 - Ability to set weblistbox.columnwidths in code
61610 - WebListBox ColumnWidths cannot exceed 100%

After researching this issue, this is clearly a BUG with ColumnWidths in Web 2.0 WebListbox. The expected behavior is to have ColumnWidths to be the same as in DesktopListbox and Web 1.0 WebListbox. Whatever you set the ColumnWidths to be in the IDE should be what the ColumnWidths are and not overridden by the WebListbox if the total size of the coulmns is greater than the size of the Listbox shown. You should be able to scroll right and view the Columns in the size that was established. This is not about changing those sizes during runtime.

I am seriously disappointed that “66793 - Set width of column of a weblistbox” Feedback was reset by Greg_O_Lone to be a Feature Request. I strongly disagree with that reclassification and posted additional info to that effect on the Feedback Case. This is truly a showstopper for me. There is no way I can covert my existing apps to Web 2.0 without the capability to set ColumnWidths and have them work consistently. It’s been 2 years since the release of Web 2.0 and I have a hard time with understanding why this bug has not been fixed with all deliberate speed.

Unless there is a workaround with WebListboxStyleRenderer to set the width of a column, I will be forced to once abandon using Web 2.0 again after many days of work only to be frustrated by an inconceivable omission in the Web 2.0 WebListbox.

Workaround update. I can make the WebListbox auto field sizing work for me if I can simulate wordwrap to break up long text into multiple lines instead of using WebListboxStyleRenderer. I need to approximate what wordwrap would do within a fixed pixel width in a cell. This is the main issue with ColumnWidths not working. Most data I’m populating in a Listbox is a fairly fixed length like TimeStamps, Names, Email Addresses, Job Numbers, etc., but there are several columns that can contain variable text that can be quite long. I think that if I can break these long lines into multiple lines I can live with that. I’ll begin searching for a method to efficiently do that, but if you know of something that already exists that I can leverage please feel free to let me know.

1 Like

Please keep us posted about your findings if possible. I will be facing something similar in the near future.

So far I have had no success. I have created a method to add EndOfLine linebreaks to the text I am adding to the WebListbox column but the Listbox is not honoring the line breaks and displays them as a single line. This is maddening!

I moved over to a GraffitiSuite Grid for these very reasons. I use a combination of ListBox’s and Grid’s, but while Grids are more finicky, they are much more powerful and you can set the # columns after Open, set the column widths on the fly and set the columns widths to be > 100% ie scrolls horizontally.

Grids aren’t perfect, but their issues are minuscule.

1 Like

Well… There is a workaround.
It’s ugly but it works.

In my WebListbox.Opening event I modified the headings and forced them to establish a with by using an underscore character instead of a space and force additional column width by adding more underscores on either side of the heading text.

Me.HeaderAt(9) = "_Complaint_ID_"
Me.HeaderAt(10) = "_______________Complaint_Description_______________"
Me.HeaderAt(11) = "_Submitted_By_"
Me.HeaderAt(12) = "_Submitted_By_Email_"
Me.HeaderAt(13) = "___________________________________Detail___________________________________"
Me.HeaderAt(14) = "_Detail_DateTime_"

I then apply a WebListBoxStyleRenderer on the columns that need text wrap so that the txt fits within the header text width.

If ReportData.Count(1) >= 0 Then
  For row = 0 To ReportData.LastIndex(1)
    For col = 0 To ReportData.LastIndex(2)
      If col = 10 Then
        detailstring = ReportData(row,col)
        detailstring = detailstring.DefineEncoding(Encodings.UTF8)
        lstbx.CellValueAt(row,col) = StyleCellTextWrap(detailstring)
      ElseIf col = 13 Then
        detailstring = ReportData(row,col)
        detailstring = detailstring.DefineEncoding(Encodings.UTF8)
        lstbx.CellValueAt(row,col) = StyleCellTextWrap(detailstring)
        lstbx.CellValueAt(row,col) = ReportData(row,col)
      End If
End If

Public Function StyleCellTextWrap(celltext As String) As WebListBoxStyleRenderer
Var style as New WebStyle
style.value(“white-space”) = “normal”
style.value(“word-wrap”) = “break-word”
Var cellrenderer as New WebListBoxStyleRenderer(style,celltext)
Return cellrenderer
End Function

It’s hideously ugly, but as a temporary fix until Xojo fixes the WebListbox ColumnWidth bug so the behavior is consistent with DesktopListbox and the old Web 1 WebListbox I have no choice but to use it. I hope this helps someone else but if you agree this bug needs to be fixed please add your comments to Feedback Case 66793 - Set width of column of a weblistbox.

Sigh…It’s a lot of coin annually for one control. If Xojo drags it’s feet fixing an obvious bug though I may be forced to go this route, but I sure would like to try it before I buy it.

Yeah, Web 2 had some major advantages: much faster than web 1, can handle a higher load, etc.

But it really has some stinkers in the ease-of-use “RAD” space.


New and Improved workaround. By replacing the Underscore character with a Braille Blank Pattern character &u2800 the overall looks like when setting ColumnWidths if it worked correctly.

Me.HeaderAt(9) = "Complaint" + &u2800 + "ID"
Me.HeaderAt(10) = "Complaint" + &u2800 + "Description" + AddSpace(20)
Me.HeaderAt(11) = "Submitted" + &u2800 + "By"
Me.HeaderAt(12) = "Submitted" + &u2800 + "By" + &u2800 + "Email"
Me.HeaderAt(13) = "Detail" + AddSpace(50)
Me.HeaderAt(14) = "Detail" + &u2800 + "DateTime"
Public Function AddSpace(num As Integer) As String
  // Braille Blank Pattern = &u2800
  Var spaces As String
  spaces = spaces.DefineEncoding(Encodings.UTF8)
  For idx As Integer = 1 to num
    spaces = spaces + &u2800
  Return spaces
End Function

1 Like

Would   be a solution? It is a non-breaking space. Screen readers and other assistive features may treat it better than Braille?


1 Like

Now that you can have multiline cells, can you scroll and see all records?
I wonder if the web framework calculates the listbox body size with the standard row height and now that your rows are bigger maybe you will not be able to scroll and see all rows.

&nbsp is HTML. You have to use the Unicode Character for it &u00A0. It works but It requires close to double the number of characters for the same amount of space.

I googled UTF8 Invisible Characters before trying &u2800 and there is a lot of good info in this Stack Overflow thread

I haven’t yet tried all the options with Windows and Mac OS in multiple browsers, but the Braille Blank Pattern worked well. I need to research how common it is before making a final decision.

And this is really good info here too!

Edit: Likely the best character to use from testing so far is &u+2001 - EM QUAD 1 em wide space, where 1 em is the height of the current font. This is wider than the Braille Blank Pattern. I plan to use that for adding space to grow column width and &u00A0 (&nbsp) for space between words.


1 Like

Fair enough, my only concern is the likes of a screen reader.

Which is another reason why Xojo needs to fix the ColumnWidths bug. A screen reader is not a problem for me in the corporate environment where my apps are deployed, but I wonder if an invisible character would even register with a screen reader.

I would have thought it would see it as a pause in reading. Like a space between words. I was imagining a situation where lots of pause could cause a large delay in between columns.

A corporate environment is exactly where I would expect there to be legislation requiring such things to work appropriately. Equal opportunities and disability provision requirements and the like.

If you’ve checked then fine.

Isn’t there a more appropriate CSS fix for this? Part of the impetus for Web 2.0 was to allow for better control via CSS. The goal of Web 1.0 was to create Desktop style apps in the browser. Web 2.0 aims to create browser apps with a more natural, web style look and feel. Apps that play nice in the browser and respond as expected on the web. It was a significant change in philosophy.