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 Tech Support » 2.84 woes continue... Tab windows don't work right anymore Collapse All
Subject Author Date
Krustys Donuts Jan 30, 2009 - 7:53 PM

My application is similar to the TabPages sample in that when I press file->new I get a new tabbed dialog. The bottom of this child dialog is bordered by a dockable window. Unlike the sample, my windows are set up to start out maximized. When I create a child dialog in 2.84, the bottom of my child window gets cut off, which never used to happen. It looks as if the height of the tab on the dialog isn’t taken into account when sizing the window. In other words, the height of the tab is appoximately the same as the amount of the bottom of the dialog that’s chopped off.  <vent>Worked great in 2.83, now broken. I have been using prof uis for a long time and I have to say 2.84 sure has a ton of regressions. I am very frustrated as I’ve been spending HOURS trying to squash these bugs and I’m wondering how many others I haven’t found yet. </vent>




To fix this particular, I had to edit the epically long CExtMenuControlBar::OnHookWndMsg. In it, there is a handler for WM_MDIACTIVATE that no longer works. By comparing the code from 2.83 to 2.84, you can see that the handler is completely different.


2.83 pseudocode:


SetRedraw(false)


CExtHookSink::OnHookWndMsgDefault()


SetRedraw(true)


::RedrawWindow()


 


now in 2.84 (pseudocode)... (notice it’s completely different that 2.83):


CExtHookSink::OnHookWndMsgDefault()


SetWindowPos()


::PostMessage( hWndMdiClient, WM_SIZE, SIZE_RESTORED)  <- Cause the window to be resized incorrectly. Commenting this out makes it work


 


Can you explain why the change was made? There must have been some reason for it although I can’t see what the benefit might have been.


 


Here is the actual code I changed to make my child windows not be cut off anymore:


if( hWndOld != NULL && bOldWasMaximized )

                {

                    ::SetWindowPos(

                        hWndNew, NULL, 0, 0, 0, 0,

                        SWP_NOACTIVATE|SWP_NOMOVE|SWP_NOSIZE

                            |SWP_NOZORDER|SWP_NOOWNERZORDER

                            |SWP_FRAMECHANGED

                        );


 


//If you comment out these 3 lines, all is well. Keeping them in causes the bottom of the child windows to be cut off:

        //            CRect rcClient;

        //            ::GetClientRect( hWndMdiClient, &rcClient );

        //            ::PostMessage( hWndMdiClient, WM_SIZE, SIZE_RESTORED, MAKELPARAM( rcClient.Width(), rcClient.Height() ) );


                }


 


Can you please explain why your change was made? I really don’t want to be off the upgrade path but I don’t want to have to make this change every time you come out with a new version. Any reason you guys can’t revet back to the 2.83 implementation of this part of the code?

Krustys Donuts Feb 2, 2009 - 1:15 PM

Unfortunately I can’t now as I’m under the gun for a deadline. But I can describe more precisely what I have. If you give me an email address I can also provide screenshots.


At the bottom of the screen is a docking window that’s present always. When the user clicks File->New, they get a new child dialog that consists of a page container (much like the custom-drawn page container in your PageContainer sample) with 4 "chevrons." This page container pop up fully maximized, so the bottom of its window butts up against the top of the docking window on the bottom of the screen. The 2nd chevron is open by default, the other 3 are closed.


When the window first paints, it look correct for a split second. But then it seems like the tab for the dialog is added late. When the tab is added, the entire dialog shift down by approximately the height of the tab itself, leaving the bottom chevron cut off. If I then try reisizing the main window, the bottom-most docking toolbar, or anything, everything suddenly works. It’s like one extra paint message would do it.


 


Thanks.

Technical Support Feb 4, 2009 - 1:20 AM

Definitively some screenshots will be helpful. Please send us an e-mail to the support mail box at this web site.

Technical Support Feb 1, 2009 - 11:46 AM

The WM_SIZE message sent to the MDI client area window in the commented lines is required for re-computing MDI child frame layout. The difference between 2.83 and 2.84 is that the latter introduces new theming code for MDI child frame windows and implements most of the MDI interface functions. For instance, even window tiling and cascading is performed by Prof-UIS. We tried to fix the problems with themed MDI child frame windows several releases ago but persistently encountered the situations when default looking window captions were painted over themed MDI child frame window captions. As a result, we coded the standard MDI interface mostly from scratch in v.2.84.

We need your help in reproducing the problem with incorrectly layouted tabs. Could we ask you to modify the TabPages sample so that we can reproduce this problem and send it to us?