Compiler warning with C++/CLI & ON_BN_CLICKED

[dan]

I am trying to port a legacy MFC application to C++/CLI. I have
managed to build the code under VS 2008 and I am in the process of
enabling the /CLR compiler directive. My goal is to try and convert
the application to a series of Mixed assemblies that will run
under .NET.

The application makes use of Message Maps using standard MFC
conventions.

I have noticed that any Message Maps using the ON_BN_CLICKED header
directive leads to the compiler warning

C4793 function compiled as native non-clr call vcall thunks must be
compiled as native

ON_BN_CLICKED is defined as ON_CONTROL( BN_CLICKED, id, memberFxn )

and ON_CONTROL( BN_CLICKED, id, memberFxn ) reduces to

{WM_COMMAND, (WORD) wNotifyCode, (WORD) id, (WORD) id, AfxSigCmd_v,
(static_cast< AFX_PMSG > (memberFxn)) },

So there must be an issue with .NET and the WM_COMMAND statement. Is
there a stanard way to replace ON_BN_CLICKED in a .NET friendly manner
so that I can compile my ON_BN_CLICKED messag maps in C++/CLI without
the compiler warning.

 

[Jochen Kalmbach [MVP]]

Hi dan!

I am trying to port a legacy MFC application to C++/CLI. I have
managed to build the code under VS 2008 and I am in the process of
enabling the /CLR compiler directive. My goal is to try and convert
the application to a series of Mixed assemblies that will run
under .NET.

I suggest to enable /clr just to specific files, which needs this feature.

C4793 function compiled as native non-clr call vcall thunks must be
compiled as native

As the _warning_ says:
(Some) virtual functions must be compiled as native...

So there must be an issue with .NET and the WM_COMMAND statement. Is
there a stanard way to replace ON_BN_CLICKED in a .NET friendly manner
so that I can compile my ON_BN_CLICKED messag maps in C++/CLI without
the compiler warning.

Disable /clr for this file.

Greetings
Jochen

 

[dan]

Hi dan!


I suggest to enable /clr just to specific files, which needs this feature..


As the _warning_ says:
(Some) virtual functions must be compiled as native...


Disable /clr for this file.

Greetings
   Jochen

Disabling /clr for each file with an ON_BN_CLICKED would remove a
significant percentage of the files in my app, so I do not think it is
an option.

I doubt that the C++/CLI would ship with a bug of this size.
ON_BN_CLICKED is very common in MFC.

Either I am using some unusual combination of old header files that
are doing something non-standard or there is something about my
project configuration that leads to the compiler warning.

I guess the next step is to build a small MFC app that calls
ON_BN_CLICKED in a message map. If I can get that app in C++/CLI, I
will try and figure out the difference between the example and my
application. Otherwise, there is a C++/CLI bug.

Dan

 

[David Wilkinson]

Disabling /clr for each file with an ON_BN_CLICKED would remove a
significant percentage of the files in my app, so I do not think it is
an option.

I doubt that the C++/CLI would ship with a bug of this size.
ON_BN_CLICKED is very common in MFC.

Either I am using some unusual combination of old header files that
are doing something non-standard or there is something about my
project configuration that leads to the compiler warning.

I guess the next step is to build a small MFC app that calls
ON_BN_CLICKED in a message map. If I can get that app in C++/CLI, I
will try and figure out the difference between the example and my
application. Otherwise, there is a C++/CLI bug.

Dan:

In your message map entries, is the member function properly written as
&ClassName::FunctionName ?

<speculation>
I have actually wondered about this. Recent versions of VC (certainly VC9)
generally refuse to pass member function arguments without the ampersand and
class name, but all legacy MFC code with message map entries has "naked" member
functions. Nevertheless it seems to compile, and I have wondered if this is some
kind of compiler extension specific to the message map entries. If so, maybe
this extension is disabled with /clr.
</speculation>

 

[dan]

Dan:

In your message map entries, is the member function properly written as
&ClassName::FunctionName ?

<speculation>
I have actually wondered about this. Recent versions of VC (certainly VC9)
generally refuse to pass member function arguments without the ampersand and
class name, but all legacy MFC code with message map entries has "naked" member
functions. Nevertheless it seems to compile, and I have wondered if this is some
kind of compiler extension specific to the message map entries. If so, maybe
this extension is disabled with /clr.
</speculation>

David,

All my functions were "naked". I changed them to include the
&className:FunctionName and I still get the same problem, so there
must be some magic in the compiler to deal with this problem.

I noticed that the compiler warning only occurs on the virtual
functions that I inherit from CDialog OnOK and OnCancel. Since I use
these buttons on almost every form, I need to figure out my thunking
problem. Is there some standard way for dealing with virtual functions
in C++/CLI to get them to play nicely with the .NET runtime.

Dan

 

[Mark Salsbery [MVP]]

You've got something else going on.

A new MFC project compiled entirely managed (/CLR turned on at project
settings) builds with no warnings.
That includes adding virtual overrides like OnOK, OnCancel, and
ON_BN_CLICKED message map entries.

You may want to try creating a project with the wizard then compare it's
header file #includes and project settings with yours and see what you're
doing differently.

Mark

 

[Mark Salsbery [MVP]]

Disabling /clr for each file with an ON_BN_CLICKED would remove a
significant percentage of the files in my app, so I do not think it is
an option.

Disabling /CLR doesn't remove a file from the project.

In fact, you can use #pragma managed/#pragma unmanaged to control
managed/unmanaged compilation down to a per-function level.

I doubt that the C++/CLI would ship with a bug of this size.
ON_BN_CLICKED is very common in MFC.

I agree.

There's no bug that I'm aware of (see my other reply). I've been using MFC
code compiled managed since VS 2003 .NET without compiler warnings.

Mark