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).
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.
[quote=118903:@Mark Pastor]I don’t think that workaround works.
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.