Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remote deletion of lv_obj_t #5

Open
X-Ryl669 opened this issue Feb 3, 2022 · 1 comment
Open

Remote deletion of lv_obj_t #5

X-Ryl669 opened this issue Feb 3, 2022 · 1 comment

Comments

@X-Ryl669
Copy link

X-Ryl669 commented Feb 3, 2022

If you start using a lv_obj_t inside another lv_obj_t, then you have an issue.
If you delete the parent, the child lv_obj_t * instance will be deleted by LVGL, but the C++ wrapper object will not.

In order to have a link between both, you need to register a LV_EVENT_DELETE on every lv_obj_t * you are wrapping so you can be informed when a children is deleted too and delete the wrapper.

However, this comes with a large penalty, each object now cost a wrapper + an event handler object.

@Viatorus
Copy link

Viatorus commented Aug 29, 2022

I see the same issue.

I tried to use the LVGL class functions around lv_obj_class_t (see lv_obj.c, lv_label.c, etc...) to construct a C++ class. This works as long as the class doesn't use virtual functions (and has a virtual table) since LVGL assumes the position of lv_obj_t is at the first memory address (and not after the virtual function table pointer).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants