I’ve looked through all ListBox properties and I cant see it, but does anyone have:
a native (xojo) way to get the border size (this varies depending on OS/style) of a ListBox in windows without resorting to system calls or going borderless and embedding it in something else
or
a way to tell if horizontal and/or vertical scrollbars are visible
or
a way to get the internal visible width/height of a listbox i.e. overall width - size of border - size of scrollbar (if shown)
Thanks
Curious, what are you ultimately looking to do?
I’m trying to implement a workaround for <https://xojo.com/issue/46694>
Others have suggested some code, but it’s not a complete solution.
If the horizontal and vertical scrollbars are up its leaving the last entry behind the horizontal scrollbar because its not selecting the correct entry. So I figured I could calculate it differently if I knew the horizontal scrollbars was up. I can calculate if the scrollbars are visible but I need to know the thickness of the border so I can get it to a pixel perfect calculation or it sometimes misses the offset as the window is being dragged until there is sufficient space.
Any of those three questions will get me a solution to implement what I need.
Failing that I’ll go the longer route and subclass the entire ListBox control and add in scrollbars myself.
I’ve attached the framework for a workaround to that case. Let me know if you can use that, probably with some tweaking.
Thanks, I’ll give it a try.
Umm, thanks for the offer Kem but I’ve already got a better version than that running (without the need for a timer).
I’ll post what I have, maybe someone can shed some light on what I’m getting stuck on.
Now I don’t at all feel like a loser who just wasted a lot of time trying to help out a fellow traveller only to be dismissed. The “umm” really helped.
Sorry Kem, I thought you had pulled the code from archive somewhere and hadn’t just spent some time working on that, please accepty my apology for that flippant remark, I’m quietly losing my patience with all this and I know you’re trying to help. If its any consolation, I’ve put in hours and hours trying to fix this problem so far, trying various tricks to get it to work, only to find more bugs (see below) 
Here’s what I’ve got so far.
https://www.dropbox.com/s/36zsdrpuykb4rp9/TestListBoxResizeFix.xojo_binary_project?dl=1
The problem is when you expend the window straight down, you should be seeing entry 40 all the way, however as the horizontal scrollbar is there, its blocking entry 40. If you expand the window right first to remove the scrollbar, then expand the window down you need it as it should be.
If you take a look at the debug output while doing this, you’ll see that I’m showing a message when the vertical scrollbar should be visible. The problem is when you get near showing the complete list with the horizontal scrollbar on and off you’ll notice there’s a slight discrepancy in the calculation, because of the scrollbar and or because of the border size.
Now I can probably calculate the fact that the horizontal scrollbar is being shown by calculating the widths of the columns (not tried this yet) but this still wont take into consideration the width of the border to address the issue above. I could just pop a fudge number in there, but it wouldnt be right for all versions of windows then as different editions have different border widths.
If noone can help me with this, my last option will be to wrap the entire listbox control and either put my own border on there, or go the whole hog and put my own scrollbars on too.
(If you encounter a crash bug when expanding the listbox, dont worry about that as I’ve reported it already <https://xojo.com/issue/47743>, no I’m not having much luck)
OK.
I can look at your code later, but one clarification. In my example code, the Timer wasn’t required, it was included intentionally. I often find that attempting to manipulate a control directly during one of its events does not work properly, probably because the control is an uncertain state where all of its properties have not yet been set as expected. By using a Timer, the code executes after the control has been “finalized” and tends to be more reliable. Perhaps that can help your efforts?
Changing the state of a control IN an implemented event of that control may cause another event to run right away - which can also change the current state thereby exacerbating issues