Error when converting VC 6 project

I've been out of the VC world for years now. I'm trying to build an old project and I'm getting this error:

Code:

---

Error        2        error C2440: 'static_cast' : cannot convert from 'BOOL (__thiscall CMainFrame::* )(void)' to 'AFX_PMSG'        d:\user\alin\vc++\xcp_diag v 1.0.0 beta4\mainfrm.cpp        99        1        XCP

---

Mainframe.cpp:

Code:

---

BEGIN_MESSAGE_MAP(CMainFrame, CMDIFrameWnd)
        //{{AFX_MSG_MAP(CMainFrame)
        ON_WM_CREATE()
        ON_COMMAND(ID_STOP_LOG, OnStopLog)
        ON_COMMAND(ID_START_LOG, OnStartLog)
        ON_UPDATE_COMMAND_UI(ID_START_LOG, OnUpdateStartLog)
        ON_UPDATE_COMMAND_UI(ID_STOP_LOG, OnUpdateStopLog)
        ON_COMMAND(ID_APP_SET_ADDR_INTEL, OnAppSetAddrIntel)
        ON_COMMAND(ID_APP_SET_ADDR_MOT, OnAppSetAddrMotorola)
        ON_UPDATE_COMMAND_UI(ID_APP_SET_ADDR_INTEL, OnUpdateAppSetAddrIntel)
        ON_UPDATE_COMMAND_UI(ID_APP_SET_ADDR_MOT, OnUpdateAppSetAddrMotorola)
        ON_WM_TIMER()
        ON_WM_CLOSE()
        ON_COMMAND(ID_FILE_SAVE_LOG, OnSaveLogFile) --> This is where the compiler reports the error.
        //}}AFX_MSG_MAP
END_MESSAGE_MAP()

---

Mainframe.h:

Code:

---

afx_msg BOOL OnSaveLogFile();

---

Thanks,
Alin

http://msdn.microsoft.com/en-us/library/f9es2det.aspx

Should return void, not BOOL.

gg

I mean to remember that I had the same error some years ago when porting a VC6 project to VC8 (VS2005).

The ON_COMMAND macro tries to "cast" a function pointer of a member function of the current class to the signature the handler function of a WM_COMMAND message does require. If this fails in a later version of VC it could be either because the signature has changed in the meanwhile, i. e. the OnCommand handler needs now a different interface, or because the compiler wouldn't accept that kind of cast at all. The latter is less likely if you made sure that the ON_COMMAND macro comes from a header of the new compiler version and not from VC6, i. e. if you don't have a mixed environment.

If you could post the definition of the AFX_PMSG macro (press F12 on that macro) I probably would remember what I did to solve the issue.

AFAIK, the message handler signature for ON_COMMAND macro is

Code:

---

afx_msg [B]void/B] OnSomething(void)[

---

*not* afx_msg BOOL ...

Oh, CodePlug did remember (google) faster than me :D

thanks for the replies.

i still remember the ON_COMMAND signature is void ;)), but at the same time my function returns BOOL and i need it to be that way. is there a cast i could try to make it accept BOOL like afx_msg BOOL OnSaveLogFile()?

Hi Alin,

Quote:

---

Originally Posted by Alin

is there a cast i could try to make it accept BOOL like afx_msg BOOL OnSaveLogFile()?

---

Nope. Not good. No way.

Quote:

---

MSDN
WM_COMMAND Message
Return Value
If an application processes this message, it should return zero.

---

And that MFC does.
However, if really makes sense for you to return other value, use ON_MESSAGE macro instead.
Although I'm wondering if something like that has any sense or effect.

Code:

---

afx_msg void MMOnSaveLogFile() {OnSaveLogFile();}

---

Use that in your message map.

gg

Quote:

---

Originally Posted by Codeplug

Code:

---

afx_msg void MMOnSaveLogFile() {OnSaveLogFile();}

---

Use that in your message map.

gg

---

That did the trick, thanks very much.

Quote:

---

my function returns BOOL and i need it to be that way

---

A BOOL return in a message map function is senseful if there is a default handling which you can invoke by returning FALSE what means "not handled". As MS did change the signature for OnCommand handlers you can be sure there is no default handling. Hence returning a BOOL or not makes no difference. So I would change the signature of my handler function in order to have a correct interface and remove the return statements accordingly.

If you need a BOOL return cause you need to call the function from another function, you better rename the old function to 'SaveLogFile' and call the void function OnSaveLogFile.

Quote:

---

Originally Posted by Alin

