C / C++ / MFC

3-Jan-12 14:17

I'm building a simple editor in a CFrameWnd using a CRichEditCtrl for the text.

As a stand-alone application everything works.
When I put the same frame code into a regular DLL, most things still work, but all custom accelerators don't function (things like Ctrl-V, Ctrl-C, etc. which are handled by the CRichEditCtrl do).

I've been able to recreate this same problem with the CMainFrame code generated by the Visual Studio Wizard.

Does anyone have any suggestions?

NciTom

Satheesh15463-Jan-12 16:37

Satheesh1546

3-Jan-12 16:37

Hi,

May be the following link will help you.

http://social.msdn.microsoft.com/Forums/en-US/vcmfcatl/thread/8bbdbd37-8034-4489-bd86-2351f0febb37

Cheers

ncitom4-Jan-12 6:06

4-Jan-12 6:06

Thanks Satheesh,

Unfortunately the link you suggest is one that I started in MSDN. Since it didn't get resolved there, I tried this forum.

patup93-Jan-12 21:22

patup9

3-Jan-12 21:22

Try to change the regular dll to MFC extension dll.

ncitom4-Jan-12 6:18

4-Jan-12 6:18

Patup,

Thanks,
Easier said than done. Frown | :(

I took the trivial mainfrm code from a wizard generated single document app and massaged it into an extension DLL. I can get it to compile, but it traps during the load of the MainFrm window.

Does anyone know of an example of an extension DLL that loads a CFrameWnd?

Randor 4-Jan-12 7:21

Randor

4-Jan-12 7:21

ncitom wrote:
I took the trivial mainfrm code from a wizard generated single document app and massaged it into an extension DLL.

Based on your brief description... it sounds like something related to either activation context[^] or the MFC module state[^].

I would be willing to have a look at your test case if you could put it up somewhere where I could download. However I offer no guarantees. Smile | :)

Best Wishes,
-David Delaune

ncitom4-Jan-12 8:43

4-Jan-12 8:43

David,

I must have put a typo into my program somewhere. I started over and successfully made an extension dll that works (albeit just a trivial version of my project).

It also seemed to solve the accelerator problem. Hopefully that's the answer to quite a few issues I've seen with MFC in a DLL. Smile | :)

Thanks,
Tom Wanat

Randor 4-Jan-12 9:02

Randor

4-Jan-12 9:02

Tom,

That's great to hear. Feel free to come back if you have any other problems. It's amazing that after you joined the codeproject that you were able to remain silent for 8 years, 8 months. Hopefully we will hear back from you before another 8 years pass. Smile | :)

Best Wishes,
-David Delaune

ncitom4-Jan-12 12:06

Dynamic menu with statusbar messages.

4-Jan-12 12:06

David,

I have visited codeproject many times during that period. I think of it as one of the most reliable sources of information.

I don't usually ask questions until I've exhausted other avenues, and I don't feel that confident to offer my experience.

Thanks for noticing,
Tom Wanat

Maximilien3-Jan-12 10:24

3-Jan-12 10:24

I build a dynamic menu "system" based on a hierarchy of files and folder (based on the MFCIE sample on msdn).

When I add my item to the menu I do something like :

CString menuString("my menu entry");
pMenu->AppendMenu(MF_STRING | MF_ENABLED, menuID, menuString);

In the CMainFrame::OnCmdMsg I handle the CN_COMMAND and CN_UPDATE_COMMAND_UI messages to handle the commands associated to the menu entries.

That is working fine.

Now, I'd like to be able to display a message in the status bar when the user moves the mouse over the menu items.

normally on "static" menu , I set the menu string (including mnemonic) in the resource and add an associated STRINGTABLE entry for the menu ID :

...
        MENUITEM "DoSomething\tF5", ID_DO_SOMETHING
...

STRINGTABLE 
BEGIN
    ID_DO_SOMETHING "Do Something\nMEssage that explains DoSomething"
END

-----
Is there an API to do that ? As far as I can see and read in MSDN there's nothing for it.

Or what should I do to do this "manually" ? I assume I have to do some kind of mouse tracking (and onIdle or timer?) to get the menu item and post a relevant text to the status bar.

Thanks.

Watched code never compiles.

ThatsAlok3-Jan-12 19:19

ThatsAlok

3-Jan-12 19:19

Havn't done it myself, does CStatusBar[^] MFC class of any help?

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture

cheers,
Alok Gupta
VC Forum Q&A :- I/IV
Support CRY- Child Relief and You

Maximilien4-Jan-12 3:35

4-Jan-12 3:35

No issue in adding text to the status bar in general, just when moving the mouse over the dynamic menu items.

looking for the place where the mouse is handled when the menu is opened (showing).

Thanks.

Watched code never compiles.

Randor 4-Jan-12 0:59

Randor

4-Jan-12 0:59

Hey Max,

I invested a couple of minutes into downloading and looking at the Microsoft sample. I am assuming that you are referring to the dynamic menu being built to hold the user favorites. It looks like the author of the code sample used 0xE00 as a magic number for the beginning ID-offset of those dynamic menu items.

You stated in your post that you are already using ON_UPDATE_COMMAND_UI and that it was working for the other menu items. Therefore I would recommend that you use:

