Changed behavior of overriden OnCmdMsg(...) after migration to Visual Studio 2005

Hello,
please assist in solving critical problem which I faced after
migration of my project to Visual Studio 2005 from Visual Studio 6.0.
My project is a document-view based application, view class is
inherited from CFormView, it is a dialogue with multiple edit fields.
For example, field m_Edit1 has OnKillFocus(...) handler defined which
validates user entered data. The next field m_Edit2 doesn't have this
handler. At the same time I have overriden method OnCmdMsg(..) in my
view class. This method performs some checking for content of m_Edit1
when EN_KILLFOCUS is sent and calls OnCmdMsg(..) of the parent class.
For some years both methods - OnKillFocus(..) and OnCmdMsg(...) for
m_Edit1 and message EN_KILLFOCUS worked ok when user filled m_Edit1
and  moved focus to the next field. No changes to this functionality
were done. The only change was recompilation with Visual Studio 2005.
Now OnKillFocus(..) works ok for m_Edit1.  But strange problem is that
OnCmdMsg(...) doesn't process EN_KILLFOCUS for m_Edit1 anymore. In
debugger I saw that when user leaves the field m_Edit1 OnCmdMsg(..) is
called for m_Edit2 in this case. It is unclear why field ID was
incremented in OnCmdMsg(...) call. It seems to be internal work of
MFC, not my code. Do you have any suggestions what may be the reason
of this problem,or, at least, what should I check?

P.S. I tried to create some simple test example, but it works ok. The
problem happens in my thick client with rich functionality of the edit
controls.

Thanks,
Alexander.
0
stoya (2)
2/11/2008 7:35:04 PM
vc.mfc 33608 articles. 0 followers. Follow

7 Replies
433 Views

Similar Articles

[PageSpeed] 19

I'm always curious why OnCmdMsg would be used.  This always struck me as delicate and a
bit dangerous.  So if the behavior changes in a different version of VS, I would not at
all be surprised to see strange behavior with this approach.  Why can't this be handled by
an EN_KILLFOCUS handler in m_Edit2 (and why are you using such highly-mnemonic names, when
human-readable names would make more sense?)

Show the code, but the approach sounds dangerous.
					joe
On Mon, 11 Feb 2008 11:35:04 -0800 (PST), Alexander Stoyakin <stoya@ua.fm> wrote:

>Hello,
>please assist in solving critical problem which I faced after
>migration of my project to Visual Studio 2005 from Visual Studio 6.0.
>My project is a document-view based application, view class is
>inherited from CFormView, it is a dialogue with multiple edit fields.
>For example, field m_Edit1 has OnKillFocus(...) handler defined which
>validates user entered data. The next field m_Edit2 doesn't have this
>handler. At the same time I have overriden method OnCmdMsg(..) in my
>view class. This method performs some checking for content of m_Edit1
>when EN_KILLFOCUS is sent and calls OnCmdMsg(..) of the parent class.
>For some years both methods - OnKillFocus(..) and OnCmdMsg(...) for
>m_Edit1 and message EN_KILLFOCUS worked ok when user filled m_Edit1
>and  moved focus to the next field. No changes to this functionality
>were done. The only change was recompilation with Visual Studio 2005.
>Now OnKillFocus(..) works ok for m_Edit1.  But strange problem is that
>OnCmdMsg(...) doesn't process EN_KILLFOCUS for m_Edit1 anymore. In
>debugger I saw that when user leaves the field m_Edit1 OnCmdMsg(..) is
>called for m_Edit2 in this case. It is unclear why field ID was
>incremented in OnCmdMsg(...) call. It seems to be internal work of
>MFC, not my code. Do you have any suggestions what may be the reason
>of this problem,or, at least, what should I check?
>
>P.S. I tried to create some simple test example, but it works ok. The
>problem happens in my thick client with rich functionality of the edit
>controls.
>
>Thanks,
>Alexander.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15975)
2/11/2008 9:19:52 PM
We used OnCmdMsg extensively to route it to custom CCmdTargets. It works 
well. However in this case, I have no idea why would you use OnCmdMsg in 
this case but I dont really know what OP is doing.

Using OnCmdMsg is actually very helpful. It lets you customize MFC command 
routing.

