Listbox paintcell bug, release 2016r2

I downloaded Release 2016 r2 and ran into a bug – I think – immediately. On a listbox I tried to “invalidate.cell” and in the paint event, which supplies row and column, the column result works for 3 or 4 calls then gives me a ridiculous result. Here’s my Paint event code:

[code]
if gPresIndex+1 = column then
g.ForeColor = RGB(255, 128, 128)
g.FillRect(0, 0, me.Width, me.Height)
else
g.ForeColor = RGB(255,255,255)
g.FillRect(0, 0, me.Width, me.Height)
end if

Return True[/code]

For the first 3 calls, the column result is correct, then it goes whacky, giving me a result like “12” in a 4-column listbox.

Anyone having similar issues? BTW, the same code works fine on 2015 release I was using. I don’t want to go back because this new release is much snappier.

Update: I now know that the column variable jumps to the columncount. IOW, as I cycle through the cells, invalidating the listbox, the column variable goes 1, 2, 3, 12.

Windows or OS X?

Windows.

Our main application makes extensive use of the CellBackgroundPaint event. On the FillRects, there was an issue where they were off by a pixel, but that was fixed during the beat cycle, it looked right on the last update. Not sure what you mean by whacky, when you say it gives a result like"12" are you talking about it changing the actual Cell contents?

a report with a sample would be good

We’re used to getting row values that exceed the rowcount.
What you are saying is that the column value exceeds the column count?
You get 0,1,2,3 and

You get one column more if the width of each columns is fix and the listbox gets resized to more than the width of all columns summed up. This is only for CellBackgroundPaint of course, not for CellTextPaint.

The column value for a 4-column listbox should be 4. So if you really get 12, this is a bug.

Not seeing either of these here

On the default windows of a new project I have a listbox & a textarea
Have the listbox set with 12 columns
Its width is 374, height 200
Only 4 are visible
Widths are set to 284,30,30,30,0,0,0,0,0,0,0,0,0,0,0,0,0,0
In its open is

 me.AddRow "1", "2", "3", "4"

Both cellbackground paint & celltext paint have

   textarea1.AppendText  currentMethodName + " " + str(row) + ", " + str(column) + EndOfLine

I get the extra row paint events but no extra column paints

I tried it with a new project, very simple, and couldn’t duplicate the problem. I now have put a new listbox on my current project and and having success … except I strangely can’t get it to take .cell() contents. My current project is quite complex and maybe somewhere I’ve done something amiss … but it does work with my older 2015 release.

The listbox I’m using only has 1 row. The columns adjust based on inputs from user. I’m using it – the listbox – as a way to click through verses of songs.

I get the extra column with your settings of the listbox if the width is more as the summed up width of all columns:
0, 1, 2, 3, 12 are the column numbers printed with System.DebugLog for CellBackgroundPaint.
0, 1, 2, 3 are the column numbers printed with System.DebugLog for CellTextPaint.

So it seems to work correctly.

[quote=277227:@Jeff Tullin]We’re used to getting row values that exceed the rowcount.
What you are saying is that the column value exceeds the column count?
You get 0,1,2,3 and [/quote]

No. It jumps to the columncount. When I want to paint the background of, say, cell 3, it says it’s at column 12.

So ColumnCount is 12 and not 4 as in your initial post?

Columncount adjusts with the loading of each new song. I set it initially at 4. When a song loads, it sets to the number of items in a presentation script: v1 c v2 c v3 c v4 … (v1 is verse 1, c is chorus).

[quote=277232:@Eli Ott]I get the extra column with your settings of the listbox if the width is more as the summed up width of all columns:
0, 1, 2, 3, 12 are the column numbers printed with System.DebugLog for CellBackgroundPaint.
0, 1, 2, 3 are the column numbers printed with System.DebugLog for CellTextPaint.

So it seems to work correctly.[/quote]

Would be much more useful if you posted steps like I did to reproduce what you’re seeing

Use your example and make the listbox resize its width when the window resizes. A soon as the width of the listbox exceeds the total of the sum of all columns widths, you get an extra CellBackgroundPaint call (where column is equal to ColumnCount).

I placed a new duplicate listbox into the project and it did the same thing … but when I tried that same thing with 2015 release, my original listbox still worked but the new one had the same problem I’m facing now.

This tells me I must have some problem in my code somewhere. I don’t think it’s a bug in Xojo. I am working on a workaround until I can trace the problem on my end. If I do find out there’s a bug in Xojo, I’ll report it. As of now, I’m pretty convinced it’s on my end. But it is baffling as to why my 2015 release runs fine – minus the duplicate listbox – and now doesn’t.

Just checked the release notes for 2016r2 and it says:

Maybe this is related to it?

That sounds like the correct behavior. It used to be you’d get an “ugly blank column” (if I recall the wording correctly) that did not obey your background painting. It sounds like they fixed it.

It is the correct behavior.

AFAIK this has always worked in previous versions.

Could it be that you mean The “Extra” White Column in the ListBox is back !?
This was – and still is a bug. As I understand it is not related to the above. The bug was (and is) about manual column resizing not calling CellBackgroundPaint.