C / C++ / MFC

Re: modifymenu question -about adding item

17-Jul-02 6:43

Its ID_FILE_CLOSE, Generally they follow the format:

ID_ is the lead characters
FILE the name of the menu the item resides in
CLOSE the name of the menu item

So for example ID_VIEW_TOOLBAR would allow toggling of the toolbar in view of an app.

Roger Allen
Sonork 100.10016

If I had a quote, it would be a very good one.

ns17-Jul-02 8:26

17-Jul-02 8:26

Thank you very much. I guess MSDN messed up! Works Fine.

However, if its a custom menu item I want to add, which has no ID defined in the class wizard (since I didnt put in into the design resource since I'm adding it programmatically), how would I make that work? I found ID_VIEW_TOOLBAR in the class wizard so its been predefined, but in

pos = FindMenuItem(submenu, "&Open...\tCtrl+O");
if (pos > -1)
submenu->InsertMenu(pos + 1, MF_BYPOSITION, ID_FILE_ARBITRARY, "&Arb");

whats ID_FILE_ARBITRARY? I didnt actually create a menu item in the resource editor else it would show up anyways at runtime. I dont see a way to make it invisible so that I only see it where I insert it and not where I positioned it in the resource editor menu layout.

Appreciate your insight,
ns

Re: modifymenu question -about adding item

Roger Allen17-Jul-02 8:49

17-Jul-02 8:49

ID_FILE_ARBITRARY would be the ID of the WM_COMMAND message you woule need to map. Once in the menu, you would have to write the handlers for them manually.

afx_msg void OnArbitrary() ;

ON_COMMAND(ID_FILE_ARBITRARY, OnArbitrary)

void CMyClass:OnArbitrary()
{
}

You will have to make sure that ID_FILE_ARBITRARY is #defined in resource.h and doesn't clash with an existing menu ID.

Roger Allen
Sonork 100.10016

If I had a quote, it would be a very good one.

ns17-Jul-02 8:57

17-Jul-02 8:57

I hadn't ever looked into resource.h (thats how new and splotchy my MFC experience is). So all I need to do is assign my arb ID a number thats not in there and I'm good to go, it seems. Theres no mention of ID_FILE_CLOSE etc so I guess they are taken care of somewhere else.

Okay if I use numbers from:

// Next default values for new objects
//
#ifdef APSTUDIO_INVOKED
#ifndef APSTUDIO_READONLY_SYMBOLS
#define _APS_3D_CONTROLS 1
#define _APS_NEXT_RESOURCE_VALUE 131
#define _APS_NEXT_COMMAND_VALUE 32783
#define _APS_NEXT_CONTROL_VALUE 1007
#define _APS_NEXT_SYMED_VALUE 101
#endif
#endif

or avoid these as well? eg. #define ID_FILE_ARB 131?

Thanks so much.
ns

Shog⁹17-Jul-02 11:13

Shog⁹

17-Jul-02 11:13

ns wrote:
Okay if I use numbers from:

These are ... housekeeping definitions used by the resource editor when adding new resources. The values are the ones used by the next resource of a given type added.

A good way to get a new, unique symbol defined is to use the View->Resource Symbols menu option in Visual Studio; this brings up a dialog letting you view existing symbols and add new ones, without having to manually edit resource.h (which could be troublesome if you're not careful and then later use the resource editor to add new resources).

--------

PMGRE

--Shog⁹ --

Roger Allen18-Jul-02 0:11

18-Jul-02 0:11

ID_FILE_CLOSE and other standard MFC menu commands etc are defined inside the MFC headers. These shouldn't be changes otherwise you stop the MFC from working so that why thier not in your resource.h.

When adding your own ID's manually (unlike what Shog9 said), if you were to use the next available ID specified by

#define _APS_NEXT_RESOURCE_VALUE 131

You would have to increment this #define in the file so that the next autmatically added one would not clash with the one you just added manually.

#define ID_FILE_MYCOMMAND 131
#define _APS_NEXT_RESOURCE_VALUE 132

Roger Allen
Sonork 100.10016

If I had a quote, it would be a very good one.

who handles ID_FILE_OPEN?

ns18-Jul-02 1:22

18-Jul-02 1:22

My thanks to both of you. I appreciate your input tremendously,
ns

Outlook GUI!!!

tongc17-Jul-02 6:02

tongc

17-Jul-02 6:02

Hi
Is there anyway that i can make my application have the looks of Outlook?? If yes, then where will i get that class?

Thanks alot!!!

Re: Outlook GUI!!!

benjymous17-Jul-02 6:19

benjymous

17-Jul-02 6:19

how about searching this site for articles that have "outlook" in the title?

--
Help me! I'm turning into a grapefruit!

Re: Outlook GUI!!!

tongc17-Jul-02 7:11

tongc

17-Jul-02 7:11

sorry, i should've done this before!!! Frown | :(

Thanks for the advise Smile | :)

ns17-Jul-02 5:48

17-Jul-02 5:48

I checked all the doc/view classses but didnt find a handler for the pre-existing VC ID_FILE_OPEN menu item. Which class handles the COMMAND for this ID? If it were the view class, and I wanted to remotely trigger this menu, could I say:

AFxGetMAinWnd()->SendMessage(WM_COMMAND, ID_FILE_OPEN)?

Does it matter who is handling this command? CAn this work even if any class were to be handling it?
Thanks,
ns

Re: who handles ID_FILE_OPEN?

Roger Allen17-Jul-02 5:56

Re: who handles ID_FILE_OPEN?

17-Jul-02 5:56

CWinApp does, or your CWinApp derived class does.

You should find these entries in your CWinApp derived class's message map

// Standard file based document commands
ON_COMMAND(ID_FILE_NEW, CWinApp::OnFileNew)
ON_COMMAND(ID_FILE_OPEN, CWinApp::OnFileOpen)

Roger Allen
Sonork 100.10016

If I had a quote, it would be a very good one.

ns17-Jul-02 6:01

17-Jul-02 6:01

Thank you. So why do we send a message to the AfxGetMainWnd() object rather than AfxGetApp()? THe former works. Havent tried the latter.

One odd thing I found is that if my menu item is handled locally by the class thats sending the message, I dont have to Afx -> sendmessage it, just a direct sendmessage (since its to this->). So looks like the message has to be sent to the class that handles the command. In retrospect thats obvious....

So why AfxGetMainWnd (which returns the mainframe right? )and not AfxGetApp who is handling the ID?
Thanks,
ns

hmmmm- why cant we send msgs to the App?

ns17-Jul-02 6:05

17-Jul-02 6:05

I got the error:

C:\swanke\A20\WzdView.cpp(124) : error C2039: 'SendMessageA' : is not a member of 'CWinApp'

So I suppose we have no choice but to send it to MAinWnd......I wonder why we cant send messages to the app???

Roger Allen17-Jul-02 6:19

17-Jul-02 6:19

The CWinApp object itself is not a window and cannot "receive the message" itself. What happens I think is that the CMAinFrame command router pass's it through a message map belonging to the app/mainframe/doc/view (these may not be in the right order here) in order looking for the first one that handles the call.

So AfxGetMainWnd()->SendMessage() will get to the app object due to the internal MFC routing mechanism.

Roger Allen
Sonork 100.10016

If I had a quote, it would be a very good one.

ns17-Jul-02 6:27

17-Jul-02 6:27

MAny thanks. I need to read more about the message passing mechanism. SO I'm gathering that AfxGetMAinWnd is giving us back an object even hif=gher than the app object (which I thought was the highest) . The name makes it sound like its going to give back a CMAINFRAME * object, which I thought was aminframe object. Anywaqys sorry if this sounds confused...I'll do some reading. APpreciate your help!
ns

Ravi Bhavnani17-Jul-02 7:27

Ravi Bhavnani

17-Jul-02 7:27

Both CWnds and CWinApps are CCmdTargets and are therefore capable of providing handlers for commands. Note that true window messages (WM_mumble) can only be sent/posted to CWnds. The command routing mechanism of the doc/view architecture works like this:

The CView object gets first dibs at handling the message.
If it doesn't handle it, the enclosing frame window gets a chance.
If it doesn't handle it, the CDocument attached to the view gets a chance.
If it doesn't handle it, the CWinApp object gets the message.

Many standard commands are "automagically" handled because CWinApp provides handlers for them. Examples are File|Open,Save, Exit, Help, etc.

/ravi

Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com

dabs18-Jul-02 2:28

dabs

18-Jul-02 2:28

Actually, the order is like this:

1. The active view gets the first shot at processing the message
2. Then the document associated with the view gets it's chance
3. The document template is next.
4. The mainframe get's its chance now.
5. Finally, the application object gets it's chance.
6. If noone handled this message it goes to ::DefWndProc( );

This applies to WM_COMMAND and WM_NOTIFY messages.