using the same project that I use in the xojo 2021r1.1 release and that in this release does not raise these exceptions, in the latest version of xojo, when I go to set the columnCont of a webListBox (in any part of the code) I get an exception “UnsupportedOperationException”, Message: “WebListbox.ColumnCount must be set before the Opening event finishes.”, reason: “WebListbox.ColumnCount must be set before the Opening event finishes.”
I of course need to set the number of columns dynamically, does anyone have any suggestions on how to handle this exception?
ColumnCount cannot be set at runtime now, if memory serves. You’d need to build your own ListBox implementation using WebContainers or a JavaScript component like GraffitiGrid.
I didn’t understand, it is no longer possible to set the number of columns of a webListBox dynamically? and why ? and where is it documented that at runtime it is not possible to change the number of columns of a webListBox? But then why wasn’t an exception thrown in the previous xojo release? (sorry for the impetuousness but it seems to me that xojo is creating complications instead of simplifying)
sorry, I tried to look at case 65007 but with the feedback app I can’t see its content, also I see that the status is fixed. However, you have been told that the problem will not be solved and that the webListBox must have the number of columns statically defined ??
Well, my assumption is that the underlying library has some issue with changing the columns while data is loaded. It’s not great fun, but when using open source you sometimes have these limitations or bugs that need to be sorted out upstream. Even if you build a pull request, you often don’t want to deploy it until it’s been accepted and merged for fear that it may not be in the next version you try to move to.
It looks like this particular issue is due to DataTables requiring that the entire table be destroyed and reinitialized when you want to add or remove columns and would not be an insignificant amount of work to fix because they likely cache all sorts of values that are calculated on init that are not recalculated.
I change the number of columns always and only after removing all the rows of the weblistbox, which among other things, I fill by hand with data coming from rowSource, so what you indicate is not my case.
however, in the 2021r1.1 release the webListBox worked (with a lot of serious problems but it worked). With the release of this version the problems that already existed have worsened, and the webListBox is not a little used component, I think it is the one most present after the webTextBoxes. Now, I think they are going the wrong way, and I don’t even want to mention the fact that porting projects from 2019 to a> = 2020 release IS SO IMPOSSIBLE !!
I wish there was something more I could tell you. It seems that changing columns at runtime caused significant enough issues that the Xojo team felt it necessary to follow the guidance of the library’s developer and not attempt it.
As to the other issues you mention, I know that they are working diligently to correct as much as possible with each release. There’s really nothing more that anyone can say than that.
Maybe one option you could try is to create a WeblistBox at design time with enough columns ( say 10)
And as you requires, hide the unused columns ( eg to use 7 columns only, hide column 8 , 9 , 10)
You could use this code ( which was written by Anthony previously, i think) to hide the column
in Xojo2021R2
This is a major regression for me - the only way to change columnCount is to do it in the Opening event of the WebListBox control (you can’t even do it in the WebPage Opening event).
Why was this feature removed? It seemed to work fine before…