Hiding pop-up menu

Have you tried using CMenu::RemoveMenu()? From MSDN:
Deletes a menu item with an associated pop-up menu from the menu. It does not destroy the handle for a pop-up menu, so the menu can be reused.

You do not need the ID to use RemoveMenu. Use the MF_BYPOSITION flag with the index of your popup menu.

Originally posted by neha75
However, when I delete the pop-up menu item when it's not available and without closing the app, open a file for which it is available, the item does not show up. When I exit the app and re-open the file, then it shows up again.
:confused: :confused:
Could you please repeat this step by step so everybody will be able to follow?

Mike,
Yes, I already have an ON_UPDATE_COMMAND_UI that checks for the availability of the functionality before displaying the menu item.

I am sorry if I was vague in my explanation. Let me explain what I want to do:

My application allows for two types of files: File1 and File2. The functionality differs in both types. File1 allows for Transmitting, while File2 is only for Receiving.
Both the Transmitting and Receiving menu items are pop-up menus with no IDs. So, in the ON_UPDATE_COMMAND_UI, I check whether the file being opened is File1. If it is, then I want to REMOVE the Receiving pop-up menu. If File2, then REMOVE the Transmitting pop-up menu.
This works fine the first time, meaning, when I execute the app and open File1, then only the Transmitting menu is available. However, the problem is that, if I open File2 after closing File1, then the Transmitting menu shows and the Receiving does not. If I close the app and run it again and open File2, then it is working fine.
I hope I explained the problem better now.

Thanks so much for your help!

ON_UPDATE_COMMAND_UI can be tricky for modifying menus, reason: if you change the menu it will retain the changes for ever. For example once you remove the Reciever menu you have to plug in that manually later if you want to see it again. We don't notice this when doing simple enable/disable because its always get decided at right time but when you remove a menu item, you will notice its gone for ever! you have to plug that in again.

I have had this problem before and I took a different approach to solve it but if you did this the way you are trying, I would like to see your code if you would post here.

Here is the code snippet:

CMenu *pMenu = ((CMainFrame*)AfxGetMainWnd())->GetMenu();
int MenuCount = pMenu->GetMenuItemCount();

for (int i=0; i < MenuCount; i++)
{
if (pMenu->GetMenuString(i, str, MF_BYPOSITION) &&
(strcmp(str, "Fe&ature") == 0))
{
nPos = i;
break;
}
}

CMenu* pSubMenu = pMenu->GetSubMenu(nPos);
int SubMenuCount = pSubMenu->GetMenuItemCount();

for (int n = 0; n < SubMenuCount; n++)
{
if (pDoc->isReceiveOn() == true)
{
if (pSubMenu->GetMenuString(n, str, MF_BYPOSITION) &&
(strcmp(str, "Receiver Alignments") == 0))
{
pSubMenu->RemoveMenu(n, MF_BYPOSITION);
}
}
}

I don't have a variable that I use to track. The variable that I use to check whether is receive is available is in the file itself, so I don't think I would need to have another one.

Thanks for your help!

I have to agree with quark. I don't see where you are re-adding the menu once you've removed it.

You should be doing the check during processing of the ON_UPDATE_COMMAND_UI handler. At that time, you would check to see if you need to remove or insert the menu. For example:

if (file_variable == "receive")
RemoveMenu();
else
InsertMenu();

I think the basis for your problem is the method you are using to determine if the menu should be removed or inserted. It appears that you may be relying on the menu itself to tell you instead of the contents of your file.

In MDI app, you could associate two different menus with different Document Temlates. Then you will not have to modify menus at run time!