Disable input from "background" with messagebox

Hello, I use LVGL 8.3.

I am trying to use a messagebox as some sort of popup, however it is still possible to touch and interact with the widgets in the background.

One option would be to set the parent variable to NULL on creation: Message box (lv_msgbox) — LVGL documentation

This creates a nice semi-transparent background which also prevents the user from touching any elements it overshadows. However, this means redrawing the entire screen instead of the portion of the screen where the messagebox should be displayed.

Creating a background myself and just setting the opacity to 0 sadly does not work, it will still attempt to draw the (technically invisible) background.

What other options do I have? Maybe a flag I overlooked…

EDIT: Ignore the fix below, it leads to unexpected behavior. A better option for this question has been posted here: Lv_roller strange behavior when clearing/adding CLICKABLE flag - #10 by kisvegabor

Hello again,

after trying some more options I eventually decided to just disable all inputs “manually” by recursively looping through the background’s (screen obj) children and disabling the CLICKABLE flag for each child. It turns out that this is the only flag that needs to be disabled, disabling and re-enabling other flags afterwards lead to unexpected results.

Here are the functions used for those interested:

void custom_set_children_input(lv_obj_t* parent, bool enable)
    uint32_t childCnt = lv_obj_get_child_cnt(parent);

    for (int32_t i = 0; i < (int32_t)childCnt; i++)
        lv_obj_t* child = lv_obj_get_child(parent, i);
        custom_set_input(child, enable);
        custom_set_children_input(child, enable);

void custom_set_input(lv_obj_t* obj, bool enable)
    void (*setInputFunc)(lv_obj_t*, lv_obj_flag_t) = &lv_obj_add_flag;

    if (!enable)
        setInputFunc = &lv_obj_clear_flag;

    setInputFunc(obj, LV_OBJ_FLAG_CLICKABLE);

After disabling all inputs I add the messagebox as a child of the background: all inputs here will still be enabled normally because it is added after disabling the other children’s input.

Hope this post helps others also trying to do the same thing! I mainly wanted to avoid the semi-transparent background because redrawing the whole screen takes too much time.

Hello Tinus,
I used “Window” widget and the icon in background still touchable, so we have the same problem.

I thought about your approach, but I found a new problem:
Some object was untouchable default like “image”, but your function set all children touchable.

  • Have you found a more official solution?

Thank you, my friend.

Yes, I have. See: Lv_roller strange behavior when clearing/adding CLICKABLE flag - #11 by Tinus

This might also work with the window widget, if you set lv_layer_top() as its parent inside the lv_win_create() function.

I have an idea, why not create popup window on “lv_layer_sys()”.
lv_obj_add_flag(lv_layer_top(), LV_OBJ_FLAG_CLICKABLE); Can disable touch lv_layer_top().

  • Do you think it’s feasible?

Hello, if you want to use a window as a popup, I would recommend creating a custom msgbox object and following the steps I did, it works well.
lv_layer_sys() just returns the current active screen of the default display, which means you are drawing the window next to existing objects on that screen instead of on top of it.

Yes, I create window (message box) at the Top-Layer now and it work fine.
But I found a new problem, if more than one window (message box) created at Top-Layer, it would still suffers from front and back click response issues.

  • That’s a very interesting question.

Glad to hear it works. Perhaps you could disable input on the previously created messagebox when you make a new one? If I’m correct, everything below lv_layer_top will still be unclickable.


The layer_top can be used by the user to create some content visible everywhere. For example, a menu bar, a pop-up, etc. If the click attribute is enabled, then layer_top will absorb all user click and acts as a modal.

Popup windows nesting is only for discussion, it should be avoided in the application, after all, the MCU is not a computer.