mfc >> Dialog Box: Which control gains the focus?

by Marc D. » Sat, 29 Jan 2005 18:03:55 GMT

Hello everybody!

Sample:

extern CMyDialog* pDial;
(initialisation)
...
(entering datas)
pDial->ShowWindow(SW_HIDE);

(other processing)

pDial-ShowWindow(SW_SHOW);
pDial->SetFocus();

Which control has the focus?

In a project developped with Visual Cpp version 5 & 6, it's the last control
having the focus when dialog was visible.

An other project developped with Visual Studio .Net, it's always the
first control (first in tabulation order) which has the focus.

With or without MFC, the behaviour is the same.

Who knows the reason why?

What is exactly behind pDial->SetFocus() (or SetFocus(hDial)) ?

Thanks in advance!








mfc >> Dialog Box: Which control gains the focus?

by thatsalok » Sat, 29 Jan 2005 19:49:43 GMT


the Ctrl with Tab Order 1 will gain Focus.
if the tab order 1 is static ctrl the focus is on corresponding EditBox or
ctrl on next tab order

With Regards
Alok Gupta
Visit me at http://alok.bizhat.com

"I think this will Help"



control





mfc >> Dialog Box: Which control gains the focus?

by Marc D. » Mon, 31 Jan 2005 05:17:42 GMT

Thanks for reply, Alok!
.......
.......
This is true as long as no Ctrl owns focus when the Dialog becomes hidden.
In this case, the same Ctrl will gain focus when the Dialog becomes visible
again.

This can be achieved using a TabCtrl with the "FOCUSNEVER" style.

As I know, with all the other methods (Button, ToolBar, ListCtrl...) any
Ctrl loses Focus BEFORE we can call pDial->ShowWindow(SW_HIDE);

Do you have another idea?

Marc.

"thatsalok" < XXXX@XXXXX.COM > a rit dans le








Similar Threads

1. OnNcPaint not called when dialog gains focus

2. Windows "randomly" setting focus to controls when close "unrelated" dialog box

Hello,

I have an (MFC based) app that has a couple of windows that stay open at all times.  One of these windows is a CFormView (for
non-MFC people, a dialog box in a scrollable window) that has a Checkbox and some radio buttons.  The following sequence of steps
causes what appears to be random behavior on the part of Windows (causing me a lot of problems):

1) Click the checkbox and then click on any radio button.  At this point, of course, the focus is on the radio button just clicked.
2) Move to another window and take some some actions that result in opening of a dialog box.
3) Close the dialog box

Windows then automatically sets focus to a control (button) back in the CFormView.  Usually it sets the focus back to the Checkbox
but some times it sets it to a "randomly selected" radio button.  The problem is that these buttons have handers that fire when
Windows sets the focus but since this didn't occur as a result of an actual selection by the User a variety of undesired actions
occur!

Here is a summary of how the dialog box is laid out:

CFormView's Dialog Box Configuration:

Checkbox	(Group & Tab Order Position #1)

Group #1
Radio Btn #1	(Group & Tab Order Position #2)
Radio Btn #2	(Tab Order Position #3)

Group #1
Radio Btn #3	(Group & Tab Order Position #4)
Radio Btn #4	(Tab Order Position #5)
Radio Btn #5	(Tab Order Position #6)

I have a couple of questions:

1) When I click away from the CFormView onto another window the focus (dotted line) on the last clicked control visually disappears.
That makes sense because the whole CFormView has lost focus.  Why does Windows then set a focus back in the CFormView when a dialog
box is closed, especially since that dialog box has no "relationship" to the CFormView?   If it's OK for no focus to be displayed
once I click *OUT* of the CFormView it seems that until the User clicks back *INTO* the CFormView that there shouldn't be any focus
rectangle visible in the CFormView.  The fact that I closed a dialog box doesn't seem to be a reason to suddenly show focus back in
the CFormView.

2) More importantly, can anyone explain why the focus that does get set in the CFormView seem to be randomly placed?  Most of the
time the focus reappears on the Checkbox (Tab Order #1) but sometimes it appears on a "randomly selected" radio button.  The
selection may actually be affected by the sequence in which buttons in CFormView are being clicked before clicking out of CFormView
but I can't see a pattern.

3) When focus is set to a "randomly selected" radio button (as trioggered by closing a dialog box), that radio button's handler is
fired.  However, as I mentioned above, most of the time the focus does get set to the Checkbox but when Windows sets focus to the
Checkbox its handler *IS NOT* fired.  Why the difference in behavior?  Thst is, if Windows setting focus to a radio button triggers
its handler why doesn't Windwos setting focus to the Checkbox trigger its handler?

Thank you.

Al Koch,
 XXXX@XXXXX.COM 

3. (ASP.NET) User control browser unable to gain focus - CSharp/C#

4. Model Dialog box causes another application to get focus

We have a model dialog box(well a bunch of them) and it seems that
when you cancel one of the in our application it will activate and
bring the focus to another open window (not in our application) anyone
know why this is and how to correct it?  it should set the focus to
our application and not "activate" another window and make that window
have the focus

5. Focus in multiple dialog boxes

6. dialog controls breaking dialog box...

I'm trying to create a dialog box that pops when a menu item is selected, and it works fine unless I put certain controls in the dialog box.  I tried a month calendar, slider, and a date time picker, and with these controls the dialog box doesn't appear when I select the menu item.  However, if I delete those controls from the dialog box, and just have buttons, it appears fine.  Any ideas?  Thanks in advance

NH

7. How Does a Dialog Box Set the Focus?

8. Modeless Dialog Boxes - Knowing when it terminates, Terminate without using delete Dlg and Getting input Focus

Hi,

I am using a Modeless dialog box.

1. When I launch the Dialog box, how does one know when it ends?
     Does it have to post a message back to the calling CWnd?
     Is that the standard method?

2. I am using Animate to close the Dialog.
    Instead of using delete dlg; I call a method CloseTheDialog(),  then dlg 
= NULL;
    After the Timer has expired for my nifty closing animation, I post a 
WM_CLOSE message to itself.
    I can see it going though the motions of closing, except for the 
destructor CDlg::~CDlg.
    When the App quits, I get memory leaks because the Dlg object is still 
hanging around.
    If I don't set dlg=NULL, and in my desctructor CView::~CView, I delete 
the dialog object
    if(Dlg != NULL){ delete Dlg; }
    I see it calling the destructor CDlg::~CDlg and I get no memory leaks.
    Am I to understand that closing a Dialog Box, doesn't necessarily delete 
the Dialog Object?
    I've tried adding delete this; to no avail.
    I could post a message back to the calling CWnd, but I am curious as to 
why the object is not getting deleted.

3. It's strange, but the mouse seems to be going to the background View,
    instead of the focus being on the Modeless Dialog.
   Shouldn't the Modeless Dialog automatically regain input focus?
   Do I have to add some Mouse Even for the Modeless Dialog Box to regain 
input focus?


Thanks again,
--