---
Ajay

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:aoe1r39ulla5hnv2qreni5hh3c7ddv9k7p@4ax.com...
> I'm always curious why OnCmdMsg would be used.  This always struck me as 
> delicate and a
> bit dangerous.  So if the behavior changes in a different version of VS, I 
> would not at
> all be surprised to see strange behavior with this approach.  Why can't 
> this be handled by
> an EN_KILLFOCUS handler in m_Edit2 (and why are you using such 
> highly-mnemonic names, when
> human-readable names would make more sense?)
>
> Show the code, but the approach sounds dangerous.
> joe
> On Mon, 11 Feb 2008 11:35:04 -0800 (PST), Alexander Stoyakin <stoya@ua.fm> 
> wrote:
>
>>Hello,
>>please assist in solving critical problem which I faced after
>>migration of my project to Visual Studio 2005 from Visual Studio 6.0.
>>My project is a document-view based application, view class is
>>inherited from CFormView, it is a dialogue with multiple edit fields.
>>For example, field m_Edit1 has OnKillFocus(...) handler defined which
>>validates user entered data. The next field m_Edit2 doesn't have this
>>handler. At the same time I have overriden method OnCmdMsg(..) in my
>>view class. This method performs some checking for content of m_Edit1
>>when EN_KILLFOCUS is sent and calls OnCmdMsg(..) of the parent class.
>>For some years both methods - OnKillFocus(..) and OnCmdMsg(...) for
>>m_Edit1 and message EN_KILLFOCUS worked ok when user filled m_Edit1
>>and  moved focus to the next field. No changes to this functionality
>>were done. The only change was recompilation with Visual Studio 2005.
>>Now OnKillFocus(..) works ok for m_Edit1.  But strange problem is that
>>OnCmdMsg(...) doesn't process EN_KILLFOCUS for m_Edit1 anymore. In
>>debugger I saw that when user leaves the field m_Edit1 OnCmdMsg(..) is
>>called for m_Edit2 in this case. It is unclear why field ID was
>>incremented in OnCmdMsg(...) call. It seems to be internal work of
>>MFC, not my code. Do you have any suggestions what may be the reason
>>of this problem,or, at least, what should I check?
>>
>>P.S. I tried to create some simple test example, but it works ok. The
>>problem happens in my thick client with rich functionality of the edit
>>controls.
>>
>>Thanks,
>>Alexander.
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm 

0
ajaykalra (6842)
2/12/2008 1:34:06 AM
Yes, that is a valid use for it; the problem is that too many people try to program like
Petzold's book describes for Microsoft Windows 1.0 (or whatever version he wrote the first
version of his book for), and they are looking for a "window procedure" style of handling,
and mistake OnCmdMsg for this.  I've never seen anyone who asks this kind of question with
enough understanding of MFC to know about custom command target routing, it is just one of
those overused and abused functions, like PreTranslateMessage (which has an important
purpose, but ends up being used for Petzold-style Windows 1.0 message handling instead).
The people who understand OnCmdMsg don't need to ask questions about handling EN_KILLFOCUS
in it, because they wouldn't use it for that purpose.

OnCmdMsg should never be used in the context that it is used here.  

I came to detest EN_KILLFOCUS validation years ago; I'm sure there are conditions under
which it should be used, but most people seem to think that validation should be done on
focus departure, and my users seem to like the style I give them, of dynamic real-time
validation (which wouldn't work if it had to do a query on a database on each keystroke).
In the few cases where I used EN_KILLFOCUS, all I do is PostMessage a validation request
to the thread and get out, and do nothing else (KillFocus handlers are delicate).  And I
NEVER pop up a dialog box if there is a validation failure (intrusive, obnoxious, and a
constant annoyance to users).  I find the simple paradigms don't take human beings into
consideration; they are designed by programmers for the convenience of programmers, and
their purpose is not to make life easy for the end user, but easy for the programmer.
					joe
On Mon, 11 Feb 2008 20:34:06 -0500, "Ajay Kalra" <ajaykalra@yahoo.com> wrote:

>We used OnCmdMsg extensively to route it to custom CCmdTargets. It works 
>well. However in this case, I have no idea why would you use OnCmdMsg in 
>this case but I dont really know what OP is doing.
>
>Using OnCmdMsg is actually very helpful. It lets you customize MFC command 
>routing.
>
>---
>Ajay
>
>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
>news:aoe1r39ulla5hnv2qreni5hh3c7ddv9k7p@4ax.com...
>> I'm always curious why OnCmdMsg would be used.  This always struck me as 
>> delicate and a
>> bit dangerous.  So if the behavior changes in a different version of VS, I 
>> would not at
>> all be surprised to see strange behavior with this approach.  Why can't 
>> this be handled by
>> an EN_KILLFOCUS handler in m_Edit2 (and why are you using such 
>> highly-mnemonic names, when
>> human-readable names would make more sense?)
>>
>> Show the code, but the approach sounds dangerous.
>> joe
>> On Mon, 11 Feb 2008 11:35:04 -0800 (PST), Alexander Stoyakin <stoya@ua.fm> 
>> wrote:
>>
>>>Hello,
>>>please assist in solving critical problem which I faced after
>>>migration of my project to Visual Studio 2005 from Visual Studio 6.0.
>>>My project is a document-view based application, view class is
>>>inherited from CFormView, it is a dialogue with multiple edit fields.
>>>For example, field m_Edit1 has OnKillFocus(...) handler defined which
>>>validates user entered data. The next field m_Edit2 doesn't have this
>>>handler. At the same time I have overriden method OnCmdMsg(..) in my
>>>view class. This method performs some checking for content of m_Edit1
>>>when EN_KILLFOCUS is sent and calls OnCmdMsg(..) of the parent class.
>>>For some years both methods - OnKillFocus(..) and OnCmdMsg(...) for
>>>m_Edit1 and message EN_KILLFOCUS worked ok when user filled m_Edit1
>>>and  moved focus to the next field. No changes to this functionality
>>>were done. The only change was recompilation with Visual Studio 2005.
>>>Now OnKillFocus(..) works ok for m_Edit1.  But strange problem is that
>>>OnCmdMsg(...) doesn't process EN_KILLFOCUS for m_Edit1 anymore. In
>>>debugger I saw that when user leaves the field m_Edit1 OnCmdMsg(..) is
>>>called for m_Edit2 in this case. It is unclear why field ID was
>>>incremented in OnCmdMsg(...) call. It seems to be internal work of
>>>MFC, not my code. Do you have any suggestions what may be the reason
>>>of this problem,or, at least, what should I check?
>>>
>>>P.S. I tried to create some simple test example, but it works ok. The
>>>problem happens in my thick client with rich functionality of the edit
>>>controls.
>>>
>>>Thanks,
>>>Alexander.
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm 
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15975)
2/12/2008 4:02:58 AM
OnCmdMsg(.) and OnNotify(..) are overriden to call common validation
methods. There are many different controls which are not derived from
common class. So validation algorithm is not implemented statically
for each control in OnKillFocus(..). Common validator class is created
and it can be assigned dynamically when we need it. Actually
OnCmdMsg(..) is not used for catching EN_KILLFOCUS only, this is just
a place where I got a problem. Reaction to all possible messages
implemented there.

On 12 =C6=C5=D7, 07:02, Joseph M. Newcomer <newco...@flounder.com> wrote:
> Yes, that is a valid use for it; the problem is that too many people try t=
o program like
> Petzold's book describes for Microsoft Windows 1.0 (or whatever version he=
 wrote the first
