|
I get the warning from just about every message map function in every dialog - I'm not explicitly casting anything - it's a multiple inheritance thing. I've seen suggestions that the order of the declaration of the base classes is important, but that isn't my issue. The majority of my derived classes have a single base class so there is no order to change. This makes me lean toward the declaration of the (ultimate) virtual base class - I've seen other suggestions that "un-virtualising" it might also solve the problem. I was trying to figure out the best approach before I start changing code all over the shop.
(Whoever originated the code (not me) took the approach of using a base class for most of the classes in the application. The dialogs, for instance, are all derived from the dialog base class which itself is derived from CDialog. All the dialogs are specialisations of this. The class structure is a bit of a nightmare to be honest, but that's what I'm dealing with)
|
|
|
|
|
Why don't you pick out the first occurance of the warning, and post the applicable code along with the exact message in the warning. I can probably tell you why you get the warning and how to fix it. VS6 used to let you get away with a lot that the newer, stricter implementations of the vc compiler will either warn you about, or not let you do it at all.
One such case is taking data from one format to another without explicit casting:
float pi = 3.1415;
int i_pi = pi;
int i_pi = (int) pi;
|
|
|
|
|
OK...thanks Albert.
On this line:
ON_BN_CLICKED(IDC_RADIO_SUITABLE, OnCheckShowAll)
I get:
warning C4407: cast between different pointer to member representations, compiler may generate incorrect code
that is in the message map of the ValveSummaryDlg class.
the class hierarchy at that point is:
WndBase
Dialog : virtual public WndBase
DialogBase : public Dialog, public CDialog
GridBase : virtual public WndBase
GridDlg : public DialogBase, public GridBase
ValveSummaryDlg : public GridDlg
|
|
|
|
|
Looks like what the compiler's trying to tell you is that the pointer to the function is ambiguous...
Try this (assuming that's the location of the method), not sure if it'll fix it, but it should be more specific:
ON_BN_CLICKED(IDC_RADIO_SUITABLE, &ValveSummaryDlg::OnCheckShowAll)
...Oh, and this is definitely due to the multiple inheritance...
Another thing to try...
DialogBase : public CDialog, public Dialog
modified on Monday, June 20, 2011 11:20 PM
|
|
|
|
|
It was a good idea Albert - but it doesn't work 
|
|
|
|
|
Why are you deriving from both Dialog and CDialog?
|
|
|
|
|
Long answer...
The application is a CAD program, so many of the dialogs have common elements (line style selection, line width selection, layer etc.). The "Dialog" class contains functions that deal with these common elements.
Short answer...
Because that's how it was done when I inherited the code and I haven't changed it 
|
|
|
|
|
Well, the root of your problem is the multiple inheritance coupled with the ON_BN_CLICKED() macro definition static cast:
#define ON_BN_CLICKED(id, memberFxn) \
ON_CONTROL(BN_CLICKED, id, memberFxn)
#define ON_CONTROL(wNotifyCode, id, memberFxn) \
{ WM_COMMAND, (WORD)wNotifyCode, (WORD)id, (WORD)id, AfxSigCmd_v, \
(static_cast< AFX_PMSG > (memberFxn)) },
Here's an article on those pointers:
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=142[^]
|
|
|
|
|
I've had enough of trying to fix it - /vmg /vmv FTW!
Thanks anyway!
|
|
|
|
|
Good luck!
|
|
|
|
|
If you can't resolve the problem trying a few different things... you may have to condense some of your inheritances. A lot of them have little rhyme or reason. For example, why create a Dialog class when you can derive place all that code on a CDialog derived class, then you only have one class to inherit from.
class CMyBaseDialog : public CDialog
class GridBase
class GridDlg : public CMyBaseDialog, public GridBase
Now this SHOULD work correctly... emphasis on the should... 
|
|
|
|
|
You are right the class structure is a mess...but I'm reticent to mess with it at the moment. I'll try and get something working from VS2010 first, then change it if I have to.
|
|
|
|
|
Well good luck, if you want more help, maybe set up a small project that just outlines what you're trying to do (just the skeletons of the classes, enough that we can see and compile the project, maybe squeeze it all into one or two files) and put it up somewhere. Its an interesting problem so I wouldn't mind helping.
Cheers! 
|
|
|
|
|
Pretty bad.
- Nevin Janzen
|
|
|
|
|
|
Any error is horrible, in my opinion.
- Nevin Janzen
|
|
|
|
|
Well that's a warning, not an error... its a level 1 warning though... so its considered severe.
|
|
|
|
|
There is still a chance of something going wrong.
- Nevin Janzen
|
|
|
|
|
Right. The only acceptable development method is keeping zero number of warning in the whole product. At least at the moment when the modified code is committed to revision control all warnings should be eliminated. If warnings are accumulated, it means the useful mechanism of warning is effectively off.
—SASergey A Kryukov
|
|
|
|
|
From MSDN page for WM_ACTIVATETOPLEVEL
http://msdn.microsoft.com/en-us/library/xkd95027(VS.80).aspx[^]
I got the below description:
This message is similar in use to WM_ACTIVATEAPP, but works in situations where windows belonging to different processes are mixed in a single window hierarchy (common in OLE applications).
Does anybody know where is a example/demo available that illustrate "windows belonging to different processes are mixed in a single window hierarchy"?
I googled but found almost nothing.
Thanks!
|
|
|
|
|
I would assume that this will happen when (say) Word runs its windows inside your application to deal with an embedded object?
So would apply to the windows / processes associated with any OLE object.
|
|
|
|
|
Hi All!
I am developing an OLE Object for MS-WORD. Now I meet a problem. And I hope someone can help me.
The Object I developing can be added into a .doc file. After added, it will draw a shape such as rectangle or circle etc. as the proof of existence. Now I find that when the .doc file which had been added the Object is to be loaded, the shape will be drawn twice. And the position of these shapes are different. I don't know why this occurred.
During the time I try to fix it, I noticed that the call of "CComControlBase::InPlaceActivate" is very important. Only after I call it, the loaded object can work. I think this means that one of the two shapes I see is owned by "InPlaceActivate". The other is owned of "UIActivate". But I can't find anyway to make this object is "InPlaceActivated" or "UIActivated" only.
Is there anyone could be kind to tell me the correct way to fix this problem? Thank you!
Best regards!
There is some white cloud floating on the blue sky. That's the landscape I like.
|
|
|
|
|
Hello,
We are having COM component created for 32 bit OS. May I know what precautions or steps I need to take while porting it on 64 bit OS. If possible please suggest Any book or good link.
Regards,
Happy Programming.
|
|
|
|
|
Hey guys,
I have been writing Windows apps with WTL for years but now for several years it hasn't been updated and the new Windows versions are coming out with more controls and messages and none of them are supported by WTL. What now?
Sincerely,
Peteris Krumins
Peteris Krumins
http://www.catonmat.net
Loves mathematics, physics and computer science!
|
|
|
|
|