mfc >> TABSTOP problem

by vadiraj_br » Thu, 27 Nov 2003 13:18:16 GMT

I have a dialog where in depending on the selection from a combo box,
the controls below are going to be different. For doing this I have
put a static control in the place where I am going to show different
controls. I have created different dialog templates for each option.
Consider the case of particular option, say "MySQL". Corresponding to
this option, there is a dialog in resource, the style of which is
child and no border. I have added a class for this dialog called
CMySQLDialog. Inside CMySQLDialog there is a function called
CreateFromStatic which takes parent and ID as parameters. What I do is
create an object of CMySQLDialog inside the main dialog, say
m_mysql_dlg and then call m_mysql_dlg.CreateFromStatic(this,
IDC_STATIC1). Here IDC_STATIC1 is the ID of static control I have
placed in main dialog. Below is the code for CreateFromStatic

BOOL CMySQLDialog::CreateFromStatic(CDialog* pParent, UINT nID)
{
ASSERT_VALID(pParent);

CWnd* pWnd = pParent->GetDlgItem(nID); // Don't look, Joe!

if (!pWnd)
return FALSE;

if (Create(IDD, pParent))
{
CRect rc;

SetDlgCtrlID(nID);

pWnd->GetWindowRect(&rc);
pParent->ScreenToClient(&rc);

SetWindowPos(
pWnd,
rc.left,
rc.top,
0,
0,
SWP_NOSIZE);

ModifyStyle(0,WS_TABSTOP);
}

pWnd->DestroyWindow();
return (IsWindow(m_hWnd));
}

Everything works fine. When I change the option, different dialogs are
shown below.
Now the problem is how to set the TAB_STOP. On the main dialog there
is one combo and two buttons. On hitting tab the focus keeps moving
between only these three controls and never enters the child dialog
within, though I have set the style for child dialog as WS_TABSTOP.
What I want is on hitting tab the focus should move to combo box..then
on hitting again it should enter the child dialog....move inside all
controls within...on hitting the tab from last control within child
dialog, it should leave the child dialog and should focus on the next
control on main dialog,i.e the button.

How can I acheive this.

vadi


mfc >> TABSTOP problem

by David Lowndes » Thu, 27 Nov 2003 15:47:16 GMT


>Now the problem is how to set the TAB_STOP. On the main dialog there

vadi,

Try setting the WS_EX_CONTROLPARENT style on the embedded dialog
window.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq



mfc >> TABSTOP problem

by vadiraj_br » Thu, 27 Nov 2003 21:21:11 GMT

Thanks Dave,

It worked.





Similar Threads

1. Tabstop problems in MFC/CLR C++ application

2. TabStop ignored in a tabControl

Hi All,

I have a fancy form which contains a tabControl with 2 tab pages. and
many more widgets.
I set the tabStop property of the tabControl to true and the index to
4, but it is ignored! The tabIndex is valid, I don't have any other
control with this tabIndex.
Anyone can come up with an idea why? BTW, the names of the tabPages
are hidden with labels. maybe this is causing the problems?

Thanks.

3. TabStop Order Confusion solved - CSharp/C#

4. What am I missing (TabStop)

Where is my TabStop property.
I want to prevent tabbing to a label.
In the MSDN it shows

Label.TabStop Property
This member supports the .NET Framework infrastructure and is not intended
to be used directly from your code.

And sure enough it is not accessible.

HUH?

BJ


5. TabStop mystery - CSharp/C#

6. How to set DataGridTextBox.TabStop ?

7. TabStop Order Confusion - CSharp/C#

8. TabStop = False changed (automatically) to True after compilation (VS 2008, Win form)

Since all the units would likely be the same, for a given set of inputs, 
indeed, I will change the UI.


"Harlan Messinger" < XXXX@XXXXX.COM > wrote in message 
news: XXXX@XXXXX.COM ...
> Peter Duniho wrote:
>> Or, another way to look at it: if you are so certain that changing the 
>> setting is such an uncommon, useless thing for a user to do that you are 
>> willing to make it so inconvenient for them to be able to do it, why is 
>> that setting in that form in the first place?  Why have something in the 
>> form that you expect users to just always be skipping over?  Put the 
>> setting somewhere else, out of the way where it's not interfering with 
>> efficient use of the rest of the UI.
>
> That's what I was thinking. Even in cases where a user is entering 
> measurements as psf, however rarely that may occur, unless you expect that 
> any user on any occasion will want to enter some measurements as kPa and 
> others as psf, you ought to provide only one place on the page for the 
> selection of the unit.