> version of his book for), and they are looking for a "window procedure" st=
yle of handling,
> and mistake OnCmdMsg for this.  I've never seen anyone who asks this kind =
of question with
> enough understanding of MFC to know about custom command target routing, i=
t is just one of
> those overused and abused functions, like PreTranslateMessage (which has a=
n important
> purpose, but ends up being used for Petzold-style Windows 1.0 message hand=
ling instead).
> The people who understand OnCmdMsg don't need to ask questions about handl=
ing EN_KILLFOCUS
> in it, because they wouldn't use it for that purpose.
>
> OnCmdMsg should never be used in the context that it is used here.
>
> I came to detest EN_KILLFOCUS validation years ago; I'm sure there are con=
ditions under
> which it should be used, but most people seem to think that validation sho=
uld be done on
> focus departure, and my users seem to like the style I give them, of dynam=
ic real-time
> validation (which wouldn't work if it had to do a query on a database on e=
ach keystroke).
> In the few cases where I used EN_KILLFOCUS, all I do is PostMessage a vali=
dation request
> to the thread and get out, and do nothing else (KillFocus handlers are del=
icate).  And I
> NEVER pop up a dialog box if there is a validation failure (intrusive, obn=
oxious, and a
> constant annoyance to users).  I find the simple paradigms don't take huma=
n beings into
> consideration; they are designed by programmers for the convenience of pro=
grammers, and
> their purpose is not to make life easy for the end user, but easy for the =
programmer.
>                                         joe
>
>
>
> On Mon, 11 Feb 2008 20:34:06 -0500, "Ajay Kalra" <ajayka...@yahoo.com> wro=
te:
> >We used OnCmdMsg extensively to route it to custom CCmdTargets. It works
> >well. However in this case, I have no idea why would you use OnCmdMsg in
> >this case but I dont really know what OP is doing.
>
> >Using OnCmdMsg is actually very helpful. It lets you customize MFC comman=
d
> >routing.
>
> >---
> >Ajay
>
> >"Joseph M. Newcomer" <newco...@flounder.com> wrote in message
> >news:aoe1r39ulla5hnv2qreni5hh3c7ddv9k7p@4ax.com...
> >> I'm always curious why OnCmdMsg would be used.  This always struck me a=
s
> >> delicate and a
> >> bit dangerous.  So if the behavior changes in a different version of VS=
, I
> >> would not at
> >> all be surprised to see strange behavior with this approach.  Why can't=

> >> this be handled by
> >> an EN_KILLFOCUS handler in m_Edit2 (and why are you using such
> >> highly-mnemonic names, when
> >> human-readable names would make more sense?)
>
> >> Show the code, but the approach sounds dangerous.
> >> joe
> >> On Mon, 11 Feb 2008 11:35:04 -0800 (PST), Alexander Stoyakin <st...@ua.=
fm>
> >> wrote:
>
> >>>Hello,
> >>>please assist in solving critical problem which I faced after
> >>>migration of my project to Visual Studio 2005 from Visual Studio 6.0.
> >>>My project is a document-view based application, view class is
> >>>inherited from CFormView, it is a dialogue with multiple edit fields.
> >>>For example, field m_Edit1 has OnKillFocus(...) handler defined which
> >>>validates user entered data. The next field m_Edit2 doesn't have this
> >>>handler. At the same time I have overriden method OnCmdMsg(..) in my
> >>>view class. This method performs some checking for content of m_Edit1
> >>>when EN_KILLFOCUS is sent and calls OnCmdMsg(..) of the parent class.
> >>>For some years both methods - OnKillFocus(..) and OnCmdMsg(...) for
> >>>m_Edit1 and message EN_KILLFOCUS worked ok when user filled m_Edit1
> >>>and  moved focus to the next field. No changes to this functionality
> >>>were done. The only change was recompilation with Visual Studio 2005.
> >>>Now OnKillFocus(..) works ok for m_Edit1.  But strange problem is that
> >>>OnCmdMsg(...) doesn't process EN_KILLFOCUS for m_Edit1 anymore. In
> >>>debugger I saw that when user leaves the field m_Edit1 OnCmdMsg(..) is
> >>>called for m_Edit2 in this case. It is unclear why field ID was
> >>>incremented in OnCmdMsg(...) call. It seems to be internal work of
> >>>MFC, not my code. Do you have any suggestions what may be the reason
> >>>of this problem,or, at least, what should I check?
>
> >>>P.S. I tried to create some simple test example, but it works ok. The
> >>>problem happens in my thick client with rich functionality of the edit
> >>>controls.
>
> >>>Thanks,
> >>>Alexander.
> >> Joseph M. Newcomer [MVP]
> >> email: newco...@flounder.com
> >> Web:http://www.flounder.com
> >> MVP Tips:http://www.flounder.com/mvp_tips.htm
>
> Joseph M. Newcomer [MVP]
> email: newco...@flounder.com
> Web:http://www.flounder.com
> MVP Tips:http://www.flounder.com/mvp_tips.htm

0
stoya (2)
2/12/2008 6:11:11 AM
I still find it to be handy when I have more than one view and want each of 
them to get the command targets so the one that handles it can get the 
messages even if not focused.  It still seems to be working as advertised.

Tom

"Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
news:6415AC7F-B838-4190-98A4-FC5DB8EC57C3@microsoft.com...
> We used OnCmdMsg extensively to route it to custom CCmdTargets. It works 
> well. However in this case, I have no idea why would you use OnCmdMsg in 
> this case but I dont really know what OP is doing.
>
> Using OnCmdMsg is actually very helpful. It lets you customize MFC command 
> routing.

0
tom.nospam (3240)
2/12/2008 6:40:50 AM
OK, that's sounding a bit saner.  But have you checked out with Spy++ to see what is
happening?  Then put a couple breakpoints in the AfxWndProc to see what is happening when
a particular killfocus notification occurs.  

KillFocus handlers are dangerous; at one point, little things like trying to pop up a
message box in a kill focus handler would crash Windows; then after a while, it would
merely lock up Windows; and I think the current state is that it locks up only the
application.  The problem with doing anything but a PostMessage in a killfocus handler is
that if you end up calling something that calls something that calls something that does
something forbidden in a killfocus handler, you end up in serious trouble.  In that case,
PreTranslateMessage is probably a better place to handle this if you are trying to respond
to loss of focus.  Then you could just PostMessage a validation request with the pointer
to the validation class.

Most control validation I deal with deals with interacting control values, which require
global knowledge of the state of the dialog; in essence, a set of constraint equations on
the enable/disable/hide/show state of each control, relative to the other controls (and in
a CFormView, relative to values in the document as well).  That's what
ON_UPDATE_COMMAND_UI is supposed to support, but for controls in CDialog/CFormView, that
isn't suppored.  
					joe

On Mon, 11 Feb 2008 22:11:11 -0800 (PST), Alexander Stoyakin <stoya@ua.fm> wrote:

