Tabindex major trouble

[Guest]

Hello.

I have a form with a tab control with some tabpages. On each of the tabpages
I have separate user controls. The user controls constist of labels,
textboxes, combo boxes and datagrids.

The problem is that I can't move focus between the input controls with the
tab button. At all. All my controls have the TabStop property set to True,
and have a positive number.

The form is inherited from a form which in turn is inherited from a windows
form. All of the controls I use are my own, inherited from windows controls.

What could possibly be wrong? Where should I look?

Thanks
- Niklas

 

[Saurabh]

Is the form being shown as a dialog against some other window? If yes is it
modal or modeless ?

 

[Guest]

It is opened with

this.Show();

- Niklas

Is the form being shown as a dialog against some other window? If yes is it
modal or modeless ?

 

[Guest]

Hmm, maybe I was a bit short.

I have a third party GIS program that acts as the users main program. Within
that, a button of ours is clicked and the button instantiates the class where
the form object resides. The form is initialized with some functions we
wrote, and then shown with this.Show();

So the form is modeless in the sense that it will always be visible on top
of the GIS program, but the user doesn't have to close the form to use the
GIS program.

Thank you
- Niklas

 

[Saurabh]

If you are saying that your dialog is shown against another application then
there could be issues. Moreover the tabkey navigation on dialogs is differen
in Win32 and .NET applications. If your parent application is a Win32
application, the translation of tab into a navigation command is not sent to
your dialog and it simply will not work.

There is a possible workaround but it will never work a 100% if your dialog
uses tab control because the tab control pages are now children whereas in
old Win32 days they used to be siblings of the control... so on and so
forth... If you could let me know your exact scenario, I may be able to
help.

Regards,

--Saurabh

 

[Guest]

Thanks Saurabh for looking into this.

I don't know what more I can specify without sending you a ton of classes
and a GIS program with a license cost of $20 000...

What I can tell you is that my combo boxes are of the type "DropDownList",
but one of them I mistakenly set to "DropDown", and that one reacted
correctly to the Tab press. We have overridden some events in our inherited
controls, but in all of them we call base.OnEvent(e) before or after our
added code.

Is there any specific info that could help you getting an idea on this? I am
most willing to supply you with answers to anything.

Thanks.
- Niklas

 

[Saurabh]

Well don't send me the classes or the GIS program worth $20000 but you could
always tell me the name of he GIS program and or whether its a .NET app or a
native Win32 app

--Saurabh

 

[Saurabh]

Right Niklas,

I assume that your GIS program is a Win32 application. In fact I am fairly
sure that it is a Win32 application. This means that it is running its own
message loop. Your form gets shown against that application meaning your
..NET forms do not have their own message loop.

The tabkey navigation is implemented differently in .NET from Win32. If you
use spy++ to see the classes of your controls, you will notive that in the
old Win32 classes, the tab key will work as you have rightly pointed out
about the combobox, and It will not work in the .NET classes.

You can hook into the parent application using Windows API and hijack the
messageloop of the parent GIS application. Then you can use the Windows API
"IsDialogMessage" to interpret it in your winform.

Other option is, You can run your application in a separate thread so that
your forms get their own message loop and the tab key navigation will work.

Let me know if you need any further information.

--Saurabh

 

[Guest]

Saurabh,
The GIS program I am using is ArcMap from ESRI, and you are right, it is
Win32 based.

I think you are right also in the handling of navigation, because I set up a
test project that I ran as an independent exe, and these troubles never
occured. That can also explain a strange behaviour that I noticed: In both my
projects I added code in the KeyPress event for one control, to print the
pressed KeyCode. In the exe, all keys but Tab showed up in the Output panel,
whereas the form contained in ArcMap printed the Tab key as well. As if it
was just another button.

So, if I get this straight, the problem is that my contained code doesn't
understand that the Tab key press implies a navigation command? It just looks
at it as another keystroke?

In between looking at forums for answers I tried to implement my own
navigation using GetNextControl and got pretty far until I noticed too many
if's and but's on the way. As I see it, even if I hijack the windows message,
I would still have to implement my own navigation, right?

If so, can't I as well just look at KeyPress event?

If not, is there some way to tell the system to navigate to the next
control, besides calling GetNextControl?

Again, thanks a lot for your time and effort.
- Niklas

 

[Guest]

One thing that contradicts the theory that my .NET application doesn't get
the "navigation" command is the mentioned difference between combo boxes that
are of the type "DropDown" vs "DropDownList".

The combo box of "DropDown" type handles Tab presses correctly.

The combo box of "DropDownList" type doesn't.

Really strange to my eyes.
- Niklas

 

[Saurabh]

Niklas,

As I had mentioned in my last post, there are 2 options.

1) The simplest option is to run your forms in a new thread and it will
work. I had tried this in one of the test projects and it seemed to work. I
am not sure how 'seamlessly' integrated your app is with the parent GIS
application. If it becomes too much of a hassle to communicate to main app
from your app running in different thread, then I'll not recommend it.

2) The other solution is to place a hook in the main app and inspect each of
the messages using 'IsDialogMessage' this function translates the navigation
message into the navigation command. You can inspect the return value from
this function to see if it was actually a navigation message or just any
message.

Out of these 2 I'll recommend option 1 as it will take away all the problems
(and may present you with the new set of problems for inter - thread
communication)

If you decide to go with option 2, I'll warn you right now that On the tab
control, you will be able to navigate within each page but as soon as you
get on the tab page header, you will not be able to enter into the page
again. So It does not work a 100% and that is because of the differences in
the Win32 tab control and the .NET tab control which I had mentioned in the
last e-mail

Here's how you can see the difference using Spy++:
If you look at a property sheet (e.g. properties of my computer) you will
see that the tab pages are siblings of the tab control. This allows
IsDialogMessage to find the pages. Since the pages also have
WS_EX_CONTROLPARENT, IsDialogMessage can navigate into it and find the
page's children windows.

If you look at the .Net form in your application, you will see that the tab
pages are children of the tab control and the tab control does not have
WS_EX_CONTROLPARENT. This will prevent the IsDialogMessage finding the tab
pages and navigating into them.

I have not tried altering these flags on the tab control but you may try and
see if you get the correct behaviour.

Once you have made your mind on which option to use, and then if you get
stuck, feel free to write again. My email id is not correct so you'll have
to post to the newsgroup

Hope this helps,

--Saurabh