You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EVENT_TYPE_MENU_UPDATEs add themselves back to the event queue as long as the menu is open; if I'm understanding the code correctly, the only time they are removed from the queue is if a menu item is clicked, or if the menu overlay is disabled when the event handler is called, and there should really only be one in the queue at a time. If a menu is open, and another menu update event is added to the queue by clicking on an item in the menu bar, the first menu update event is not removed. Repeatedly clicking the same item on the menu bar will add more and more events to the queue, which will lag the system until the menu is closed and the events are removed.
I actually first ran into this issue when trying to open a menu when a different menu was already open. Since both events are in the queue, both of them attempt to update the menu whenever the mouse is over them, leading to a weird effect where the menu sort of runs away from the cursor.
event_type_menu_update_issue_2.mp4
The text was updated successfully, but these errors were encountered:
It's been a really long time since I last worked on menu stuff (the menu bar was the first UI element I ever implemented for fox32rom/os), so tbh my memory of how it all works isn't very good :p
When an event is fetched from the queue it is automatically removed from the queue, which is why menu_update_event re-adds them to the queue as long as the menu remains open. This results in menu_update_event continuously being called while the menu is open, which handles redrawing and detecting menu clicks. Unless I'm misunderstanding what you mean, this is intended (though whether it's actually a good system or not is debatable).
I think the main bugs here are the fact that clicking on the same menu bar item a bunch of times slows down the system, and that clicking on a different menu bar item while a menu is already open causes that effect where the menu runs away from the cursor. Also while I'm at it, implementing the ability to close the menu by clicking anywhere outside of the menu would be nice, rather than needing to click an empty space in the menu bar.
Thanks for confirming that this is the way the menu system works. Is it supposed to be possible for there to be more than one event of type EVENT_TYPE_MENU_UPDATE in the queue at once, or is this unintended?
EVENT_TYPE_MENU_UPDATEs add themselves back to the event queue as long as the menu is open; if I'm understanding the code correctly, the only time they are removed from the queue is if a menu item is clicked, or if the menu overlay is disabled when the event handler is called, and there should really only be one in the queue at a time. If a menu is open, and another menu update event is added to the queue by clicking on an item in the menu bar, the first menu update event is not removed. Repeatedly clicking the same item on the menu bar will add more and more events to the queue, which will lag the system until the menu is closed and the events are removed.
I actually first ran into this issue when trying to open a menu when a different menu was already open. Since both events are in the queue, both of them attempt to update the menu whenever the mouse is over them, leading to a weird effect where the menu sort of runs away from the cursor.
event_type_menu_update_issue_2.mp4
The text was updated successfully, but these errors were encountered: