Re: About OnSetFocus - Subnote - Update
Hi Joe,
Issuing a new SetFocus inside an OnKillFocus (or OnSetFocus) is not =
well-defined and
should not be done. PostMessage a user-defined message back to this =
window to set focus
to itself. In the past, this actually caused the OS to lock up and =
required a reboot.
It took me a while to figure out the PointInRect thingy.
It works, but I will take your advice.
I don't want to run into any issues later on.
I am happy I got the focus thing all figured out!
Thanks,
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message =
news:tl3cb3d0513tj2a5c63b7jrfn10n90tab6@4ax.com...
See below...
On Sat, 4 Aug 2007 17:50:00 -0700, "Nobody" <Nobody@yahoo.com> wrote:
Hi,
Here is an update to OnSetFocus.
The following code snippets are what I am using in my custom control.
Its working nicely.
void CSomeControl::OnKillFocus(CWnd* pNewWnd)
{
CSomeBase:OnKillFocus(pNewWnd);
CPoint point;
::GetCursorPos(&point);
CWnd::ScreenToClient(&point);
CRect Rect;
GetClientRect(Rect);
if( Rect.PtInRect(point) )
{
SetFocus();
****
Issuing a new SetFocus inside an OnKillFocus (or OnSetFocus) is not =
well-defined and
should not be done. PostMessage a user-defined message back to this =
window to set focus
to itself. In the past, this actually caused the OS to lock up and =
required a reboot.
From the WM_KILLFOCUS documentation:
"While processing this message, do not make any function calls that =
display or activate a
window. This causes the thread to yield control and can cause the =
application to stop
responding to messages."
Note that a SetFocus can have this side effect.
****
}
}
int CControl::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT =
message)
{
// When Control becomes active, get the focus. Makes sense.
SetFocus();
return CWnd::OnMouseActivate(pDesktopWnd, nHitTest, message);
}
This is a temporary soluction if there is only 1 control in a view.
It will work, but using the above code snippets are better and =
probably how MFC controls work.
void CMyView::OnSetFocus()
{
GetControl()->SetFocus();
****
Same issue. You should not change the focus within a change-focus =
notification.
****
}
Regards,
"Nobody" <Nobody@yahoo.com> wrote in message =
news:u6H85RSxHHA.2432@TK2MSFTNGP04.phx.gbl...
Hi Dave,
I knew commenting out
CView::OnMouseActivate(pDesktopWnd, nHitTest, message);
was going to be bad.
So, to remedy that.
int CMyView::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT =
message)
{
CWnd* pWnd = GetFocus(); //Save Current Focus
int ret = CView::OnMouseActivate(pDesktopWnd, nHitTest, message);
pWnd->SetFocus(); //Restore it
return ret;
}
I suppose I could have done it the easy way.
void CMyView::OnSetFocus()
{
GetControl()->SetFocus();
}
But, at least I know what is going on now anyways.
And, if I have multiple controls in a View, like that of a Dialog, it =
will work just like a Dialog, but without the tab support.
Regards,
"Nobody" <Nobody@yahoo.com> wrote in message =
news:usIT8ROxHHA.4464@TK2MSFTNGP02.phx.gbl...
Hi David,
I get it now.
It really doesn't matter if you do SetFocus() inside a control in =
OnInit().
Somebody else could be doing SomethingElse()->SetFocus() afterwards, =
which takes the focus away.
I ended up removing OnSetFocus() and OnKillFocus() and the SetFocus() =
in OnInit()
I added this to get it to work correctly.
int CControl::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT =
message)
{
// When Control becomes active, get the focus. Makes sense.
SetFocus();
return CWnd::OnMouseActivate(pDesktopWnd, nHitTest, message);
}
Think of it this way. When you tab to controls in a dialog, you would =
think the dialog manager
sets the focus to the next tabbed control, which I suppose is does, =
since it was working correctly.
But, what happens when a control is clicked instead of tabbing? It =
didn't work.
So, Tabbing works, but not if the control is clicked. That was the =
reasoning behind adding OnMouseActivate()
I was also having a problem in the View.
As soon as the Control gets the focus, it was immediately taken away.
Thats probably because when the Control becomes active, it makes the =
View active, which in turn takes away the focus.
So, what I did was this
int CMyView::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT =
message)
{
// return CView::OnMouseActivate(pDesktopWnd, nHitTest, message);
return TRUE;
}
That is what I was looking for. This is the function that makes a =
window active.
Sure enough. down inside of CView::OnMouseActive() it has
CWnd::OnMouseActivate()
HWND hWndFocus ::SetFocus().
*Note that it could be dangerous to just comment out =
CView::OnMouseActivate() I will probably have to move CView stuff to =
here and just remove ::SetFocus.
I am not having any problems as of yet.
So, that is actually how it works!
Also, in a dialog, I was getting that "Bonk" sound.
I actually don't need the WM_KEYDOWN messages and I just use =
PreTranslateMessage instead.
CControl::OnPreTranslateMessage()
{
If(pMsg->message == WM_KEYDOWN)
{
UINT nChar = (UINT)pMsg->wParam;
UINT nRepCnt = (UINT)pMsg->lParam & 0xFF00;
UINT nFlags = (UINT)pMsg->lParam >> 16;
OnKeyDown(nChar, nRepCnt, nFlags);
return TRUE; //No further processing needed. No "Bonk" sound.
}
return CWnd::PreTranslateMessage()
}
More about controls. If interested.
Dialog Initialization is different from Control.Create()
OnCreate() is not called when used in a Dialog.
Which is messing me up somewhat.
It has to do with embedding Custom Controls in a dialog.
A window is automatically created for you.
That way, you don't need to set the Rect Coodinates. It is done =
automatically.
http://www.codeproject.com:80/miscctrl/customcontrol.asp
Second, I am not getting the WM_INITDIALOG messages, so I have to =
intialize the control manually
BOOL CDlgTest::OnInitDialog()
{
//I shouldn't have to be doing it this way.
GetControl()->InitControl();
}
Back to the Drawing board, err make that Keyboard.
Thanks,
"Nobody" <Nobody@yahoo.com> wrote in message =
news:%23wsX5NExHHA.312@TK2MSFTNGP04.phx.gbl...
Hi David,
Your probably right. I haven't gotten to that point just yet.
Like I said, I have not tested it in a Dialog.
The odd thing is that if I don't comment out the =
CWnd::OnKillFocus(pNewWnd);
The messages go directly to the View.
The control has the "Focus", (Need a different word) but the =
WM_KEYDOWN messages are going to the View.
I'm not sure what makes a window "Active", or if it even cares.
I think it is just another rect and somewhere in the background, it =
does something like
IsTopLevelWindow() Yes
PointInRect(point) Yes,
Well then, send mouse messages to that Window.
I don't know exactly what is going on just yet.
I can open a dialog, or any other window and whatever window/control =
gains the focus.
and when I come back to my control, it has focus.
(Note that I do not call set focus again. I only call SetFocus once.)
So, that wouldn't be right if it works like your thinking, which =
sounds correct, I might add.
Maybe it is working like OnMouseMove().
If somehow, WM_MOUSEMOVE is disabled, the control would never get the =
mouse messages.
(That could be very well be the case in a static text control, hence =
the SS_NOTIFY ... for keyboard messages )
but, you don't have to call SetFocus() for mouse messages, yet the =
mouse messages still work in other windows,
That could be very well what is going on.
I could just be enabling Keyboard messages to go to my control instead =
of SetCapture() which keeps the messages
from propagating, which is what you and I are thinking.
That is the best I can figure so far.
I'll put the control in a dialog and let you know how things go.
Heck, I am happy I got this far.
P.S.
Something interesting as far as controls go.
Do you know who sends WM_INITDIALOG or WM_INITIALUPDATE.
That is kind of bugging me. CFrameWnd::OnInitialUpdate() might be =
doing it for the View, but I am not sure
who sends the message to the dialog?
P.S.S. Some beer speak. Rambling on...
Thanks,
"David Ching" <dc@remove-this.dcsoft.com> wrote in message =
news:w3hli.37796$YL5.14917@newssvr29.news.prodigy.net...
I'm still not sure if it is correct behavior for a control to set =
focus to
itself on creation. What if the caller doesn't want that? What if =
there
are 2 or more instances of the control in the dialog; which one =
should get
focus? The caller (i.e. dialog) needs to have control of this! The =
world
would be a mess if all the controls in the dialog tried to grab =
focus like
this.
-- David
"Nobody" <Nobody@yahoo.com> wrote in message
news:eBVB$VCxHHA.4592@TK2MSFTNGP05.phx.gbl...
Hi,
I had to comment out the CWnd::OnKillFocus(). I guess that prevents =
if from
losing focus.
like it shows here http://www.winterdom.com:80/dev/mfc/PopupEdit.cpp
#include <afxpriv.h> //for WM_INITs
/* If in a dialog */
ON_MESSAGE(WM_INITDIALOG, InitialUpdate)
/* If in a view */
ON_MESSAGE(WM_INITIALUPDATE, InitialUpdate)
Control::InitialUpdate(WPARAM wParam, LPARAM lParam)
{
SetFocus();
}
void Control::OnKillFocus(CWnd* pNewWnd)
{
// CWnd::OnKillFocus(pNewWnd);
}
I haven't tested it in a dialog yet.
Thanks all!
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm