Z-Order and Tab Order

[Paul Squires]

I need to confirm: Once child window controls are created on a dialog, there is no way to alter their zorder without affecting their tab order, right?

From what I can see (and read), the zorder and tab order are essentially the same thing except that the tab order only applies to child windows with the %WS_TABSTOP style set.

I have tried creating the child windows based on tab order and then using SetWindowPos to change zorder but doing so causes the tab order to change.

I am thinking that I will only be able to correctly set zorder for non tabstop child windows (like STATIC). Once I start trying to set the zorder for WS_TABSTOP windows then things start to get weird.

Did any of that make sense?

[Bern Ertl]

Check out Dominic Mitchell's posts (pages 3 & 4) in this ancient thread:

http://www.powerbasic.com/support/pbforums/showthread.php?t=3351

[Chris Boss]

ZOrder and tab order are basically the same thing, if you let Windows automatically handle tabbing.

Now you can intercept the Tab key in your message loop, rather than pass it on to IsDialogMessage and process it yourself to impliment your own tab order.

I am not sure, but you may be able to also process the WM_NEXTDLGCTL and modify its parameters before passing it on to DefWindowProc.

To impliment your own tab order, regardless of zorder, you simply have to override the windows defaults and do the processing yourself.

[Kev Peel]

Yes, Windows uses the Z-order for tab handling. If you have control over the parent's message loop you could handle the tab keys and ordering yourself, as Chris mentioned. The order would have to be stored somewhere (ie. using window properties or user data)

[Paul Squires]

Thanks Guys,

Chris, you're right - I can implement my own tab order and that was something that I did with the very first version of FireFly. The problem is that once I go down that road then I need to be able to handle new controls that are added at runtime, maintain an internal array of control handles, etc... I would prefer to stay with the current IsDialogMessage and let Windows handle all of the messy stuff.

My current train of thought is to only set zorder for non-tabstop enabled controls. At least that will correctly handle Label on Label type of situations.

Thanks,

[Michael Mattias]

SetWindowPos() can be used to change the Z(tab)-order. I just did this two weeks ago for the first time (to add controls at runtime, just like here!) and it worked exactly 'as advertised'

[Michael Mattias]

Oops, gotta read more carefully. That's what you are doing.

I don't understand why you'd want to change the ZOrder for controls on a screen unless you are using Z-order plus clipping to hide/show controls... which can be done a tad more easily using, well, the hide and show functions.

[Chris Boss]

Changing the ZOrder of a control will also automatically changes its Tab order.

It is quite understandable to want to have a different Tab order than the ZOrder at times.

In most instances though, one would not want controls which are tabable to (can get the focus and handle user input) to overlay each other, so their zorder would not be an issue.

Mostly only Static controls tend to be placed overlaying each other, so zorder tends to be critical there. Such controls need not care about tab order and only about zorder.

Paul, in EZGUI I do the following:

- Only Tab order is definable.
The user is told that ZOrder and tab order are the same and the designer only allows defining tab order.
- certain controls are by default set to a very high Tab order (zorder) number, so they will be in the background, such as the Frame control and the Tab control.
- Every time a new control is created or modified the ZOrder (tab order) is automatically reset by enumerating all the controls and calling SetWindowPos

I also prefer to use IsDialogMessage in the message loop since it does so much.

As an alternative, you may want to add a flag to your message loop which will allow the programmer to temporarily turn off the use of IsDialogMessage. I do this with EZGUI. By setting the flag ON or OFF, the user can determine whether they want IsDialogMessage to be used. For example, say when a certain controls gets the focus, you want the Tab key action to be turned off or be at user control. By setting the flag for the message loop and turning off the call to IsDialogMessage the user can process the tab key themselves (or let the control do it, such as with an edit or richedit control).

Then provide some wrappers for commands to move the focus to a specific control. Also when the flag is off for use IsDialogMessage somehow pass a keyboard event to the current control when the tab key is pressed so they can determine what to do.

Since FireFly is SDK based, you have complete control over the message loop and can do whatever you want with it.

In the EZGUI runtime the message loop code is nearly 200 lines of code and I also impliment my own Modal message loop rather than let windows impliment modal windows.

The point is that you can make your message loop as complex as you want and override any default processing any way you like.

Also the message is loop is a great place to add a lot of preprocessing, since Windows posts many messages to the message que, rather than send them directly to the window procedures. You can do some neat stuff by trapping messages in the message loop and preprocessing them, even adding overrides to tab order.