C / C++ / MFC

Menu Item appears Grayed in MFC

13-Dec-01 6:43

If what you want is to allocate a little more space on top of the property sheet, add this snippet on your OnInitDialog():

CRect rectWnd;
GetWindowRect(rectWnd);
SetWindowPos(NULL, 0, 0,
    rectWnd.Width(),
    rectWnd.Height() + 100,
    SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE);

CWnd *pWnd=GetWindow(GW_CHILD);

while(pWnd!=NULL){
    CRect rect;
    pWnd->GetWindowRect(rect);
    rect.OffsetRect(0,100);
    ScreenToClient(rect);
    pWnd->MoveWindow(rect,FALSE);
    pWnd=pWnd->GetNextWindow();
}

(Of course you'll want to change the offset to fit the dimensions of the bitmap header.)

Joaquín M López Muñoz
Telefónica, Investgación y Desarrollo

13-Dec-01 5:53

I have added a Menu Item to Popup default item File. After adding the Coommand Handler, when I run the app, the Menu item that I added appears Grayed. I am not sure why that is happening when the properties are not set to be disabled nor the code is written to do so. What would make the item Enabled or non-grayed by default.

Joaquín M López Muñoz13-Dec-01 6:14

13-Dec-01 6:14

Well, seems like MFC is not being able to locate the Command handler you wrote for that menu item. You could check if the handler is correct by creating a non popup menu (a fixed menu on the main windows, for instance) and inserting a menu item with the same ID. If the command handler is correct that item should be enabled (and the problem lies elsewhere).

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

13-Dec-01 8:30

When I drag the Item to main bar, it is not grayed. Only when I nest it in the File option, it gets Grayed. I have the OnUpdateYourMenuItem too. Tried adding code to ENABLE the Item and still no luck.

Rick York13-Dec-01 8:13

Rick York

13-Dec-01 8:13

Do you have a a OnUpdateYourMenuItem(CCmdUI *pCmdUI) handler for this menu item ? If you don't the menu item is disabled by default.

13-Dec-01 9:27

I did edit the ID few days back but, surprisingly, it doesn't behave that way when I have it at top level. Only when I make it a subitem, or within a popup, it gets grayed for no reason. I rebuild the files but no effect.

Rick York13-Dec-01 10:19

Rick York

13-Dec-01 10:19

The reason that changes to resource.h do not always result in a recompilation is that VC++ insists on putting a line that says NO_DEPENDENCY at the top of it. I find this incredibly annoying. Why couldn't they make it a selectable option ?

Rick York13-Dec-01 11:00

Rick York

13-Dec-01 11:00

You are exactly right and that is why it annoys me so much. I have figured out how to play their game though and remove the NO_DEPENDENCY line with a minimum of headache. I do this in nearly every project I work on. With the speed of computers these days I can think of no good reason to have anything NOT dependent on resource.h that uses it. It only causes problems and does provide no benefit.

Difference of behavior: WXP vs W2K ???

13-Dec-01 11:44

Finally I found out the solution. I didn't associate the Menu to Main Frame. Instead I did to one of the views. Surprisingly it let me pick a view.

Mickael Pointier13-Dec-01 5:51

Mickael Pointier

13-Dec-01 5:51

Hi.

One of the applications I've coded refuse to work correctly on WinXP (but was working fine for months under Windows 2000). I wonder if someone else notice this kind of problem.

More specificaly, I'm using anonymous pipes to make the two parts of my application communicate, but unfortunately the created process never get the handle of the pipes the main process creates. It results in the fact the the child process get the standard STDIN/OUT/ERR handles when it does GetStdHandle(). Confused | :confused:

[Note: I'm not using CreateProcess, but CreateProcessWithLogonW. I can send a part of the code if it helps.]

Hungar Convention/Norm/Method

Carlos Antollini13-Dec-01 4:24

Carlos Antollini

13-Dec-01 4:24

Any body here Know where I can find some documentation about that?

Best Reagrds....
Green Alien | [Alien]

Tomorrow is Friday!!!

Carlos Antollini.
Sonork ID 100.10529 cantollini

Joaquín M López Muñoz13-Dec-01 5:08

13-Dec-01 5:08

The foundational paper by Charles Simonyi.
It is my impression that Hungarian notation has fallen into some discredit during the last years, mainly because it promotes a very loose way of type checking. Languages more modern than C (like C++) have stricter type checking systems that render this kind of nmenomics redundant in the best case (or false in the worst, if you changed the type of a variable and forgot to rename it).

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Carlos Antollini13-Dec-01 6:07

Carlos Antollini

13-Dec-01 6:07

Gracias Joaquin, Big Grin | :-D

Muy util, tu información.... Rose | [Rose]

Best Regards!!!!

Carlos Antollini.
Sonork ID 100.10529 cantollini

Joaquín M López Muñoz13-Dec-01 6:20

13-Dec-01 6:20

De nada

Si te interesa el tema, échale un vistazo a este divertido artículo de Jim Hyslop y Herb Sutter en contra de la notación húngara.

If you're interested in this subject, check this funny article by Jim Hyslop and Herb Sutter against Hungarian notation.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo