Split Frame Never Returns

[lbrendel-signum]

I have created a Widget that acts like a Message Box based on an older discussion post and I am having issues with its usage and dpg.split_frame being inconsistently working. If I create the Message Box on a separate thread that i create to run the window pops up fine. If i call it from within a callback of another dpg item when split_frame is called it never returns and the program hangs. Are there limitations as to where split_frame can be called or should i be handling this differently?

with dpg.mutex():
    viewport_width = dpg.get_viewport_client_width()
    viewport_height = dpg.get_viewport_client_height()
    with dpg.window(label=title, modal=True, no_move=True, no_collapse=True, tag=self.tag):
        dpg.add_text(message)
        dpg.add_button(label="OK", callback=lambda: dpg.delete_item(self.tag))
dpg.split_frame()
width = dpg.get_item_width(self.tag)
height = dpg.get_item_height(self.tag)
dpg.set_item_pos(
    self.tag,
    [(viewport_width - width) // 2, (viewport_height - height) // 2],
)
while dpg.does_item_exist(self.tag) and dpg.is_item_shown(self.tag):
    dpg.split_frame()

[v-ein]

Technically, a call to split_frame from within with dpg.mutex() must hang up. The mutex will block rendering and split_frame must wait for a frame to be rendered, which will never happen because of the mutex. If split_frame does not hang up for you, it's a bug 😂. Don't worry, I'll eventually fix it! 🤣 (I'm serious, one of my planned fixes is to make split_frame release right after the end of frame rather than wait 32 milliseconds, so I'll eventually revisit split_frame's code).

[lbrendel-signum]

Thanks for the response but i just realized that my formatting got messed up in the code. Let me fix that. The split_frame is not suppose to be under the mutex

[v-ein]

Okay, but now the code is going to loop while self.tag exists and its show flag is True. What is the purpose of this loop? Anyway, I presume the only way the loop is supposed to end is by user pressing the OK button... But this won't work because the callback for the button click will be put into the handler queue, and will not start until the current callback is finished - but the current callback is endlessly looping on split_frame... Looks like a deadlock.

[lbrendel-signum]

@v-ein Yes it was meant to act as a means to prevent following code from executing in the event that the message box was visible. Then when the user closed it then the code could continue one because the window was destroyed. The split_frame that occurs right after the mutex ends is the first one that never returns and is there so the window can be drawn to get the dimensions to then center the window.

I will try some other scenarios to see if i can if i can get more data as to why sometimes the window appears just fine and others the split_frame hangs forever.

[v-ein]

Just move to a separate callback whatever should go after the message box, and call that callback on the button click:

def message_box(title: str, message: str, callback: Callable[[], None]) -> None:
    with dpg.mutex():
        viewport_width = dpg.get_viewport_client_width()
        viewport_height = dpg.get_viewport_client_height()
        with dpg.window(label=title, modal=True, no_move=True, no_collapse=True) as wnd:
            dpg.add_text(message)
            dpg.add_button(label="OK", callback=lambda: (dpg.delete_item(wnd), callback()))
    dpg.split_frame()
    width = dpg.get_item_width(wnd)
    height = dpg.get_item_height(wnd)
    dpg.set_item_pos(
        wnd,
        [(viewport_width - width) // 2, (viewport_height - height) // 2],
    )


... # your code that runs before the message box

def continue_work():
    ... # your code that runs after the message box

message_box("Test", "Lorem ipsum", callback=continue_work)

There are other alternatives, too, but they are a bit more complicated - like, you could schedule your code to a separate thread, probably running an asyncio loop, and then make message_box wait on an event that the button callback would signal. This way the calling code will look linear, at the expense of always using a separate thread to run the code (and DPG is not entirely thread safe at the moment).

[lbrendel-signum]

Thanks. I will look at this as an option and see if i can make something work.