>OnCmdMsg(.) and OnNotify(..) are overriden to call common validation
>methods. There are many different controls which are not derived from
>common class. So validation algorithm is not implemented statically
>for each control in OnKillFocus(..). Common validator class is created
>and it can be assigned dynamically when we need it. Actually
>OnCmdMsg(..) is not used for catching EN_KILLFOCUS only, this is just
>a place where I got a problem. Reaction to all possible messages
>implemented there.
>
>On 12 ???, 07:02, Joseph M. Newcomer <newco...@flounder.com> wrote:
>> Yes, that is a valid use for it; the problem is that too many people try to program like
>> Petzold's book describes for Microsoft Windows 1.0 (or whatever version he wrote the first
>> version of his book for), and they are looking for a "window procedure" style of handling,
>> and mistake OnCmdMsg for this.  I've never seen anyone who asks this kind of question with
>> enough understanding of MFC to know about custom command target routing, it is just one of
>> those overused and abused functions, like PreTranslateMessage (which has an important
>> purpose, but ends up being used for Petzold-style Windows 1.0 message handling instead).
>> The people who understand OnCmdMsg don't need to ask questions about handling EN_KILLFOCUS
>> in it, because they wouldn't use it for that purpose.
>>
>> OnCmdMsg should never be used in the context that it is used here.
>>
>> I came to detest EN_KILLFOCUS validation years ago; I'm sure there are conditions under
>> which it should be used, but most people seem to think that validation should be done on
>> focus departure, and my users seem to like the style I give them, of dynamic real-time
>> validation (which wouldn't work if it had to do a query on a database on each keystroke).
>> In the few cases where I used EN_KILLFOCUS, all I do is PostMessage a validation request
>> to the thread and get out, and do nothing else (KillFocus handlers are delicate).  And I
>> NEVER pop up a dialog box if there is a validation failure (intrusive, obnoxious, and a
>> constant annoyance to users).  I find the simple paradigms don't take human beings into
>> consideration; they are designed by programmers for the convenience of programmers, and
>> their purpose is not to make life easy for the end user, but easy for the programmer.
>>                                         joe
>>
>>
>>
>> On Mon, 11 Feb 2008 20:34:06 -0500, "Ajay Kalra" <ajayka...@yahoo.com> wrote:
>> >We used OnCmdMsg extensively to route it to custom CCmdTargets. It works
>> >well. However in this case, I have no idea why would you use OnCmdMsg in
>> >this case but I dont really know what OP is doing.
>>
>> >Using OnCmdMsg is actually very helpful. It lets you customize MFC command
>> >routing.
>>
>> >---
>> >Ajay
>>
>> >"Joseph M. Newcomer" <newco...@flounder.com> wrote in message
>> >news:aoe1r39ulla5hnv2qreni5hh3c7ddv9k7p@4ax.com...
>> >> I'm always curious why OnCmdMsg would be used.  This always struck me as
>> >> delicate and a
>> >> bit dangerous.  So if the behavior changes in a different version of VS, I
>> >> would not at
>> >> all be surprised to see strange behavior with this approach.  Why can't
>> >> this be handled by
>> >> an EN_KILLFOCUS handler in m_Edit2 (and why are you using such
>> >> highly-mnemonic names, when
>> >> human-readable names would make more sense?)
>>
>> >> Show the code, but the approach sounds dangerous.
>> >> joe
>> >> On Mon, 11 Feb 2008 11:35:04 -0800 (PST), Alexander Stoyakin <st...@ua.fm>
>> >> wrote:
>>
>> >>>Hello,
>> >>>please assist in solving critical problem which I faced after
>> >>>migration of my project to Visual Studio 2005 from Visual Studio 6.0.
>> >>>My project is a document-view based application, view class is
>> >>>inherited from CFormView, it is a dialogue with multiple edit fields.
>> >>>For example, field m_Edit1 has OnKillFocus(...) handler defined which
>> >>>validates user entered data. The next field m_Edit2 doesn't have this
>> >>>handler. At the same time I have overriden method OnCmdMsg(..) in my
>> >>>view class. This method performs some checking for content of m_Edit1
>> >>>when EN_KILLFOCUS is sent and calls OnCmdMsg(..) of the parent class.
>> >>>For some years both methods - OnKillFocus(..) and OnCmdMsg(...) for
>> >>>m_Edit1 and message EN_KILLFOCUS worked ok when user filled m_Edit1
>> >>>and  moved focus to the next field. No changes to this functionality
>> >>>were done. The only change was recompilation with Visual Studio 2005.
>> >>>Now OnKillFocus(..) works ok for m_Edit1.  But strange problem is that
>> >>>OnCmdMsg(...) doesn't process EN_KILLFOCUS for m_Edit1 anymore. In
>> >>>debugger I saw that when user leaves the field m_Edit1 OnCmdMsg(..) is
>> >>>called for m_Edit2 in this case. It is unclear why field ID was
>> >>>incremented in OnCmdMsg(...) call. It seems to be internal work of
>> >>>MFC, not my code. Do you have any suggestions what may be the reason
>> >>>of this problem,or, at least, what should I check?
>>
>> >>>P.S. I tried to create some simple test example, but it works ok. The
>> >>>problem happens in my thick client with rich functionality of the edit
>> >>>controls.
>>
>> >>>Thanks,
>> >>>Alexander.
>> >> Joseph M. Newcomer [MVP]
>> >> email: newco...@flounder.com
>> >> Web:http://www.flounder.com
>> >> MVP Tips:http://www.flounder.com/mvp_tips.htm
>>
>> Joseph M. Newcomer [MVP]
>> email: newco...@flounder.com
>> Web:http://www.flounder.com
>> MVP Tips:http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15975)
2/12/2008 5:04:55 PM
Exactly. That is how we used it also. Thats how I discovered it.

We in fact had a collection of CCmdTarget. The collection itself was derived 
from CCmdTarget. It simply routed to each individual CCmdTarget. We 
essentially retooled MFC default command routing as it was too narrow for 
our needs.

---
Ajay

"Tom Serface" <tom.nospam@camaswood.com> wrote in message 
news:9F274771-567A-43F9-B826-62FCD7D30518@microsoft.com...
>I still find it to be handy when I have more than one view and want each of 
>them to get the command targets so the one that handles it can get the 
>messages even if not focused.  It still seems to be working as advertised.
>
> Tom
>
> "Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
> news:6415AC7F-B838-4190-98A4-FC5DB8EC57C3@microsoft.com...
>> We used OnCmdMsg extensively to route it to custom CCmdTargets. It works 
>> well. However in this case, I have no idea why would you use OnCmdMsg in 
>> this case but I dont really know what OP is doing.
>>
>> Using OnCmdMsg is actually very helpful. It lets you customize MFC 
>> command routing.
> 

0
ajaykalra (6842)
2/13/2008 12:26:15 AM
Reply:

Similar Artilces: