Path: utzoo!utgpu!watserv1!mgardi
From: mgardi@watserv1.waterloo.edu (Mutual Life)
Newsgroups: comp.lang.c++
Subject: Re: virtual functions and CommonView
Message-ID: <955@watserv1.waterloo.edu>
Date: 3 Feb 90 04:32:22 GMT
References: <5436@vax1.tcd.ie>
Reply-To: mgardi@watserv1.waterloo.edu (Mutual Life)
Organization: U. of Waterloo, Ontario
Lines: 70

In article <5436@vax1.tcd.ie> ekelly@vax1.tcd.ie (EAMON EXT.1795, ROOM 12, 204 PEARSE ST.) writes:
>
>In CommonView there is a class 'Window'. This has two protected procedures
>(among others) 'virtual void _FAR Activate (Event);' and 'long _FAR Dispatch
>(Event)'
>
>
>My question is what is the difference between 'Activate', which is 'virtual'
>and 'Dispatch' which is not?
>
>I though the difference was that my 'Activate' would not need to call 'Window
>:: Activate' but that idea was squashed by Glockenspiel when I ask why my
>program would not work.
>

According to the C++ primer, p.342 (I am not sure if this is release 2.0
specific)
"The redefinition of a virtual function in a derived class must match exactly
the name, signature, and return type of the vase class instance. The keyword
virtual need not be specified....The class designer need only
specify the keyword virtual for the first definition of each instance"
 
Hmmm....I did not know this, and am not sure if I am reading this correctly,
but does this mean that DISPATCH is virtual anyway (it is derived from 
EventContext DISPATCH which is virtual, and has the exact same signature).
 
Anyway, about the second part.
You do NOT have to call Window::Activate to have your program work....IF you
handle EVERYTHING yourself. At least for most of the event handlers, such
as FocusChange, WindowInit, ButtonClk etc., you merely defined in these       
routines what it is that you want done when this event is created. If you
do NOT care, the leaving the definition out assumes DefWndProc processing of
that event. (ie. ignoring a WM_KEYDOWN by not creating a KeyDown routine
will be handled by the default windowing system. But if you want to only
allow Numeric input, your KeyDown event would query the character being
processed: If it was not numeric...DO NOTHING (windows default stuff will not
be done. If it is numeric, call Window::KeyDown to get back to the Windows
Default stuff....Note that you do not HAVE to do this if you are willing to
handle all the stuff necessary to get that character onto the Window)

I think this is the problem with your Activate event handler...It does not
necessarily have to call Window::Activate, but if you are not dealing with
the event completely, your program will not work.

This can get tricky when working with the Dispatcher in the same way...you
can create a numeric edit by intercepting the WM_ messages in the dispatcher,
and only letting the WM_ messages get sent to the Window::Dispatcher to create
events if the characters are numeric. But if you start intercepting events
such as WM_SYSKEYDOWN or whatever, and do not let them go on to the
default window dispatcher, I assume that you will have to take care of ALL
the subsequent messages that will not then be sent internally by windows....
ie. WM_SYSCOMMAND, WM_SIZE etc. etc. as well.
 
Hope this helps....Everyone...Feel free to pick this dissertation apart if
I am way off base: I am in the process of learning this stuff as well!
 
p.

Peter DeVries
Mutual Life of Canada
c/o mgardi@watdcsu
(519) 888-3523
(416) 972-0594

My opinions/comments are mine, and mine only, and have nothing
to do with what Mutual Life of Canada thinks (now isn't that
an understatement!)
p.