fix (callbacks): Refcount mess in mvAddCallback() and mvRunCallback()

[v-ein]

---

name: Pull Request
about: Create a pull request to help us improve
title: Refcount mess in mvAddCallback() and mvRunCallback()
assignees: ''

---

Closes #2036

Description:
This fix looks remarkably similar to PR #2282 by @bzczb, who deserves recognition for finding all the hidden gems quirks and overall for great job on fixing the issue (trust me, this rabbit hole was deep). However, in fact this PR is the result of "parallel evolution" of my own fix, and therefore bears some differences, too. One of them is how callbacks in the queue are handled when their "parent" mvAppItem gets deleted - currently both fixes have some visible side effects in this case. I'm going to add yet another fix on top of this (as a separate PR but still the same release) and try to keep delete_item behavior backward compatible for most scenarios/users.

This PR also includes some changes that got mixed with it over time and I decided to bring them along rather than waste time trying to separate things:

• It adds on_close call to popup windows - this fixes on_close has no effect for popup windows #2372.
• The item_visible handler now passes the ID of the widget in app_data, like other handlers do.
• destroy_context now works way better and waits for all callbacks to complete before shutting down everything - fixes Resize handlers might be running while DPG context is being destroyed #2020.

Also, the PR fixes some other issues that are not directly related to reference counting but are related to the callback mechanism:

• It removes the two-step callback scheduling in set_frame_callback - this fixes set_frame_callback is racy and can lose callbacks #2269.
• Callbacks now honor the "manual callback management" mode - fixes Handler Registry callbacks are not placed into the global callback queue #2208.
• It fixes a race condition between the callback queue and item deletion (when the item gets deleted but its callback is still in the queue) - fixes Application crashes when deleting custom series #2427.

Concerning Areas:
After merging this PR, delete_item will behave a bit differently: if a callback for the item being deleted is running (including the case where you call dpg.delete_item(sender) from the callback), the item will be kept alive until the callback completes. All subsequent callbacks waiting in the queue will be thrown away, but the current callback will work as if the item never got deleted. Well, you won't be able to actually access the item, but it will prevent creation of another one with the same tag/UUID 😅.

I'm going to add yet another PR to reduce some unexpected side effects of this change in behavior.