ON_UPDATE_COMMAND_UI_RANGE[^]

Since we know that the author of the code sample used the magic number 0xE00 as the starting ID... then you could do something like:

C++

ON_UPDATE_COMMAND_UI_RANGE(0xE00,0xE00 + 0xFF, &CMainFrame::OnUpdateFavorites) //Might want to increase the top number

With this minor change the code sample will fire OnUpdateFavorites when the user moves the mouse over those favorites. You would also need to modify the code where the author does not set a menu ID on some of the sub menus. Either put them into the magic number range or create a new magic number range. Keep in mind that because the status bar was not created with a resource ID... it gets the default MFC id of AFX_IDW_STATUS_BAR. You could change this resource ID and obtain full control over your status bar.

Some additional off-topic comments:
The code sample is poorly written and uses a recursive function for building that menu based on a folder layout on the users hard drive. It would be possible to craft a folder layout that would cause this code sample to recursion until a stack overflow occurred. The code sample also does not handle NTFS junction points which could also be used to generate a stack overflow. If you intend to use this code in a commercial product you may want to re-design the function that builds the favorites menu. I did not perform a full code review so there may be other issues.

Best Wishes,
-David Delaune

modified 4-Jan-12 10:15am.

Maximilien4-Jan-12 4:13

4-Jan-12 4:13

I'm not using ON_UPDATE_COMMAND_UI but CN_UPDATE_COMMAND_UI in CMainFrame::OnCmdMsg.

AFAIK, The ON_UPDATE_COMMAND_UI(_RANGE) and CN_UPDATE_COMMAND_UI will be called when the menu is created, not when the mouse moves over the different menu items

If I use the range, I still have to manage/handle each item individually to find out which one I click I selected to be able to "do" whatever I need to "do" (that is working perfectly with the code in CMainFrame::OnCmdMsg), in my case it is to open a file (

I've already fixed some of the issues that could be found in the msdn samples.

My only issue is not the adding/handling of dynamic menu items, it is only display the associated text in the statubar when the mouse moves over menu items.

Anyway, it is only a small enhancement for now.

Thanks.

Watched code never compiles.

Randor 4-Jan-12 4:31

Randor

4-Jan-12 4:31

Maximilien wrote:
AFAIK, The ON_UPDATE_COMMAND_UI(_RANGE) and CN_UPDATE_COMMAND_UI will be called when the menu is created, not when the mouse moves over the different menu items

No, that is not correct. ON_UPDATE_COMMAND_UI and ON_UPDATE_COMMAND_UI_RANGE is called when the UI may potentially require an update. (Such as when the user moves his mouse over the menu item)

Btw... you do know that... ON_UPDATE_COMMAND_UI is a handler for CN_UPDATE_COMMAND_UI right?

C++

#define ON_UPDATE_COMMAND_UI(id, memberFxn) \
	{ WM_COMMAND, CN_UPDATE_COMMAND_UI, (WORD)id, (WORD)id, AfxSigCmdUI, \
		(AFX_PMSG) \
		(static_cast< void (AFX_MSG_CALL CCmdTarget::*)(CCmdUI*) > \
		(memberFxn)) },

#define ON_UPDATE_COMMAND_UI_RANGE(id, idLast, memberFxn) \
	{ WM_COMMAND, CN_UPDATE_COMMAND_UI, (WORD)id, (WORD)idLast, AfxSigCmdUI, \
		(AFX_PMSG) \
		(static_cast< void (AFX_MSG_CALL CCmdTarget::*)(CCmdUI*) > \
		(memberFxn)) },

Anyway... I have shown you how you can update the status bar when the mouse moves over the menu item using ON_UPDATE_COMMAND_UI_RANGE. I tested this and it absolutely works, I can update the status bar in the MFCIE sample with the favorite URL.

I do not know if you can use CMainFrame::OnCmdMsg to recieve these messages... I have not tested it. The reason I mentioned AFX_IDW_STATUS_BAR in my previous post was to illustrate that you are essentially using the MFC status bar if you are using this default ID. MFC generally implements a message filter... ingoring messages not intended for it. This is how menu items are greyed out in MFC if they do not have a handler.

I'll do a test here in a few minutes to see if I can catch that menu ID range in CMainFrame::OnCmdMsg.

Best Wishes,
-David Delaune

[UPDATE]

Sorry about the long delay... I was briefly sidetracked.

I have confirmed that I can also catch the menu id and index inside CMainFrame::OnCmdMsg

C++

BOOL CMainFrame::OnCmdMsg(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO* pHandlerInfo)
{
	if(nCode == CN_UPDATE_COMMAND_UI)
	{
		CCmdUI *pCmdUI = reinterpret_cast<CCmdUI *>(pExtra);
		if(NULL != pCmdUI)
		{
			TRACE2("%d : %d\n",pCmdUI->m_nID,pCmdUI->m_nIndex);
		}
	}
	return CFrameWnd::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo);
}

modified 4-Jan-12 10:58am.

Maximilien4-Jan-12 5:22

4-Jan-12 5:22

Thanks for your time; I kind of suck this year!

Will look into it.

Max.

Watched code never compiles.