Prev: counterpart for MAKEINTRESOURCE
Next: Error while declaring CArray within struct
From: rahul on 25 Nov 2009 03:52
In MFC Generally when we Override Message Handling function by a class
then we call base class function at the end like,
return CPropertySheet::PreTranslateMessage(pMsg);

how this is valid??
If PreTranslateMessage() is not static function then how can we call
it by this way (i.e. ClassName::FunctionName)??

From: Giovanni Dicanio on 25 Nov 2009 04:13
"rahul" <hyrahul64(a)gmail.com> ha scritto nel messaggio
news:0d4c5040-184f-40ea-aad2-9b442e14a4fa(a)k13g2000prh.googlegroups.com...

> In MFC Generally when we Override Message Handling function by a class
> then we call base class function at the end like,
> return CPropertySheet::PreTranslateMessage(pMsg);
>
> how this is valid??
> If PreTranslateMessage() is not static function then how can we call
> it by this way (i.e. ClassName::FunctionName)??

If C++ class 'Derived' derives from 'Base', it is ordinary C++ syntax to
call Base::DoSomething() from Derived::DoSomething(). There is no constraint
for DoSomething method to be static.
(The compiler can happily pass the 'this' pointer as hidden parameter as
usual.)

Giovanni


From: Goran on 25 Nov 2009 07:04
On Nov 25, 9:52 am, rahul <hyrahu...(a)gmail.com> wrote:
> In MFC Generally when we Override Message Handling function by a class
> then we call base class function at the end like,
> return CPropertySheet::PreTranslateMessage(pMsg);
>
> how this is valid??
> If PreTranslateMessage() is not static function then how can we call
> it by this way (i.e. ClassName::FunctionName)??

(Not at all MFC question, BTW. Try http://groups.google.com/group/comp.lang..c++.moderated/topics
for more involved crowd).

I would guess the most important reason that this is allowed really is
inheritance.

That said, why you think it's important that language prevents you
from using fully-qualified function name? It's the same call, just
longer to type (but, important with inheritance).

Note that you can also do:

class Type
{
public:
static void StaticFunc() {}
void Func() {}
};

Type var;
var.StaticFunc(); // !!! works not with class name, but class instance
var.Type::Func(); // !!! works, too

Goran.
From: Joseph M. Newcomer on 25 Nov 2009 12:19
Actually, it would be erroneous if it *was* a static function. This would mean that it
had no access to the instance-specific information, which includes the m_hWnd member which
is the window that is wrapped.

CWnd::PreTranslateMessage is a *virtual* method. RTFM. Note that if you have class A,
from which you derive class B, from which you derive class C, and in C:something you call
the superclass A:something, this is *probably* wrong; you should have called B:something.

You can avoid this error by using the Microsoft extension __super, e.g., calling
__super::something, so if you later introduce class B between A and C (C was formerly
derived from A), and forget to change the calls in C to call its correct superclass, this
saves you. But it can also do you in; see the documentation for __super for an
interesting case.

Message maps are a cheat that let you get virtual methods without massive vtables.
Unfortunately, they aren't quite right, and don't quite simulate virtual methods. In
particular, if you call the base class from a derived message map, it does not use the
arguments you pass (which would have made sense in an OO system) but instead uses the
parameters from the original message (which is actually incorrect behavior; it is just
what MFC does, due to terminal brain damage in the original design to make it "efficient";
that is, Unixitis infected them. In Unix, the philosophy was "we don't care if it is
correct, as long as it is small and fast")

joe

On Wed, 25 Nov 2009 00:52:22 -0800 (PST), rahul <hyrahul64(a)gmail.com> wrote:

>In MFC Generally when we Override Message Handling function by a class
>then we call base class function at the end like,
>return CPropertySheet::PreTranslateMessage(pMsg);
>
>how this is valid??
>If PreTranslateMessage() is not static function then how can we call
>it by this way (i.e. ClassName::FunctionName)??
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 25 Nov 2009 12:33
Actually, this is not overriding *message* handling, because this method is not actually
triggered by a particular message. It overrides message handling in a very restricted
way, because after you return from PreTranslateMessage with a FALSE value, it actually
handles the message in the current class, and if you return from PreTranslateMessage with
non-FALSE, it doesn't handle the message in *any* class.

Note also that PreTranslateMessage is often abused and used inappropriately, for example,
to simulate Petzold-style handlers, or because the programmer really doesn't understand
the message map. Nearly *all* uses I've seen of PreTranslateMessage are incorrect; it is
used in very rare contexts, such as handling F1 help. There are many correct ways to use
it, but you'd have to explain why you are using it before I'd believe it is being used
correctly.
joe
On Wed, 25 Nov 2009 00:52:22 -0800 (PST), rahul <hyrahul64(a)gmail.com> wrote:

>In MFC Generally when we Override Message Handling function by a class
>then we call base class function at the end like,
>return CPropertySheet::PreTranslateMessage(pMsg);
>
>how this is valid??
>If PreTranslateMessage() is not static function then how can we call
>it by this way (i.e. ClassName::FunctionName)??
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 | 
Pages: 1
Prev: counterpart for MAKEINTRESOURCE
Next: Error while declaring CArray within struct