ATL problem 1

[IonelBurtan]

I have a dialog class derived from CAxDialogImpl with a fie controls on it, a tab control and some tabs, each of them being a dialog itself.

All is working ok on it except one thing: the tab order.
That is when the focus is on the tab control - it does not enters the controls on the current tab, but skips to the next control in the main dialog.
That is: the control from the tabs on tha tab control cannot be reached with the keyboard, only with the mouse.

I have tried to capture the OnChar Message on the dialog to take care of VK_TAB myself but, great surprise, the code NEVER enters the OnChar routine. I saw the CHAIN_xxx family macros but I do not know how to use it.

I do not know why,
Any idea or help appreciated,
Code samples appreaciated



s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...

http://www20.brinkster.com/ionelb

 

[xwb]

Have you tried the other key combinations like ctrl-tab, alt-tab, shift-tab. They sometimes work. Sometimes you have to use something like ctrl-tab followed by one of the arrow keys.

 

[IonelBurtan]

these does not work either. anyway the problem is to programatically set the tab order in the situation above. Basically the structure is:

CAxDialog - main, modal
|- CCustomTabCtrl - derived from CWindowIMpl
|- CAxDialog - modeless, for the first tab
|- CAxDialog - modeless, for the second tab
|- CAxDialog - modeless, for the third tab
|- CAxDialog - modeless, for the fourth tab
The child dialogs are showed/hidden with ShowWindow and they are positioned with SetWindowPos.

Bye,


s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...

http://www20.brinkster.com/ionelb

 

[fromkc]

Have you tried setting the TAB ORDER using the option from
'LAYOUT\TAB ORDER' while the dialog resource editor is open.

Then when you open your dialog in the InitDialog handler set use the EnableWindow(TRUE OR FALSE) calls to actually grey out or make a control visible.

Out of the 4 controls in your dialog, you will notice that the using 'TAB' from the keyboard will automatically only land on the controls which are enabled and tab order will move in the order order it was set.

If you are over-riding OnInitDialog() handler, set focus to the first control you want focus on when the dlg is displayed.

For e.g.

BOOL CDownloadFile::OnInitDialog()
{
CDialog::OnInitDialog();
CEdit *pEdit;
pEdit = (CEdit *) GetDlgItem(IDC_INPUTFILE);
pEdit->EnableWindow(FALSE);

CComboBox *pProtocol;
pProtocol = (CComboBox *) GetDlgItem(IDC_CODE);
pProtocol->EnableWindow(TRUE);
//
// Enable protocol combo box and set up the data to display.
//
status = PopulateProtocolComboBox(this, pProtocol);
pProtocol->SetCurSel(0);
return FALSE;
// Focus is set on first item in combo box
}

 

[IonelBurtan]

Hello, thank you for your detailed response.
I know about the tab order (this is basic, I have 4 years of VC++). This solved the order only for the outer(or main) dialog.

I also know the trick of returning false from OnInitDialog and set the focus manually to the first control. This did resolve part of the problem.

But the main problem still stands. It do not receive the WM_KEYDOWN with VK_TAB

That is, when the user presses the TAB and the focus is on the tab control (first tab), I have no way of catching that key press (or I did not find it). I have added handlers for WM_KEYDOWN on the main dialog, the tab control (I even tried subclassing it), and on the first dialog coresponding to the first tab. No success.

To make things even more annoying the Spy++ tool application sees a WM_KEYDOWN with VK_TAB being sent to the tab control window, but I cannot catch it. Somehow ATL message processing stops it before reaching my overriden DialogProc or handler function (I tried both)

Please help me if you know something about it,
There is not clue in MSDN and on the web to this problem, I have searched.




s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...

http://www20.brinkster.com/ionelb

 

[fromkc]

Hi! There,
Sorry, My earlier reply was too basic. I haven't worked with TabCtrl much but looks like it is the same as any other control.
I just have a suggestion for you, I looked in MSDN for a sample on using TabCtrl, Which I think you may have already done but anyhow :
FIRE: Demonstrates Windows 95 Common Controls

If you download this example it may give an idea on tab control..they are handling SELCHANGE instead of KEYDOWN, but doesn't matter the message should get to your code.

About the messages not getting to your code, It had happened to me before when I was not getting a WM_TIMER msg., the reason was that my dialog was closing or the object was getting destroyed before it got this message. Just something to look into. I finally used UDM (user defined msgs.) to solve my particular problem.

 

[IonelBurtan]

Hi fromkc,
thank you for your reply

I have studied the sample that you told me(FIRE), a while ago, it does not have any clue for my problem, since it uses MFC window classes not ATL window classes

About using some UDM(user defined message), I( cannot do that, since I am not controling both ends of the messsage). I am controling only the receiver.

I am sure there is something with the way ATL treats messages (unlike MFC, i know how to make things work in a similar project with MFC).
Bad is, that I cannot debug, since most of the code of ATL are macros.

I am still stuck with this,

s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...

http://www20.brinkster.com/ionelb

 

[xwb]

It is strange that ctrl-tab (to go forwards) and ctrl-shift-tab (to go backwards) don't work. Just tried them on the screen properties and it works. Maybe there is something different in ATL/WTL.

 

[IonelBurtan]

Yes, they do not work at all.
In the mean time, I have managed to solve hlf of the problem. Now I get the tab control when the tab is pressed and the focus is on the tab control.
(If somebody is interested, I can explain, it is quite a story)

BUT, I have bumped in the other half.
That is when the focus is on the any of the controls in any of the 4 the modeless child windows (tabs of the tab control) and I press tab, the focus moves out of the tab dialog (not to the next control), and I hear a beep.

Spy++ tells me that the WM_KEYDOWN with VK_TAB is sent ONLY to the control (so the parent does not receive anything).
I am stuck now better that the first time, as the parent dialog does not even receive anything on VK_TAB.

Any ideas?

s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...

http://www20.brinkster.com/ionelb

 

[lchazard]

Ionel,

Googled into your post looking for solution to a problem which may be related. I have an app with multiple processes, one of which parents an ActiveX ATLCTL.DLL. The ActiveX is failing to receive a WM_USER+5 message sent to it. I can see the message in a PreTranslate of the parent, but it blackholes
after that. When I tried (just looking for clues) a SendMessageToDescendants, the hwnd of the ActiveX was not on the group of messages sent (According to Spy++). I have read that WM_USER is obsolete and WM_APP should at least be used; RegisterWindowMessage for robustness.

I'm a little green with Visual C++ and may have used some bad terminology...but maybe if we trade notes, something between our two problems may share a common fault.

Larry

 

[LazyMe]

I have read that WM_USER is obsolete and WM_APP should at least be used; RegisterWindowMessage for robustness.

It's not really obsolete. It's just that it is to be used within a private window class only; it is not to be used throughout an application because it is not guaranteed to be unique, since some window classes may already be using some of them.

Greetings,
Rick

 

[IonelBurtan]

Hi everybody,

I am so glad that you have put a monopoly on the thread I have started WITH ANOTHER PROBLEM that I can just help myself to uncork another beer.
Now, seriously, If you have other issues, why not start another thread?

If you have a solution or even a hint to the actual ATL problem, please do so, if not do not bother anymore. I am tiread oppening this thread and reading issues that I do not care of at this moment.

Bye

s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...

http://www20.brinkster.com/ionelb

 

[farawayfaraway]

Hi IonelBurtan,

In the mean time, I have managed to solve hlf of the problem. Now I get the tab control when the tab is pressed and the focus is on the tab control.
(If somebody is interested, I can explain, it is quite a story)

How did u manage to get the focus inside of CTabCtrl object in a CDialog? I was stuck in the same problem for a few days...

Sorry I am a newbie and cannot help u on ur problem. Hope u will find out what u need soon...

thx in advance.

 

[IonelBurtan]

The trick was to made the main dialog modeless and override the modeless dialog window message loop, filtering messages with IsDialogMessage.
Look for this is MSDN, you will find some example.

Bye,

s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...

http://www20.brinkster.com/ionelb

 

[farawayfaraway]

Hi IonelBurtan,
Thx for ur hint! brilliant idea!

 

[IonelBurtan]

Glad I Counld help!
If you find a solution to the other half of the problem please let me know. I am VERY interested.

Reminder for all that did not read all:
The oproblem is that in a embedded CAxDialog in a ordinary tab Control (e.g. class SysTabControl32) as a modeless dialog, when pressing TAB the focus does not pass to the next member of the modeless dialog but leaves the tab and a beep can be heared. The problem apears only when using ATL window classes, in MFC or pure SDK it works like a charm.

Thanks for any hint on this,




s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...

http://www20.brinkster.com/ionelb