- In lv_obj_del(), LV_EVENT_DELETE is sent after children are deleted. IMO this is not right, as the event handler might want to process the whole tree it owns upon this event, ie. it might want to be notified early on. Heck, it even might want to remove the children under its own control.
I’d suggest to move
lv_event_send(obj, LV_EVENT_DELETE, NULL);
before
/*Recursively delete the children*/
-
The same is in delete_children(). But wait, why is there such a function at all? Isn’t it conceptually identical to lv_obj_clean()? Comparing delete_children() to lv_obj_del() (which is after all called recursively from lv_obj_clean()) revealed different ordering of substantially same operations - I am not that deeply involved in lvgl to be able to judge whether this is material or not; but again, conceptually, I don’t see why would there be a need for a separate function to do the same thing.
-
Whatever is answer to first 2 items, using lv_obj_clean() (thus lv_obj_del()/delete_children()) as they are now, on \lv_examples\lv_tests\lv_test_group, causes it to fail, as one of the event handlers used there, win_btn_event_handler(), attempts to use information from its children before checking what event is on - as in the present state, this handler can be called with LV_EVENT_DELETE after deleting the children. This may easily go unnoticed unless LV_MEM_ADD_JUNK is engaged.
JW