Re: About OnSetFocus - Subnote - Update

From:

"Nobody" <Nobody@yahoo.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Mon, 6 Aug 2007 02:13:21 -0700

Message-ID:

<eGY1NoA2HHA.1336@TK2MSFTNGP04.phx.gbl>

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