|
The assignment operator used is chosen based on the
type of the variable being assigned to. To use the base
assignment operator without a cast would require an overload
that returns a derived.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Is it in the specification of C++? If not, what I can see is the derived class inherits all of the information of the function in the bass class, including the return value.
thanks,
Bob
|
|
|
|
|
It wouldn't work for any class, whether virtual or not.
There's not an implicit assignment operator for a type that takes a
base type as its right-hand operand. You must explicitly provide the
assignment operator or cast the left operand to a type that matches
an existing assignment operator overload.
Using a cast may hide the compiler error but if the operator overload that
the compiler chooses to call doesn't actually return a derived&, then you can't
rely on it being a derived object.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Also..
It is stated here[^] that assignment operators are not inherited.
Take a close look at this[^] example as well.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thank you so much. Now I am clear.
Bob
|
|
|
|
|
AFAIK, In C++, operator = is not inherited.
|
|
|
|
|
I'm trying to hook in a master "omg, we're going down, eject, eject, eject!" code chunk into my mfc dialog application. Basically, I do not want the user to see "chg.exe has done something bad and will need to terminate." What I want is to be able to capture as much forensic data to allow me to have a hope to diagnose what caused the crash.
So, in doing my research, I have seen two main approaches - override the run method of the CWinApp:
<br />
<br />
int CMyApp::Run() <br />
{<br />
BOOL bRun;<br />
BOOL bExit=FALSE;<br />
<br />
while(!bExit)<br />
{<br />
try<br />
{<br />
bRun= CWinApp::Run();<br />
bExit=TRUE;<br />
}<br />
catch (...)<br />
{<br />
AfxMessageBox(_T("Exeption!!!"));
}<br />
}<br />
return bRun;<br />
}<br />
I've also added the ProcessWndProcException handler at the app level as well.
What I have seen so far is that basically the code is ignored. If I hack up a little dialog app and divide by 0 or try to modify NULL, I see nothing at run time until I try to exit my app. What should one expect from these approaches?
Charlie Gilley
Will program for food...
<italic>Hurtling toward a government of the stupid, by the stupid, for the stupid we go. —Michelle Malkin
|
|
|
|
|
|
I'll take a look this evening.... thanks
Charlie Gilley
Will program for food...
<italic>Hurtling toward a government of the stupid, by the stupid, for the stupid we go. —Michelle Malkin
|
|
|
|
|
|
Hi,
Is there a way to catch Exceptions in my SDI MFC application in a very low level?
What I mean: I work with an SQL database and it may be that I have an error in the SQL syntax etc. In this case a specific exceptions is thrown.
I do not want to catch it somewhere in my code for View/Document but rather somewhere in the application object and then just display an error message and terminating my application the right way (including calling of all destructors).
When I do not catch them, I get a "Runtime error" in the debug version. I would like to have this similar behaviour.
Regards,
Niki
|
|
|
|
|
You can add a global exception handler using the SetUnhandledExceptionFilter Function[^] and catch all SQL related errors and return EXCEPTION_EXECUTE_HANDLER for all other exceptions or maybe handle them as well.
Best Wishes,
-David Delaune
|
|
|
|
|
|
i can easily send mails with ASP VB etc..
but i could not send mail with "CDO.Message" in C++
i have tried lots of sample code around the web
but none of them worked well,
i am always getting lots of compiler error
please , could you show me a working sample that uses "CDO.Message"
Here is a sample[^] from MSDN
envirounment Visual Studio .NET 2003
note :
i do not want to use a pre-written SMTP class (FireWall problems etc..)
thanks.
|
|
|
|
|
Is there a way to tell Visual Studio 2008 to not run the Manifest Tool at all during a build?
I have created my own custom manifest resource which I embed into the EXE by myself.
Even though it's possible to tell the manifest tool not to embed the manifest, I can't stop it from creating a separate manifest file called "AppName.exe.manifest"
It's a pain to have to delete this extra manifest file every time I build the project.
Does anyone know how to stop the Manifest Tool from running?
|
|
|
|
|
What if you go to the project/Linker/Generate Manifest File setting and set it to no?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I forgot to check in the Linker properties! I was only looking in the Manifest Tool properties.
I'll give that a try, thanks Mark!
|
|
|
|
|
Hi,
I am trying to serialize all objects stored in a CArray but if a trace it through, it is calling the default SerializeElements which understandably does not serialize the objects correctly. I want this to call mt object's Serialize method.
I have tried adding my own helper but the compiler says that it already exists. This may be because I have used DECLARE_SERIAL and IMPLEMENT_SERIAL macros. MSDN says that if you use these macros, the helper function will be implemented, but if that is so, why isnt it being called?
Does anyone have any ideas what I can try ?
TIA
Tony
|
|
|
|
|
Its OK, I figured it out. It was nothing to do with the DECLARE_SERIAL and IMPLEMENT_SERIAL macros
DUH!
|
|
|
|
|
Good to know.
IMHO object serialization is one of most appealing features of MFC .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: IMHO object serialization is one of most appealing features of MFC.
I've never used it after initial learning. I'm too much of a file format control freak...
Iain.
|
|
|
|
|
I like to have control on file format too. Anyway, automatic object (re-)creation is too appealing to me.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hello,
I have some code which has a dialog box and a list control placed on it, and I handled the WM_LBUTTONDOWN message on it, which perfectly executed when the code was compiled in Visual C++ 6.0. But the same code, when ported to VS 2005, does not respond to this message at all, although the code compiles and links fine in VS 2005. I tried to handle the notification message, NM_CLICK also, on the List Control which is on the dialog box, but to no avail. What must be the problem?
Please suggest the remedy.
Thanks,
Software Developer
Sanjay Khapre
|
|
|
|
|
From whatever you've said looks like it should work and can't guess anything else, we need more information on how you are calling/showing this dialog.
|
|
|
|
|
Where are you handling (or trying to handle) these messages....in the dialog class or
a CListCtrl-derived class?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|