That did the trick, thanks very much.

---

Still wondering. Has it any effect, or it's only to compile?

Quote:

---

Originally Posted by ovidiucucu

Still wondering. Has it any effect, or it's only to compile?

---

In VC8 help they described ON_COMMAND_EX with

Quote:

---

An extended form of command message handlers is available for advanced uses. The ON_COMMAND_EX macro is used for such message handlers, and it provides a superset of the ON_COMMAND functionality. Extended command-handler member functions take a single parameter, a UINT containing the command ID, and return a BOOL

---

So it looks as ON_COMMAND_EX has now the functionality of former ON_COMMAND and that newer ON_COMMAND only will accept a void handler.

Quote:

---

Originally Posted by itsmeandnobodyelse

In VC8 help they described ON_COMMAND_EX with
...
So it looks as ON_COMMAND_EX has now the functionality of former ON_COMMAND and that newer ON_COMMAND only will accept a void handler.

---

This ON_COMMAND_EX looks like the old ON_CONTROL_REFLECT macro. Doesn't it?

Don't know exactly but I mean to remember that the _REFLECT macros were to redirect messages normally sent to the parent dialog to the (derived) control itself.

See here for details: http://msdn.microsoft.com/de-de/libr...(v=vs.80).aspx

>> ... ON_COMMAND_EX has now the functionality of former ON_COMMAND and that newer ON_COMMAND only will accept a void handler.
http://msdn.microsoft.com/en-us/libr...8VS.60%29.aspx
They've both been the same since 6.0.
The original code compiled under 6.0 either because the conversion was forced or the compiler silently accepted it.

gg

You are right. I remember now. The newer macros use reinterpret_cast which fails when the return type differs. The VC6 uses old C cast which doesn't complain.

Quote:

---

Originally Posted by itsmeandnobodyelse

The newer macros use reinterpret_cast which fails when the return type differs.

---

Here, reinterpret_cast instead of C-style cast would be "aceeasi Marie cu alta palarie" ("the same Mary with another hat"). Alin, please tanslate a little bit better! :)
I.e. nothing really different.

In fact, newer vesions of MFC use static_cast to avoid nasty troubles because of wrong handler function signatures.

Code:

---

#define ON_COMMAND(id, memberFxn) \
  { WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSigCmd_v, \
      reinterpret_cast<AFX_PMSG> (memberFxn) },

---

where AFX_PMSG is

Code:

---

typedef void (AFX_MSG_CALL CCmdTarget::*AFX_PMSG)(void);

---

See MSDN:Incorrect Function Signatures May Cause Problems in Release

Quote:

---

Originally Posted by ovidiucucu

Here, reinterpret_cast instead of C-style cast would be "aceeasi Marie cu alta palarie" ("the same Mary with another hat"). Alin, please tanslate a little bit better! :)

---

I compared C cast of VC6 with reinterpret_cast of newer versions (since VC7 == VS2003 or later). So, it wasn't a valuation of whether static_cast or reinterpret_cast was more suitable to replace a C cast (though I don't like neither of the new ones) but only an attempt to explain why the cast failed in the newer versions.

I don't think that C cast is the same as reinterpret_cast in common but you surely are right regarding casting of function pointers.

Quote:

---

Originally Posted by itsmeandnobodyelse

I compared C cast of VC6 with reinterpret_cast of newer versions (since VC7 == VS2003 or later). So, it wasn't a valuation of whether static_cast or reinterpret_cast was more suitable to replace a C cast (though I don't like neither of the new ones) but only an attempt to explain why the cast failed in the newer versions.

I don't think that C cast is the same as reinterpret_cast in common but you surely are right regarding casting of function pointers.

---

First, please keep in mind that even you like or not, reinterpret_cast and static_cast ARE different stuff.

Second, please note that nobody is perfect, then can do mistakes; saying "Ok, I was wrong/made a typo/didn't know" may be appreciated in a greater degree than "I'm always right. My intention was to say someting else but just wanted to foolish you, supid".

Third, before posting please give a breath, think about your answer, and only after that push the "Submit Reply" button.

It makes not the sligthest difference if you do a reinterpret_cast or a static_cast on a function pointer beside that the one may compile while the other doesn't.

So Mary still wears the same hat. Relax. :D

Quote:

---

Originally Posted by itsmeandnobodyelse

So Mary still wears the same hat. Relax. :D

---

There are significant differences between C++ casting operators. They are not introduced for nothing.
Please read more and stop fluffing threads!