Hi all! It is my first post at this forum. Forgive to me my bad English.
I would like to find out, why in editors of dialogue windows these windows are shown by back on before? For example, why last added element is located on the background while my intuition speaks, that it(he) should be in the foreground. I recently have learned about this feature of editors of dialogue windows after had because of it a problem and could not understand c than she(it) is connected,in other words, I did not understand because of what she (it) have arisen (this problem it was possible to solve due to the help received on a forum of a site www.wasm.ru). As I understand, it occurs because of that, editors of dialogues insert descriptions of control elements into a RC-file in conformity of sequence of their insert in a dialogue window. I want to understand, why so is made. What basis for this is? I understand that it to make easier, but it (IMHO) not the serious reason... Please, help me to understand it! Me especially interests, that of it thinks KetilO.
Regards.
I would like to find out, why in editors of dialogue windows these windows are shown by back on before? For example, why last added element is located on the background while my intuition speaks, that it(he) should be in the foreground. I recently have learned about this feature of editors of dialogue windows after had because of it a problem and could not understand c than she(it) is connected,in other words, I did not understand because of what she (it) have arisen (this problem it was possible to solve due to the help received on a forum of a site www.wasm.ru). As I understand, it occurs because of that, editors of dialogues insert descriptions of control elements into a RC-file in conformity of sequence of their insert in a dialogue window. I want to understand, why so is made. What basis for this is? I understand that it to make easier, but it (IMHO) not the serious reason... Please, help me to understand it! Me especially interests, that of it thinks KetilO.
Regards.
Hi Oleg_SK,
Dialog boxes manage all controls behavior. The tab order is the sequence in which the controls will receive the focus while pressing the <Tab> key. To do that, Windows looks the Z order of the controls. The Z order is the order in which controls are positioned inside their parent (the dialog box). The first control (that being on the top) will be the first one to receive the focus. If you change the tab order for a control in the Dialog editor, it will be re-positioned so that, at run time, it has the correct tab order.
Regards,
Ramon
Dialog boxes manage all controls behavior. The tab order is the sequence in which the controls will receive the focus while pressing the <Tab> key. To do that, Windows looks the Z order of the controls. The Z order is the order in which controls are positioned inside their parent (the dialog box). The first control (that being on the top) will be the first one to receive the focus. If you change the tab order for a control in the Dialog editor, it will be re-positioned so that, at run time, it has the correct tab order.
Regards,
Ramon
Hi rsala
Thank for your answer. All that you have told I already I know, and I not absolutely understand, how it is connected to a question (can be I has bad explained?). I know that it is possible to manually change tab order for control elements. Practically I frequently should make it and if in dialogue is much of control elements this process of me tires (especially when I think that the program could make it automatically).
I simply want to know, why process formation of a dialogue window is put " from foot's on a head "? IMHO, it is not difficult for program to insert descriptions of control elements into a RC-file upside-down in relation to sequence of their insert in a dialogue window. It would allow during work of my program ?????? a dialogue window in the same kind in what I saw it(him) in the editor of a dialogue window. Now I receive not that I expect, and I should make a lot of additional work to correct it. It is bad. For example, if I create GroupBox, and then on him{it} I place EditBox I intuitively think that EditBox is in the foreground, and GroupBox on a background. In practice the opposite situation turns out. It is very inconvenient! I want to understand what there are reasons for similar work of editors of dialogue windows.
Regards.
Thank for your answer. All that you have told I already I know, and I not absolutely understand, how it is connected to a question (can be I has bad explained?). I know that it is possible to manually change tab order for control elements. Practically I frequently should make it and if in dialogue is much of control elements this process of me tires (especially when I think that the program could make it automatically).
I simply want to know, why process formation of a dialogue window is put " from foot's on a head "? IMHO, it is not difficult for program to insert descriptions of control elements into a RC-file upside-down in relation to sequence of their insert in a dialogue window. It would allow during work of my program ?????? a dialogue window in the same kind in what I saw it(him) in the editor of a dialogue window. Now I receive not that I expect, and I should make a lot of additional work to correct it. It is bad. For example, if I create GroupBox, and then on him{it} I place EditBox I intuitively think that EditBox is in the foreground, and GroupBox on a background. In practice the opposite situation turns out. It is very inconvenient! I want to understand what there are reasons for similar work of editors of dialogue windows.
Regards.
Hi,
As Ramon explained the order windows are drawn is the Z-Order. When Windows draws a dialog it begins at the lowest control in the Z-Order and draws it, it then draws the next higher one, if it "clips" the lower one that is it intersects it, it will be drawn on top of it. Windows will continue to step through the Z-Order until it has drawn all the controls. In order to have one control placed on top of another you must give it a higher Z-Order, most dialog editors allow you to do this with a TAB order feild or in RadASM you can simply select the control and use the PGUP/PGDN keys to change it's place in the order.
However, the TAB order is not synonymous with Z-Order, the Z axis order of the dialog does not necessarily have to correspond to the tab order. Though in practice when a dialog is initialized Windows makes use of the TAB order to determine Z-Order, it can change during the execution of the dialog, for example if you place one button over another then click the lower one, the Z-Order no longer matches the TAB order.
As Ramon explained the order windows are drawn is the Z-Order. When Windows draws a dialog it begins at the lowest control in the Z-Order and draws it, it then draws the next higher one, if it "clips" the lower one that is it intersects it, it will be drawn on top of it. Windows will continue to step through the Z-Order until it has drawn all the controls. In order to have one control placed on top of another you must give it a higher Z-Order, most dialog editors allow you to do this with a TAB order feild or in RadASM you can simply select the control and use the PGUP/PGDN keys to change it's place in the order.
However, the TAB order is not synonymous with Z-Order, the Z axis order of the dialog does not necessarily have to correspond to the tab order. Though in practice when a dialog is initialized Windows makes use of the TAB order to determine Z-Order, it can change during the execution of the dialog, for example if you place one button over another then click the lower one, the Z-Order no longer matches the TAB order.