WebListBox - InsertRow Bug ??

This one really threw me off - tell me if I am missing something.

Create a WebPage.
Put a 4 column WebListBox on that page.
Put this code in the Open Event for that WebListBox

For r As Integer = 0 to 9
me.InsertRow 0,"",""
For c As Integer = 0 to 3
me.Cell(me.LastIndex,c) = str®+", "+str©
Next
Next

Tell me if you get what you expect.

[quote=118890:@Mark Pastor]This one really threw me off - tell me if I am missing something.

Create a WebPage.
Put a 4 column WebListBox on that page.
Put this code in the Open Event for that WebListBox

For r As Integer = 0 to 9
me.InsertRow 0,"",""
For c As Integer = 0 to 3
me.Cell(me.LastIndex,c) = str®+", "+str©
Next
Next

Tell me if you get what you expect.[/quote]

You insertRow with only two fields. It works fine with 4 :

For r As Integer = 0 to 9 me.InsertRow 0,"","","","" For c As Integer = 0 to 3 me.Cell(me.LastIndex,c) = str(r)+", "+str(c) Next Next

That’s my point! Isn’t InsertRow supposed to, um, insert a ROW?

If insertRow did not work, you would not have 10 rows in your ListBox.

You were inserting rows fine, but instead of 4 columns, inserted only 2. When I changed for

me.InsertRow 0,"","","",""

Display became coherent.

Completely understand. But wouldn’t you call this a bug? Shouldn’t an entire row of blanks get inserted, except for where you specifically include data? I would expect my original code to insert 4 blank cells, even though I only specified two of them. No?

What really hurt me on this one is I populated a weblistbox of user data using my method of insert 0,"" - then filled in the rest of the columns. This was not in the open event, and believe it or not, the table came out just as I expected it to. But then, I wanted to pull the data from the table for a PDF report, and - listen up - even though the data on screen was correct, when I pulled data directly from the listbox (i.e. s = listbox1.cell(r,c) ) - the values for s disagreed with what was on the screen - consistent with the affect above. So, I am pretty convinced there is a serious bug, one way or the other. This took me a couple days to trouble shoot and figure out this inconsistency.

I am not quite sure of what is going on. If I go simply me.InsertRow 0, all cells start with 9. So indeed each cell is created somehow, as it can be modified. What is really puzzling is why r is not taken into account when columns are not “”. I get 9,x in each cell, and cannot explain why. As if somehow the value of r was set to 9 out of the first for next loop. Weird.

What that means is that an InsertRow must be done with real strings as columns and implicit produces whacky results.

Amazingly enough, using addRow with no strings produces adequate values (in reverse order of course).

This project shows what happened in my customer app. The first table LOOKS like it fills properly (Fill button), but then look what happens when you copy to the other table (Copy button).

https://drive.google.com/file/d/0B6VX0ve9b4G-TVc4aHVyb3BOdXc/edit?usp=sharing

There’s a bug that was just fixed ( in the last week or so) which could screw up the value of lastindex and some of the backing data when you mix insertrow with < # of columns with direct cell assignments.

Just use insertrow for the first value and then use Cell for the columns for now.

I don’t think that workaround works.
Check out my examples in feedback://showreport?report_id=34796

Let me know if I don’t understand your suggestion.

Thanks.

[quote=118903:@Mark Pastor]I don’t think that workaround works.
[/quote]
The reason I say this is because I am doing exactly that in my customer app, and while the screen data looks good, the backing data does not. Very weird indeed.

Try not relying on LastIndex.

I will give that a try.

Nope - that doesn’t work either. It is the Insert mechanism that is not working.

https://drive.google.com/file/d/0B6VX0ve9b4G-ZE10TURJYzd3UEE/edit?usp=sharing

Right. so the answer for right now is to replace this:

ListBox2.InsertRow 0,"",""

with this:

ListBox2.InsertRow 0,"","","",""

The feedback case is feedback://showreport?report_id=19928

[quote=118913:@Greg O’Lone]Right. so the answer for right now is to replace this:

ListBox2.InsertRow 0,"",""

with this:

ListBox2.InsertRow 0,"","","",""

Gotchya - VALIDATED WORKAROUND.

Thanks.

What I have been saying since first reply :s

I just needed someone to acknowledge it was truly a bug - so I could properly set my understanding and expectations.

Hence you ignore the solution provided in reply #2 to prefer the very same code in post #15. Quite logical indeed :confused:

FYI - I am not the one that marked the response as the answer - someone else did that.

The following, in my opinion is the real answer I was looking for.

Hence my original post with “…Bug ??” in the title.