B4J Question [solved] CLV RemoveAt - unexpected log

[udg]

Hi all,

today compiling with Debug a complex program, I unexpectedly read an error message in the log.
So I tried to replicate it in a very simple test project, the one attached to this post.

My hope is that I'm doing something really stupid but it's late and I can't see it.
Otherwise it could be a bug..

Run the program and click on the trash can for the last item. A long error is displayed but the programm still runs and you can delete other items no raising any error (if you avoid to select again the newly set last item).

So, it seems related to RemoveAt and last item in the CLV.

xCLV 1.70
B4J 7.31

Edit: adding a sleep(0) just after the dim Index line it seems to clear the problem.

Dim index As Int = CustomListView1.GetItemFromView(lbl)
Sleep(0)

 

[stevel05]

This code works wiithout issue:

Sub CustomListView1_ItemClick (Index As Int, Value As Object)
    Log("ItemClick " & Index)
    CustomListView1.RemoveAt(Index)
End Sub

And your sub completes before the crash, there may be something in the library that tries to read the pane after the mouse click event returns, which of course has been removed in this case.

 

[stevel05]

Nope, it came to me, you need to consume the Event to stop the event passing to another view and referencing a now non existent view:

    Case "0"
            Log("remove item - CLV size before: "&CustomListView1.size)
            Log("removing index: "&index)
            CustomListView1.RemoveAt(index)    'CRASH if selected last item
            EventData.Consume
            'Let's try using a wait for - CRASH as above
            'wait for (removeitem(index)) Complete (Result As Object)
            Log("new CLV size: "&CustomListView1.Size)

 

[udg]

Thanks a lot.
The Event.Consume line solved the problem, making the addition of the Sleep(0) instruction no more necessary.
It seems that once the MouseClicked event is over, a CLV_ItemClick event is raised anyway (even if there's no reference to it in code); so, if we don't consume the mouse event, when ItemClick is raised it finds a list of the wrong size.

Attached the working code for future reference.

A question still pending: why the sleep(0) cured the problem? Probably because it causes a return to Main (and the silent raising of ItemClick) before the actual item removal, so list size appears ok at any time.