Cannot set listIndex from within cellAction event in ListBox... by design?

I’m using a listbox that allows the user to make changes to the contents of the listbox by editing things in-place. To do this, I’ve set the cellType property to be TypeEditableTextField for the cells I care about. Let’s say my list box contains this list:

Bar
Baz
Boo
Foo

Note that they are alphabetical - my list needs to stay sorted in alphabetical order. Now, assume the user wants to change “Foo” to be “Ada”. To do this, they double click on the Foo cell which has 2 effects: it selects that row in the listbox, then makes that row become an edit field with “Foo” in it and selected. The user then types in “Ada” and presses enter.

At this point, the cellAction event is fired, which in my app’s instance will update the item in the database to be Ada instead of Foo, it then clears out everything in the list and reloads it all so things are again in the correct order. I should mention that I cannot simply use the sort methods of the listBox because this is a hierarchical listbox, and the item that was edited may be the child of some higher level item, and I need each child list sorted alphabetically as well as the parents.

Here’s there my problem lies: I’d like to KEEP the user’s selection on the thing they just edited… so after re-loading the list I loop through it looking for the thing they just updated (“Ada” in this case) and then set me.listIndex = index of the “Ada” item. Then cellAction ends and returns. But the call to listIndex does not seem to have had any effect, so here’s what the list now looks like:

Ada <-- This should be the selected row, but it is not.
Bar
Baz
Boo <-- This is the selected row.

TL;DR:
So, can I not change the listIndex from within cellAction? Do I have to resort to something stupid like a timer to wait for cellAction to finish before I can change the listIndex? Is this actually a bug? I have a sample project and am happy to submit a bug report, but would rather not clutter up feedback with something that is by design.

Usually No need to delete all rows and reload all…

Find the Item’s parent by going backwoods checking the indent level… Close the Parent and then open it… Depending on your code children should be in the right order

Cache something that let;s you set the list index to it in the ExpandRow event…

That strategy has worked well for me to do similar things… If doing it in CellAction is an issue… use a timer with a period of 1 to close the Parent so you are no longer in that event when you set listindex in ExpandRow…

  • Karen

Thanks, Karen. Ultimately I just used a timer that the cellAction fires off to update the listIndex, since I already built the thing based around the ability to update the listIndex anytime I wanted to.

I REALLY wish that the documentation for Xojo would point out oddball cases like this… but the docs for all the intricate things you can do with ListBox are pretty sparse.

sigh

If you care to read the Apple documentation for UITableView which is far, far more complex, Xojo looks like War and Peace in a good English adaptation, whereas the Apple stuff would still be in Russian :wink:

[quote=151613:@Kimball Larsen]I REALLY wish that the documentation for Xojo would point out oddball cases like this… but the docs for all the intricate things you can do with ListBox are pretty sparse.
[/quote]

There are so many possibilities that I don’t see how they could do it.

In any case, throughout the framework when there is an issue like that, a timer is usually the way to get it to work.

On the contrary, Apple’s documentation is VERY good. Specifically, take a look at the docs for
selectRowAtIndexPath:animated:scrollPosition: in UITableView here.

And compare that to the Xojo documentation for ListIndex.

I’d MUCH rather spend 15 minutes reading through complex but complete documentation to understand the limits of what I’m trying to use than spend several hours guessing and testing various scenarios by creating sample projects, whining on the forum, and submitting bug reports like this one.

I used the Timer workaround in a pre-1.0 version of Answers (the function got re-designed out so it was no longer necessary.) It works fine and isn’t noticeable on a delay of 50ms.

I think because the CellAction event is within table updating/drawing/whatever it occurs too close to something like setting the ListIndex. You should probably submit the feedback report, but I’d think it’s low priority because of the Timer solution.