| 1088 | |
| 1089 | |
| 1090 | void UserMenu::DestroyHandle() |
| 1091 | // Destroys the Win32 menu or marks it NULL if it has already been destroyed externally. |
| 1092 | // This should be called only when the UserMenu is being deleted (or the script is exiting), |
| 1093 | // otherwise any parent menus would still refer to the old Win32 menu. If the UserMenu is |
| 1094 | // being deleted, that implies that its reference count is zero, meaning it isn't in use as |
| 1095 | // a submenu or menu bar. |
| 1096 | { |
| 1097 | if (!mMenu) // For performance. |
| 1098 | return; |
| 1099 | // Testing on Windows 10 shows that DestroyMenu() is able to destroy a menu even while it is |
| 1100 | // being displayed, causing only temporary cosmetic issues. Previous testing with menu bars |
| 1101 | // showed similar results. There wouldn't be much point in checking the following because the |
| 1102 | // script is in an uninterruptible state while the menu is displayed, which in addition to |
| 1103 | // pausing the current thread (which happens anyway), no new threads can be launched: |
| 1104 | //if (g_MenuIsVisible) |
| 1105 | // return FAIL; |
| 1106 | |
| 1107 | // MSDN: "DestroyMenu is recursive, that is, it will destroy the menu and all its submenus." |
| 1108 | // Therefore remove all submenus before destroying the menu, in case the script is using them. |
| 1109 | // If the script is not using them, they will be destroyed automatically as they are released |
| 1110 | // by ~UserMenuItem(). |
| 1111 | for (UserMenuItem *mi = mFirstMenuItem; mi ; mi = mi->mNextMenuItem) |
| 1112 | if (mi->mSubmenu) |
| 1113 | RemoveMenu(mMenu, mi->mMenuID, MF_BYCOMMAND); |
| 1114 | |
| 1115 | DestroyMenu(mMenu); |
| 1116 | mMenu = NULL; |
| 1117 | } |
| 1118 | |
| 1119 | |
| 1120 |
nothing calls this directly
no outgoing calls
no test coverage detected