|
Insert new 'String Table' resource. Add your strings to it. Use LoadString function to get the strings.
|
|
|
|
|
Hi Selva,
SelvaKr wrote: Tool tips are specified in the resource as direct strings in the prompt field of
the properties.
The VC resource editor intends to help you to create toolbar tooltips, they are actually in the resource stringtable.
For instance in your .rc file you have:
STRINGTABLE
BEGIN
ID_FILE_NEW "Create a new document\nNew"A toolbar button's tooltip is the part of the string resource with same ID following '\n'.
As the part preceding '\n' is the status bar text when a menu entry with same ID is hovered you can localize the strings matching your menus and toolbars in one step.
cheers,
AR
When the wise (person) points at the moon the fool looks at the finger (Chinese proverb)
|
|
|
|
|
So in porting my VS6 MFC app to VS2010 I'm plagued with hundreds of C4407 warnings. And Google is giving me no joy on how to fix it.
(...cast between different pointer to member representations, compiler may generate incorrect code...
...Compiling with the /vmm might help...)
So the question is, can I ignore the warning? How likely is this "incorrect code" and what might be the result? (I end up in the wrong base class?)
|
|
|
|
|
Kyudos wrote: So the question is, can I ignore the warning?
Well, possibly, but it depends on what you are doing. The warning comes from the use of a cast that may lead to the compiler making a wrong assumption about what you are trying to do. It would be better if you asked yourself why you have so many cast operators and what are they there for? Perhaps if you posted some of the code where the error occurs it may help someone to offer a better suggestion.
The best things in life are not things.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
