Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS General Discussion » CExtTabWnd Collapse All
Subject Author Date
francis baker Mar 22, 2007 - 10:06 PM

Tab Window keeps coming to the top of the window and covering my CStatic controls on mouse over. ANyway to force it to ignore the mouse over event or stay on the bottom of the z-order? thx.

Technical Support Sep 19, 2008 - 11:41 AM

The tab common control and its CTabCtrl wrapper class in MFC is the window which consist of tab items area and tab page border. The tab common control part inside tab page border is hollow part. It’s simply not painted part of tab common control window. Such tab control works OK if it’s created inside non-resizable dialog window. It’s source of flicker effects in resizable dialogs.

The CExtTabWnd control in Prof-UIS is not based on the tab common control. Our tab line control is window written from scratch. It contains only tab items area. So the CExtTabWnd control should never intersect with other dialog control. If you need something like property sheet what contains several page windows and tabs for switching active/selected/visible page window, then you should use the CExtTabPageContainerWnd control. Please take a look at the ProfUIS_Controls sample application. There are two dialog page in this sample application dedicated both to tab line control and tab page container control. Both controls can be created as custom dialog controls.

Ed Nafziger Sep 18, 2008 - 7:17 PM

I’m experiencing the same issue with the tab control covering other controls, using ProfUI 2.60. Perhaps this is fixed already in later versions, I dont know.

>> It is not completely clear what you actually mean.

What francis baker is describing is probably the most common use of a non-page tab control:

1) you add a tab control to a dialog.
2) you resize the tab control to take up most of the dialog.
3) you add controls to the form, in the area of the tab control, either dynamically at runtime, or in the dialog form editor.
4) at runtime you change the controls in the dialog based on what tab is selected.

the problem is that the controls are hidden by the tab control. this works fine in mfc (without profui) but not with profui.

setting the z-order of the tab control, using SetWindowPos to bottommost does not work.

Tab controls do not have a "background" property, otherwise I would have tried setting it to "transparent".

setting the tab order of the tab control to the highest value in the dialog does not work.

setting the z-order of all the controls in the dialog to topmost is an unacceptable solution and i didn’t even bother to try it.

I set the height of the tab control so that is just a row of tabs, and placed the controls below it, but this looks stupid because you are missing the border that typically surrounds a tab control.

francis baker Mar 23, 2007 - 2:23 PM

Just that any control like a CExtLabel that I place on the CExtTabWnd Control gets covered whenever I mouse over any part of the Tab Control. It pushes the label behind the tab.

Technical Support Mar 26, 2007 - 12:21 PM

If you place several windows in the same area, the window, which has a higher z-order, will certainly cover windows which have a lower z-order. By the way, what is the reason for placing CExtLabel or other controls in CExtTabWnd? Did you try the SetWindowPos() method as we suggested?



francis baker Mar 26, 2007 - 12:59 PM

the CExtTabWnd still moves to the front whenever the tab control is touched with the cursor, even after setting the Z-Order. I was putting a label on the client area of the control for the functionality of the page. I have tabs that when selected show different controls. I just need the CExtTabWnd to act as a selection mechanism. I have now made the tab control of height 0, so only the tabs show, not the client area of the control. But this is a poor work around, I think. Thanks.

Technical Support Mar 27, 2007 - 7:56 AM

Would you send us a screenshots or/and a test project that demonstrates the problem so that we can help you?



Technical Support Mar 23, 2007 - 2:17 PM

It is not completely clear what you actually mean. Would you send us some screenshots which demonstrate the problem? Please note you can use the SetWindowPos() method for changing the z-order of a child, pop-up, or top-level window.

Ed Nafziger Sep 18, 2008 - 7:17 PM

I’m experiencing the same issue with the tab control covering other controls, using ProfUI 2.60. Perhaps this is fixed already in later versions, I dont know.

>> It is not completely clear what you actually mean.

What francis baker is describing is probably the most common use of a non-page tab control:

1) you add a tab control to a dialog.
2) you resize the tab control to take up most of the dialog.
3) you add controls to the form, in the area of the tab control, either dynamically at runtime, or in the dialog form editor.
4) at runtime you change the controls in the dialog based on what tab is selected.

the problem is that the controls are hidden by the tab control. this works fine in mfc (without profui) but not with profui.

setting the z-order of the tab control, using SetWindowPos to bottommost does not work.

Tab controls do not have a "background" property, otherwise I would have tried setting it to "transparent".

setting the tab order of the tab control to the highest value in the dialog does not work.

setting the z-order of all the controls in the dialog to topmost is an unacceptable solution and i didn’t even bother to try it.

I set the height of the tab control so that is just a row of tabs, and placed the controls below it, but this looks stupid because you are missing the border that typically surrounds a tab control.