WebListBox.RowHeight Not Returning Actual Value

I’m having an issue where WebListBox.RowHeight is not returning the correct value. It is returning the Minimum Row Height.

I want the height of my listbox to be set so that all the rows are properly shown w/o the scroll bar. There are two issues:

1.) If I try to calculate the height by using:

WebListBox.Height = WebListBox.RowCount*WebListbox.RowHeight(0)

I do not get the proper height. The the upper rows will be cut off and the scroll bar active because the actual row height is not being returned.

2.) Even if I do get the height of the list box set correctly with all rows showing, the scroll bar does not hide. The listbox has to get significantly larger before the scroll bar hides and there’s no way to hide it via method or property.

I have a feedback case opened for number 1 (<https://xojo.com/issue/34208>) but I have not reported number 2 yet. I will.

I assume you’ve checked both of these against r1.1 to ensure they’re actually regressions?

I have not but I will. And I do not note them as regressions in the bug reports.

FYI - the bug report for #2 is: <https://xojo.com/issue/34218>

So even if they are not regressions, it is a bug I have found during beta testing.

Neither of these are regressions from 2014r1.1. However, there is a report that has been closed that is very similar to what I opened:

<https://xojo.com/issue/18012>

Thom closed it back in 2011 saying there was nothing that could be done about it which is disturbing.

The actual height is going to be determined browser side. You’d have to write a JavaScript that checks the innerHeight of the DOM element you want and report it back to the server. Doable. Not trivial. Better to design so you don’t rely on browser metrics for expected behavior. If the user zooms in or out, for example, your estimates will be screwed up anyway.

So then pray tell, how does one set the height of the listbox when one cannot get the values of the sizes of the elements in said listbox? If the user zooms in or out, the whole box should scale accordingly. I see no issue with that…

I have a feeling the height you set is a suggestion. But I’d have to experiment and dig into the framework to see for sure. You just really don’t have the same layout control on the web that you have in desktop apps. Font metrics play a role and aren’t precisely measurable. When you try, you usually end up with the mess that is WebLabel with multiline set false.

Ugh. That’s just crap.

It’s one of the headache things about Xojo web. “Hey, we make web programming easy. Just like the desktop. Err, wait. We really can’t do it that way…”

You end up with all these quirks and workarounds for something that should be doable. The framework should be able to get all the font metrics and browser info, etc. from the client and size things accordingly.

And if a style is set in the app, then that basically sets everything in stone anyhow, so with a style of a size applied, you should then be able to reliably get that size…

But no, it has to be quirky…

It is what it is. With all the event handling and programmer code on the server side, the problem is that the server has a model of what it thinks is on the client side, and then there’s the client side.

OK, this was moved out of the beta list referencing beta case numbers. Not sure if that was a good idea or not - whatever.

Anyhow, Brad, the fact remains that in 99% of the use cases, there’s probably a pretty good guess that the server side could make as to the sizing. From my playing between Safari and Chrome, I see no difference in sizing between the two. So I’m betting most browsers would be pretty close. You could get a LOT close than just returning the minimum height.

I’m still befuddled how there is no mechanism to return the row height. It’s obviously something.

Oh, I see Joe made the cases public. OK then…

You’re right… it is something. Interacting with a web browser is a lot like NASA landing a spacecraft on Mars. With a 20 minute latency in each direction, by the time you’ve received a message that the craft has started its descent, it’s already on the ground, either sitting there waiting for the next command or it’s a pile of scrap metal because you didn’t do your job right. Internet latency isn’t 20 minutes, but it might as well be. Everything you get back from the browser is in the past and there’s nothing you can do about that if you want to be able to write Xojo code to manipulate things.

You couldn’t (for instance) write code like this:

Dim h as Integer = Listbox1.RowHeight(row) //Because rowheights are variable on the web

To get that data, we’d have to make RowHeight into a function with a callback. Your app would create a request to send to the browser, but it’s not sent then and there. It waits until all of the code in the event loop is complete. The best we could do is to return zero (or maybe -1) immediately so your code would complete. Then the whole set of commands is sent to the browser and the browser responds with a value… lets say 35. So what do we do with that value? We could put it into a property on the server for the next time you call RowHeight, but it’s possible that it will no longer be correct because other factors can affect rowheight, including changes in their contents, style changes, etc.

On the other hand, you could (as Brad said) write some javascript code to get the rowheights and calculate the entire height that you need and make the adjustments directly, but as I’ve said many times in the past, poking around in our framework and in the DOM is not supported and it may break in the future as we make improvements to the framework.

I get what you are saying, Greg, but is there not a way to force a listbox or any other object for that matter to be a certain size at the server prior to building the page? If “anything” can change as you are alleging then how can we set width and height or Top and Left?

Why can we not force a list box to have a certain set of characteristics or a “style” or whatever you want to call it that supersedes any other user configured browser settings. Why must we be subject to the whims of a browser with some properties but not with others?

How would the rowheight of the listbox change as you say it might?

I’m not interested in reading the value of something from the past. I’m interested in setting it now and for the future and locking it in so it won’t change. Why can we not do that?

There are different DOM concepts of outerHeight/outerWidth and innerHeight/innerWidth. On the web, stuff flows, even when you set up boundaries. The browser is in charge of the flow, taking hints from the code. Ultimately, if you want the metrics, you have to ask the browser for them. That’s just how it works, and there’s no changing it.

When you combine the way this works with the way Web Edition works, you get what Greg described. Your code would have to send some script to the browser, and that script would have to send information back to your code. There are some situations where this can work effectively. But it changes how you code, as you have to work asynchronously, step by step.

[quote=105408:@Jon Ogden]I get what you are saying, Greg, but is there not a way to force a listbox or any other object for that matter to be a certain size at the server prior to building the page? If “anything” can change as you are alleging then how can we set width and height or Top and Left?

Why can we not force a list box to have a certain set of characteristics or a “style” or whatever you want to call it that supersedes any other user configured browser settings. Why must we be subject to the whims of a browser with some properties but not with others?

How would the rowheight of the listbox change as you say it might?

I’m not interested in reading the value of something from the past. I’m interested in setting it now and for the future and locking it in so it won’t change. Why can we not do that?[/quote]

For the same reason that trying to do typesetting on the web doesn’t work very well.
You DON’T have absolute control over positioning etc like you do on the desktop.
If a font is missing you can get fonts being substituted & this can change metrics.
But you don’t know for sure WHAT the browser did without asking it - hence the round trips & latency & ……

And it you try to program “the web” in the exact same fashion as the desktop you’ll in for a world of pain because they are similar but not the same. There are some realities we just can’t hide from view - like this.

Here’s a good example of us having to work around this problem…

When writing your drawing code for the Paint event of a WebCanvas, the HTML5 canvas under the hood doesn’t support drawing pictures directly. You actually have to give it a URL of a picture, which it is up to the browser to retrieve at its leisure. So what we do is create a WebPicture on the fly, capture the PictureChanged event and trigger another paint event. This time the picture is available on the browser to be drawn. Because we use a diff algorithm, the delta change is usually negligible. My point is that we work around these hurdles where we can, but as Brad said, there are places where it’s virtually impossible and the results wouldn’t be acceptable to the user base at large.

That said, what is it that you are doing where you need to resize a listbox based on the height of the contents anyway? Maybe we could come up with a different presentation of your data that would work better with the web framework?