Just some easy test that I’m trying to understand:
I create a new project with simple controls: One Window, one ListBox, one PushButton;
The ListBox has Height=90 and DefaultRowHeight=30 .So, it appears 3 rows;
The ListBox Inicial Value is “1 (enter) 2” So, the first row starts with “1” and the second row with “2”;
Then, the PushButton has this code on Action Event:
ListBox1.AddRow
ListBox1.ColumnType(0)=ListBox.TypeEditable
When I trigger the PushButton, two things happen:
1-The third line can now receive data (is not more just a “visible” row)
2-A forth line is created. I can see this line rolling the scroll, and this line is not editable
Can I ask why this forth line appeared? Has anyone seen this?
PS.: If Height=91, the forth line still appears, but if Height=92 the forth line is NOT created.
Here’s the project. 2016r4.1, Windows 7 Pro ListBox Test
Jrmie, yes Sir, Windows 7 PRO. I don’t know, I already made a post here about ListBox visible/editable rows, I really don’t know if this was supposed to happen. Even stranger when Mac runs with no problem
I wouldn’t consider this as a problem but a platform specific behaviour. Now that you know that on Windows the total RowHeights will be slightly different, you can set the following in the Listbox open event:
[quote=310754:@JrmieLeroy]I wouldn’t consider this as a problem but a platform specific behaviour. Now that you know that on Windows the total RowHeights will be slightly different, you can set the following in the Listbox open event:
I agree, is not a big problem (I must say that doesn’t help my OCD :D, but I will survive)
Tried your code, didn’t work, (the “ghost” line still appears)
Yes, this should work. Although, I’m not so happy about this (and by the fact that on Mac, this is fine). I tried some combinations with your code on and off, with and without Different types of gridlines, sometimes setting height=90 , 91, 92, etc. And this annoying line still appears on most cases. I just wanted simple behaviour for a simple code. It seems that is too much to ask for 3 lines with Height 30 combined with ListBox.Height=90
Listbox is not a native control, and it may have artifacts on different platforms. It is just the way it is. If you invest on a Xojo license you can create a feedback to identify this as an area of concern; but this being the listbox, and in Windows; it is like a two strike policy. I would not hold my breath. If you really want to go down the Xojo path, then do so accepting this (otherwise it will keep nagging you all throughout); it is not a bad system, but if you are not on the mainstream path you may not feel the “love”.
Really? I didn’t see any easy way to show what happens when I execute this demo. I didn’t think this was just my specific problem, but now I’m not so sure
Ok, to update this thread, because there were some private messages…
The uploaded xojo-project works as expected, because the listbox.height was set to 92. If you set it to 90 and start it, there are “ghostlines” even on Mac.
Seems to be an error in the control.
That’s is standard windows behavior. On windows list boxes do not scroll continuously. Rather the top row displayed is always even with the top. Depending on the size of the listbox the bottom displayed control is only partially shown. If the bottom index is not completely show you can scroll down one more line to show the last index fully. This shows an empty partial space.
In VB net there is a property call integralheight. You could simulate this with the Xojo ListBox.
Neil, nice explanation.
I guess make ListBox.Height=DefaultRowHeight*NumberofRows is not standard procedure, although in my head this makes perfect sense. But i’m not someone important in the programming world.
I will continue using (height+2), is not my all time best visual solution, but works.