Listbox.CellClick doesn't always = listindex

I am running Win 10 and current XOJO. I haven’t tested this on my MAC.
I have a problem with a Listbox.cellclick not always changing the listindex. I assume it is supposed, Correct?
My code that does result in a change is

If me.ListIndex = -1 Then me.ListIndex = row End If
I haven’t had to do this elsewhere.

Cellclick should fire for any/every cell that has DATA… if you click on a row that is >=LISTCOUNT it will not fire

The code you have will only change the listIndex if there is not currently a selection in the LB. If there is, the above code will do nothing. It is much safer and more common practice to change the list index in the change event.

[quote=322382:@Arthur Gabhart]
I have a problem with a Listbox.cellclick not always changing the listindex. [/quote]
Cell Click should NOT have the row = listindex
This event happens before the change event so you can possibly cancel it

Returning True means that the event will not be processed further (i.e., editable cells won’t be editable and ListBox selection won’t change).

Okay. I didn’t mention the fact that the cell I’m clicking on does have data, which I programmatically added to the list and currently it’s the only cell with data. So the listcount is equal to the value. I also keep a record outside of the listbox of the last listindex.
I also don’t want to cancel out the change event. Part of my problem has been in tracking what value did or didn’t change and even if I reset it somewhere. I assume that the reason the change event doesn’t always fire is either threading or the code in cellclick is still running. How can I safe guard against change not firing when needed? Since I keep a record outside of the listbox of the listindex, maybe what I should add is a change event which verifies if it should be changed. Sorry if this sounds convoluted.

Would have to see your code to know why change doesnt fire but quite honestly I’ve used the listbox a lot and never seen it NOT happen when it should unless I return a value that is intended to suppress the change from happening

ListCount is 1 based… the Cells are ZERO based…

So if ListCount is 1, then the ONLY cell has an index of ZERO

That’s what I thought. According to the documents, listindex is zero based.
For Norm’s question, the line above is

TextFld.Text = me.Cell(row, column)//Textfld is a textfield box and how the write-protected window (me) gets modified. If me.ListIndex = -1 Then me.ListIndex = row End If
Also, this is the first window of the many windows, and it isn’t the main window. Just the first. An ini window if you prefer. It is called in as a showmodal window.
This action I’m performing (cellclick) is the first action by the user (art) in the entire program.

yeah that doesn’t block the change from happening
at least not here on Windows, Linux, or OS X

So, thoughts as to what else could be happening?

Hard to say without debugging your app and I dont really have time to do that

If I can get just that window to perform this way, should I post it?
I’m not sure which day that might be, but not today.
And thank you for confirming I’m not crazy.


Change doesnt mean the contents of the cell have changed, you know that?
It means the listindex has changed.
Setting the listindex in code in this way looks like a good way to confuse matters.

If your cellclick event wasnt there, clicking on the row would select the row.

I think your

TextFld.Text = me.Cell(row, column)

code, belongs in the change event, as

TextFld.Text = me.Cell(row, 0)

Something like that does belong in change anyways.
The only problem is row and column aren’t passed to change.
it’d cut out some other code from moving with an arrow button.

Row will be listindex.
Column isnt important for a change event.
I cant help but feel you are over thinking this.

Have you considered the MouseDown event?
In that,

me.listindex = me.RowFromXY(x,y) theColumn = me.ColumnFromXY(x,y) //do something with the column information

So if its the only cell with data, why do you even need to have a change event to copy that data to somewhere else?

If you allow people to amend what they want, you might only serialise it when they click save.
Trying to spot changes as they happen sounds very convoluted, yes.