Forum

Is it possible to change the size of a contol bar at runtime by program?

Thanks

 

Dear Support,

I will like to have a static control that will have a line completing it, much like the one described here:

http://www.codeproject.com/KB/static/cseparator.aspx#@lt;/p>

Or here:

http://www.codeproject.com/KB/static/groupline.aspx#@lt;/p>

For implementing this, I need to draw a line, but of-course I need it to be themed with the current Prof-UIS theme.

What function can I use?

Thanks,

Ron.

Here is how your code should look like:

#if (!defined __EXT_MEMORY_DC_H)
            #include <../Src/ExtMemoryDC.h>
#endif

void CYourClass::OnPaint() 
{
CPaintDC dcPaint( this );
CRect rcClient;
            GetClientRect( &rcClient );
            if( rcClient.IsRectEmpty() )
                        return;
CExtMemoryDC dc( pDC, &rcClient );
bool bDrawDefaultBackground = true;
            if( g_PaintManager->GetCb2DbTransparentMode(this) && g_PaintManager->PaintDockerBkgnd( true, dc, this ) )
                        bDrawDefaultBackground = false;
            if( bDrawDefaultBackground )
                        dc.FillSolidRect( &rcClient, g_PaintManager->GetColor( CExtPaintManager::CLR_3DFACE_OUT, this ) );  
            //
            // Themed background is ready. Draw your control over it here.
            //
}

BOOL CYourClass::OnEraseBkgnd( CDC * pDC ) 
{
            pDC;
            return TRUE;
}

I also need to draw themed text - how do I do this?

You should draw text using the classic MFC’s CDC::DrawText() or Win32 ::DrawText() API and the g_PaintManager->GetColor( CExtPaintManager::CLR_TEXT_OUT, NULL ) text color.

I think you did not understand what I asked... I need to draw a separator line in the themed style, not only the back-ground.

I understand the code you provided above draws the control in the color of the background, but how do I add the themed line onto it?

Thanks,

Ron.

You should invoke the g_PaintManager->PaintSeparator( . . . ) code. Here is the declaration of the CExtPaintManager::PaintSeparator() virtual method:

virtual void PaintSeparator(
            CDC & dc,
            const RECT & rectItem,
            bool bHorz,
            bool bTransparentBk,
            CObject * pHelperSrc,
            LPARAM lParam = 0L
            );

Hi,

This code does not compile - in

CExtMemoryDC dc( pDC, &rcClient );

The pDC is not defined anywhere in the function.

I tried to replace it with &dcPaint, but I don’t see any line (it does not draw anything)

Please note that I am using it in a dialog.

Thanks,

Ron.

Dear Support,

After swithcing from CMDIChildWnd to CExtNCW<CMDIChildWnd>, we encountered many performance issues.

We inverstigated them and found that if we use CMDIChildWnd, when creating a new maximized view, OnSize is called 6 time (once with cx=cy0=0, and 5 more times).

But, if we create a view with CExtNCW<CMDIChildWnd> OnSizeis called 14(!) times.

The problem is that inside OnSize we do a lot of computation, assuming that this function is called only when needed, that is not 14 times in a row!

More then this, we see that if we change the title of the child frame, OnSize is called twice, which causes our view to flicker. When the title is change in the normal CMDIChildWnd, this does not happen.(all we do is add * to the title when the data in the view was modified...)

In general, we decided to remove this feature for now, as it seems to be immature. Please let us know when these performance issues are going to be solved, as it affect the overall look & feel of our systems.

If anybody else has encountered these issues, please let the support know... I’m sure we’re not alone.

Regards,

Ron.

There are two interesting for you messages defined in Win32 Platform SDK: WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE. The CExtNCW template class supports them. So you can handle the WM_EXITSIZEMOVE message independently from whether the window non client area is themed by Prof-UIS. These two messages are related to any resizable windows, not only to MDI child frames.

Dear Support,

From my checks, it seems that these messages are sent only when the user resizes and moves the window around, not when a new window is created, or when the mamimize/minimize/restore commands are passed to the window.

My most problematic scenario is the new frame, then I get the 14 WM_SIZE messages, without knowing which one is the last one.

Do you know of any solution foer this problem?

Many thanks,

Ron.

Thanks - will explore these messages.

The standard MDI interface is the most broken part of Windows UI. If you didn’t notice yet, all the Microsoft’s applications released last several years do not use the standard MDI interface. The WM_SIZE message is received several times because Prof-UIS sends it explicitly when the state of MDI interfaces needs to be updated.

Is there any way that I will be able to know when the resizing ended? I don’t want to recalculate 14 times, I need to recalculate once when the view has finally arrived at its final size.

Thanks,

Ron.

My application uses luna blue theme like the ProfStudio sample.

I notice that message boxes in ProfStudio sample are luna blue themed but are not in my application.  How can I make them themed in my app?

 

Thanks

If you use 2.84, add

    IMPLEMENT_CWinAPP_DoMessageBox;

to your CWinApp derived class.

Thank you, the correct solution is to add IMPLEMENT_CWinAPP_DoMessageBox as I am using 2.84.  I now have themed message boxes.

 

On the subject of Manifest files.  In VS2005 and VS2008 the manifest file would be added under project Properties\Manifest Tool\Additional Manifest Files...  Might want to specify this in in your FAQ.

I need to destroy a window that i put into CExtControlBar when user hides the corresponding CExtControlBar-object (with a cross in the upper-right corner). Alternately I need to create my window when user shows the corresponding CExtControlBar-object.
I want to do these actions because my windows perform some heavy calculations and I don’t want them to work when they are not on the screen.
I’ve tried to override OnControlBarPositionChange function but it doesn’t trigger on cross button.
I’ve also tried to catch WM_SYSCOMMAND message (with wParam == SC_CLOSE) but it doesn’t come.
I’ve tried WM_WINDOWSPOSCHANGED notification with SWP_HIDEWINDOW flag. It triggers correctly but it also triggers when CExtControlBar-object is to dock to some side. And I don’t want to destroy my window in such cases because i need to create it in a moment after destroying.

Is there a good solution for my problem?

You are using MFC and Prof-UIS from the non-MFC EXE application. This means you DLL module which used Prof-UIS should be the MFC regular DLL project type. If you are using Prof-UIS in the MFC regular DLL project, then you should use the RDE version of Prof-UIS which requires invocation of the CExt_ProfUIS_ModuleState::InitExtension() method:

http://www.prof-uis.com/prof-uis/tech-support/faq/miscellaneous.aspx#how-to-use-prof-uis-in-my-dll-project

The second important thing is very specific for the non-EXE MFC UI which does not control the thread message loop and, as result, the MFC idle processing mechanism is not invoked. The MFC frame windows and control bars inside them, including Prof-UIS control bars, often use delayed layout recalculation based on the CFrameWnd::DelayRecalcLayout() method. The control bars often do position changing, window showing and hiding for more than one control bar window at once. It’s not effective and not flicker free to do window position and visibility changing for each control bar immediately. So, control bars just remember how they should change their positions and visibility and delay the frame layout recalculation. When the thread message loop in the MFC based EXE becomes idle, the CFrameWnd::OnIdleUpdateCmdUI() method is invoked. This method analyzes whether some control bars delayed their position and visibility changing and invokes the CFrameWnd::RecalcLayout() method for applying all the delayed actions. But the MFC regular DLL modules typically does not control the thread message loop, they does not known when the thread becomes idle and, as result, the frame windows in such DLLs does not have any chances for invoking any algorithms based on the MFC’s idle time processing. This is related to both delayed layout computations for control bars and delayed CCmdUI-based command updating for visible UI elements. We guess that’s why some of the control bars present in your frame window does not finalize their layout changing after particular user actions. There are two solutions of this problem. If you have some idle thread state detection mechanism in your main Win32 EXE module, then you should notify the frame window in your MFC regular DLL about idle time events and this DLL should invoke the frame’s CFrameWnd::OnIdleUpdateCmdUI() method. If the idle time detection is not available in your main EXE module, then you can run some timer each 100 milliseconds in your frame window and invoke the frame’s CFrameWnd::OnIdleUpdateCmdUI() method from the timer’s handler method. The last approach is used in our Frame Features ActiveX control which is MFC regular DLL with Prof-UIS/ProfAuto/RDE modules applied and running inside Visual Basic 6.0, Visual J++ and .NET based applications.

That helped. Thank you very much!

Hello!

That’s a good solution, thanks. But while experimenting with CExtDynamicControlBar I’ve found virtual methods that will be enough to override to get the functionality I want. (Actually I’ve overridden two methods: BarStateSet in CExtDynamicControlBar and NcButtons_HandleClick in CExtDynamicTabbedControlBar (by the way this method is always called twice and that made me do some cheats to handle it correctly) )

Unfortunately I’ve encountered a couple of other problems. They are rather difficult to explain and i’ve made some screenshots to make it more obvious.

Problem 1.

1. I have 2 windows: one is docked and one is floating

Docked window is single (is an instance of a class CExtDynamicControlBar, but not of a class CExtDynamicTabbedControlBar)

2. I drag floating window to be tabbed to a docked one like this:


3. Then I expect CExtDynamicControlBar to be created and two windows to be tabbed but i have just this:


4. After resizing of main frame everything comes all right:


This stuff happens only when one window is docked and another floating window is dragged to be tabbed.


Problem 2.
1. I have floating CExtDynamicTabbedControlBar container with 2 windows in it


2. Click on cross button once (I have CExtControlBar::g_bCloseOnlyOneBarInTabGroup = true;)


3. Clicking on cross button again i expect the window to be closed, but I see this:

Everything OK but the container is still visible.

4. After an attempt to dock the container disappears.




I should mention the structure of my project.

I’ve got pure WinAPI (not MFC) exe-file. This project uses MFC-dll in witch I store all the user interface code. This MFC-dll deals with Prof-UIS dll.

I suppose the problem is in bad initialization of all that stuff. When used in a simple mfc exe application Prof-UIS doesn’t have this bug.

Hi,

We discussed it in the past, you said you will come with a solution, but nothing so far.

When placing dialogs inside tab control, it looks very ugly in the location that the dialog and the tab control meet, as seem below.

Is there anything you can do to make this look better?

Thanks,

Ron.

 

We didn’t forget this. Implementation of this feature is delayed due to higher priority tasks.

Please provide us with time-table to when this is to be fixed - we are waiting for a long time.

Dear Support,

We are having problems with group-box hiding controls.

We know how to prevent it from happening, by changing the tab order, however, we have problem with custrom controls:

We have a custom control that creates at run time an edit-box inside it, and this edit-box is not visible if the custom-control is inside the group-box. If we remove the group-box we see the edit-box properly.

How can we solve this problem?

Thanks,

Ron.

This conversation with you is like many of our other conversations with you. We still need more details. For instance, the ProfUIS_Controls sample application contains the Tab Containers dialog page. This dialog page contains two tab page container controls which can be assumed as something similar to your custom control. These tab page containers have several child windows inserted into them as pages. They contain dialog pages with two edit controls. These dialog pages contain correctly displayed edit controls. We promise you we did not do anything special in Prof-UIS to let these edit controls be displayed correctly.

It’s possible to remove group boxes and handle the dialog’s WM_PAINT messages manually like the CExtWS::WindowProc() method does. Such WM_PAINT message handler should draw dialog background using Prof-UIS paint manager and then draw something group box like looking over the background.

This custom control should have the WS_CHILD|WS_VISIBLE styles. The edit box should be created as a child of your custom control window. It should not try to create this edit as a child of your dialog. But if it does so, then please change editors Z-order and place it after your custom control. Please check this.

Hello.

On the Office2007 theme, Ribbon works without a problem.

However, on the theme before it, Ribbon does not work normally.

http://www.prof-uis.com/prof-uis/tech-support/support-forum/please-answer-it-63555.aspx

CExtResizableDialog doesn’t allow the dialog to be sized smaller than the original size in the dialog resource.

We design our dialogs to have an "optimal" size when initially opened.  But this is only occasionally smallest allowable size.  It would be useful to have a way to override the limitation or to specify a minimal size.

We have the class hierarchy for that.

Hi,

I have a tree with two columns. Sometimes when resizing the dialog, which resizes the tree inside (using anchors) the application crashes deep inside Prof-UIS. This only happens when making the window higher. This is the stack:

>    ProfUIS284md.dll!CExtTreeGridDataProvider::_Tree_MapRowToCache(unsigned long nRowNo=13)  Line 2273    C++
	 ProfUIS284md.dll!CExtTreeGridDataProvider::_Tree_NodeGetByVisibleRowIndex(unsigned long nRowNo=14)  Line 936 + 0x16 bytes    C++
	 ProfUIS284md.dll!CExtTreeGridDataProvider::TreeNodeGetByVisibleRowIndex(unsigned long nRowNo=14)  Line 921 + 0x16 bytes    C++
	 ProfUIS284md.dll!CExtTreeGridWnd::ItemGetByVisibleRowIndex(long nRowNo=14)  Line 3109 + 0xc bytes    C++
	 ProfUIS284md.dll!CExtTreeGridWnd::OnSiwQueryItemExtentV(long nRowNo=13, int * p_nExtraSpaceBefore=0x00000000, int * p_nExtraSpaceAfter=0x00000000)  Line 5121 + 0x16 bytes    C++
	 ProfUIS284md.dll!CExtGridBaseWnd::OnSiwCalcPageMetrics(int nDirection=0)  Line 7152 + 0x1d bytes    C++
	 ProfUIS284md.dll!CExtScrollItemWnd::OnSiwGetVisibleRange()  Line 6546 + 0x18 bytes    C++
	 ProfUIS284md.dll!CExtGridBaseWnd::OnGbwWalkVisibleAreas(CDC & dc={...}, bool bFocusedControl=false, CExtGridHitTestInfo * pHT=0x00000000)  Line 2582 + 0x16 bytes    C++
	 ProfUIS284md.dll!CExtGridBaseWnd::OnSiwPaintForeground(CDC & dc={...}, bool bFocusedControl=false)  Line 2169 + 0x1c bytes    C++
	 ProfUIS284md.dll!CExtScrollItemWnd::OnSwPaint(CDC & dc={...})  Line 6080 + 0x1a bytes    C++
	 ProfUIS284md.dll!CExtScrollWnd::OnPaint()  Line 4240 + 0x19 bytes    C++
	 mfc80d.dll!CWnd::OnWndMsg(unsigned int message=15, unsigned int wParam=0, long lParam=0, long * pResult=0x00125a0c)  Line 2028    C++
	 mfc80d.dll!CWnd::WindowProc(unsigned int message=15, unsigned int wParam=0, long lParam=0)  Line 1741 + 0x20 bytes    C++
	 ProfUIS284md.dll!CExtScrollWnd::WindowProc(unsigned int message=15, unsigned int wParam=0, long lParam=0)  Line 4312    C++
	 ProfUIS284md.dll!CExtGridBaseWnd::WindowProc(unsigned int message=15, unsigned int wParam=0, long lParam=0)  Line 12775    C++

In this function:

ULONG CExtTreeGridDataProvider::_Tree_MapRowToCache( ULONG nRowNo ) const
{
    ASSERT_VALID( this );
const CExtGridDataProvider & _DP = _Tree_GetCacheDP();
ULONG nReservedRowCount = 0;
     _DP.CacheReservedCountsGet( NULL, &nReservedRowCount );
ULONG nRowCountReservedForTree = _Tree_ReservedRowsGet();
    ASSERT( nReservedRowCount >= nRowCountReservedForTree );
    nReservedRowCount -= nRowCountReservedForTree;
ULONG nOffset = 0;
    if( nRowNo >= nReservedRowCount )
    {
        nRowNo -= nReservedRowCount;
        ASSERT( nRowNo < ULONG(m_arrGridVis.GetSize()) );
        CExtTreeGridCellNode * pNode = m_arrGridVis.GetAt( nRowNo );
        ASSERT_VALID( pNode );
        nOffset = pNode->TreeNodeCalcOffset( false, true );
        nOffset += nReservedRowCount;
    } // if( nRowNo >= nReservedRowCount )
    else
        nOffset = nRowNo;
    return nOffset + nRowCountReservedForTree;
}

I see that pNode is NULL (8 rows from the bottom)

Please check what causes this bug, and at least how to bypass it, becuase we cannot deliver our product with this bug.

Thanks,

Ron.

It’s very simple. We have several test projects dedicated to the CExtTreeGridWnd class:

http://www.prof-uis.com/download/forums/test_tree_grid_idea.zip
http://www.prof-uis.com/download/forums/test_tree_grid_idea(with-hiding).zip
http://www.prof-uis.com/download/forums/test_tree_grid_idea_dnd.zip
http://www.prof-uis.com/download/forums/test_tree_grid_idea_expanding.zip
http://www.prof-uis.com/download/forums/test_tree_grid_idea_outer.zip
http://www.prof-uis.com/download/forums/TestTreeGridInFloatingBar2.zip
http://www.prof-uis.com/download/forums/TestTreeGridSortingOnHeaderClick.zip

You can use any of them. We want you to describe very exact step by step sequence of actions which with generate the crash. That’s all.

The crazy thing is that this line:

        CExtTreeGridCellNode * pNode = m_arrGridVis.GetAt( nRowNo );

has a velid value in nRowNo (13) when the size of m_arrGridVis is 20, but somehow it inserted a NULL pointer into the array... how can this be?

I have to add that this does not happen in all trees only in a specific one, so it seems that this bug is very tricky - but we must fix it.

So any ideas how you can insert a NULL pointer into this array?

Thanks,

Ron.

This crash looks like memory damage or incorrectly modified internal tree grid’s data. We need your help in reproducing it.

Hi,

I have a maximized application that uses the CExtPaintManagerOffice2007_Silver theme in 2.84.

At some point in time, when I drag another window or even a control bar from that application, the title stops to draw itself, and I see trails of the window I dragged over it. Below is an example when this happens (it happens a lot!) It even looks like the default XP title bar is partialy drawn.

If I double-click the title, it draws properly the title in its new restored size, but if I double click it again, the right side remains in the XP blue title.

Please fix.

Thanks,

Ron.

Dear Support,

When having an application maximized in 2.84 with CExtPaintManagerXP theme, it does not cover the whole window, there is a 10 pixel offset from the top, and the bottom 10 pixels are hidden behind the windows task-bar.

This is the top of the display

It’s not any of the prof-UI demos, but my own application...

Please note that I am using dual view, and each monitor has a different resolution (this is a new setup we use)

Also, in the Office themes this does not happen, only in the XP theme.

We tried to run the MDI sample application on Windows XP Professional English SP3 with two monitors. The left and main monitor is 1600x1200. The secondary right monitor is 1024x768. The state of the main frame window is restored OK on both monitors and in both normal and maximized states. We hope you provide us with more details. We need to know required monitor resolutions, which shell bars are running and visible on your monitors and, exactly they are docked and which of them are using auto hiding.

Hi,

The main monitor is 1600x1200, the second (right) is 1280x1024.

WIn XP SP3 English

My task-bar is the only item on my desk-top, it is two rows high.

I run it without loading the UI state from the registry

All I do is:

    pFrame->ActivateFrame(SW_SHOWMAXIMIZED);

To the main frame (this is an MDI application).

Note again - works fine in 2007 themese (grey/blue/black) does not work fine in XP theme.

We modified the MDI sample application for testing this issue:

http://www.prof-uis.com/download/forums/tmp/ForRon-TestingMaximize.zip

We replaced the following line in the CMDIApp::InitInstance() method:

pFrame->ActivateFrame( m_nCmdShow );

With the following line:

pFrame->ActivateFrame( SW_SHOWMAXIMIZED );

We completely removed the CMainFrame::m_dataFrameWP property and all its usages (replaced with NULL its usage as method parameter). We removed the CMainFrame::ActivateFrame() virtual method.
Then we run this modified MDI sample application from the Windows Explorer. It starts maximized on the desktop which is closest to the location of the Windows Explorer’s window. The location of the main frame window is the correct location of the correctly maximized window. So, we need more details. Which desktop theme is used on your computer and which DPI setting is set? What do we need to modify additionally in the source code of the MDI sample application to make it reproducing this issue?

We modified the MDI sample application for testing this issue:

http://www.prof-uis.com/download/forums/tmp/ForRon-TestingMaximize.zip

We replaced the following line in the CMDIApp::InitInstance() method:

pFrame->ActivateFrame( m_nCmdShow );

With the following line:

pFrame->ActivateFrame( SW_SHOWMAXIMIZED );

We completely removed the CMainFrame::m_dataFrameWP property and all its usages (replaced with NULL its usage as method parameter). We removed the CMainFrame::ActivateFrame() virtual method.
Then we run this modified MDI sample application from the Windows Explorer. It starts maximized on the desktop which is closest to the location of the Windows Explorer’s window. The location of the main frame window is the correct location of the correctly maximized window. So, we need more details. Which desktop theme is used on your computer and which DPI setting is set? What do we need to modify additionally in the source code of the MDI sample application to make it reproducing this issue?

Dear Support,

I cannot reproduce it in ther MDI application, however, something is definently not right for me in the XP theme.

Can you please point me to where you put the size of the main-frame, so that I will be able to debug my application to get to the root of this problem?

Thanks,

Ron.

Because the XP theme has so many problems, we decided to not use it for now, as we don’t have time to figure out what is the problem with the maximize mode in this theme.

Hi,

i have the same problem. My monitor is 1680 x 1050, Win XP SP2 german. When is swich your MDI sample application from Office 2007 Theme to XP theme, than there are 10 pixel offset a top. When i then minimized and after that maximed the application, then it’s ok. But when you then switch back to Office 2007 theme there are now 10 pixel missing on every side.

Ulrich

Hi Ulrich,

Did you find any solution to this problem?

Thanks,

Ron.

Hi Ron,

i have no time to fix this problem in the moment. Hopefully the support find a solution.

Ulrich

Dear Support,

I use the CExtPaintManagerXP theme, I have several combo-boxes, when drawing an owner-drawn combo-box they are displayed in the normal XP style, not in the theme I choose. When I hover over them, it seems that Prof-UIS draws them, but immediately after the OS draws them again, causing an annoying flicker.

This is an example of 4 combo-boxes, 2 are normal, and 2 are ownder drawn:

Please fix.

Thanks,

Ron.

Thank you for reporting this issue. We have fixed it in the following method:

void CExtComboBox::OnPaint()
{
            if( ( GetExStyle() & (WS_EX_DLGMODALFRAME|WS_EX_CLIENTEDGE|WS_EX_STATICEDGE) ) != 0 )
                        ModifyStyleEx( WS_EX_DLGMODALFRAME|WS_EX_CLIENTEDGE|WS_EX_STATICEDGE, 0, SWP_FRAMECHANGED );
COLORREF clrFillClientArea = COLORREF(-1L);
DWORD dwStyle = GetStyle();
CPaintDC dcPaint( this );
            CExtPaintManager::stat_ExcludeChildAreas( dcPaint.GetSafeHdc(), GetSafeHwnd() );
CRect rcClient;
            GetClientRect( &rcClient );
CExtMemoryDC dc( &dcPaint, &rcClient );
CRgn _rgn;
            if( ( dwStyle & ( CBS_OWNERDRAWFIXED|CBS_OWNERDRAWVARIABLE ) ) != 0 )
            {
                        CRect rcRgn = rcClient;
                        rcRgn.right -= ::GetSystemMetrics( SM_CXVSCROLL );
                        if( _rgn.CreateRectRgnIndirect( &rcRgn ) )
                                    dc.SelectClipRgn( &_rgn );
            }
            DefWindowProc( WM_PAINT, (WPARAM)dc.GetSafeHdc(), (LPARAM)0 );
            if( _rgn.GetSafeHandle() != NULL )
                        dc.SelectClipRgn( NULL );
            if(                     (dwStyle&CBS_SIMPLE) == CBS_SIMPLE 
                        &&        (dwStyle&CBS_DROPDOWN) != CBS_DROPDOWN
                        &&        (dwStyle&CBS_DROPDOWNLIST) != CBS_DROPDOWNLIST
                        )
            {
                        if(                     (! PmBridge_GetPM()->GetCb2DbTransparentMode(this) )
                                    ||           (! PmBridge_GetPM()->PaintDockerBkgnd( true, dc, this ) )
                                    )
                                    clrFillClientArea = PmBridge_GetPM()->GetColor( CExtPaintManager::CLR_3DFACE_OUT, this );
            }
            if( clrFillClientArea != COLORREF(-1L) )
                        dc.FillSolidRect( &rcClient, clrFillClientArea );
            _OnDrawComboImpl( GetDroppedState() ? true : false, IsHovered(), &dc );
}

Dear Support,

I dock two dialogs side by side, on the bottom of the main frame, and drag the border between them so the left’s one is aporx. 25% of the common width, and the right one get aprox. 75% of the common width:

+-----------------------------------------+
|										 |
|										 |
|										 |
|										 |
|										 |
+---------------------------+-------------+
|						   |			 |
|						   |			 |
+---------------------------+-------------+

When I exit and re-run the application, the 2 dialogs are docked at the bottom, but each one get 50% of the common width - it did not remember the different width I gave each one of the dialogs:

+-----------------------------------------+
|										 |
|										 |
|										 |
|										 |
|										 |
+--------------------+--------------------+
|				    |				    |
|				    |				    |
+--------------------+--------------------+

Please fix.

Thanks,

Ron.

Well... the preview does not look like the submitted post... but I hope you understand the problem.

Please show the source code you used for docking control bars side by side.

If you compile and run the MDI sample application, then you will see the Bar 1 and Bar 3 bars at the bottom side of the main frame window. You can re-dock them into one row or column and change their mutually dependent sizes. The sizes are restored after restarting this sample application. The following part of the CMainFrame::OnCreate() method in this sample application is responsible for initial bar docking and loading bar states:

   if(         ! CExtControlBar::ProfileBarStateLoad(
                                    this,
                                    pApp->m_pszRegistryKey,
                                    pApp->m_pszProfileName,
                                    pApp->m_pszProfileName,
                                    &m_dataFrameWP
                                    )
                        )
            {
                        DockControlBar(&m_wndMenuBar);
                        DockControlBar(&m_wndToolBar);
                        DockControlBar(&m_wndToolBarUiLook,AFX_IDW_DOCKBAR_RIGHT);
                        m_wndResizableBar0.SetInitDesiredSizeVertical( CSize(80,80) );
                        m_wndResizableBar1.SetInitDesiredSizeHorizontal( CSize(80,80) );
                        m_wndResizableBar2.SetInitDesiredSizeVertical( CSize(80,80) );
                        m_wndResizableBar3.SetInitDesiredSizeHorizontal( CSize(80,80) );
                        m_wndResizableBar4.SetInitDesiredSizeVertical( CSize(80,80) );
                        m_wndResizableBar0.DockControlBar(AFX_IDW_DOCKBAR_LEFT,1,this,false);
                        m_wndResizableBar1.DockControlBar(AFX_IDW_DOCKBAR_BOTTOM,2,this,false);
                        m_wndResizableBar2.DockControlBar(AFX_IDW_DOCKBAR_LEFT,3,this,false);
                        m_wndResizableBar3.DockControlBar(AFX_IDW_DOCKBAR_BOTTOM,4,this,false);
                        m_wndResizableBar4.DockControlBar(AFX_IDW_DOCKBAR_LEFT,5,this,false);
                        m_wndResizableBarTA.DockControlBar(AFX_IDW_DOCKBAR_RIGHT,1,this,false);
                        RecalcLayout();
            }

We can modify this code snippet and replace the following line:

m_wndResizableBar2.DockControlBar(AFX_IDW_DOCKBAR_LEFT,3,this,false);

With the following code:

RecalcLayout();
m_wndResizableBar3.DockControlBarLTRB(&m_wndResizableBar1,AFX_IDW_DOCKBAR_RIGHT,true); 

After removing the HKEY_CURRENT_USER\Software\Foss\MDI registry key and restarting the sample application you will see two bars programmatically docked into one row at the bottom side of the main frame window. You can change their sizes and they will be restored OK.

Dear Support,

I do not dock them side-by-side in the code, but at run time.

My assumption was that this setting will be saved, and when I re-load the application, the layout, and the size each bar occupies will be remembered.

Insead, when I re-load the application, each bar gets 50% instead of the setting it had before it was closed.

 

We are sorry but could you provide some step by step description of what we should do in the MDI sample application to reproduce this issue?

I am sending you an example from the MDI application via mail.

We successfully reproduced this problem. We found only temporarily and experimental solution to this problem. To try it please find the CExtControlBar::InternalDockStateSite::StateSet() method in the .../Prof-UIS/Src/ExtControlBar.cpp file. You can see the if( bPresetWP ) { . . . } conditional code statement at the at the beginning of this method. Please replace it with the following:

 if( bPresetWP )
      {
            CRect rcDockSiteWnd;
            if(         m_wp.showCmd == SW_SHOWMAXIMIZED
                  ||    m_wp.showCmd == SW_SHOWMINIMIZED
                  ||    m_wp.showCmd == SW_SHOWMINNOACTIVE
                  ||    m_wp.showCmd == SW_HIDE
                  ||    m_wp.showCmd == SW_FORCEMINIMIZE
                  )
            {
                  CExtPaintManager::monitor_parms_t _mp;
                  CExtPaintManager::stat_GetMonitorParms( _mp, m_wp.rcNormalPosition );
                  rcDockSiteWnd = _mp.m_rcWorkArea;
            }
            else
                  rcDockSiteWnd =  m_wp.rcNormalPosition;
            CWnd * pWndPlacement = CExtControlBar::stat_GetWndForPlacement( m_pDockSite );
            ASSERT_VALID( pWndPlacement );
            if( pWndPlacement != m_pDockSite )
                  m_pDockSite->SetWindowPos(
                        NULL, 0, 0, rcDockSiteWnd.Width(), rcDockSiteWnd.Height(),
                        SWP_NOZORDER|SWP_NOOWNERZORDER|SWP_NOACTIVATE|SWP_NOMOVE|SWP_NOREDRAW // |SWP_NOSENDCHANGING 
                        );
            pWndPlacement->SetWindowPlacement( &m_wp ); // THIS IS THE REALLY IMPORTANT LINE AND IT DOES FIX
      } // if( bPresetWP )

Now the problem with the size of restored bars is gone. But another new problem is potentially appeared. The code snipped above is invoked when the CMainFrame::OnCreate() method invokes the CExtControlBar::ProfileBarStateLoad() static method for loading bar states and WINDOWPLACEMENT data structure that is used later in the CMainFrame::ActivateFrame() virtual method. So, previously the placement of the main frame window was restored in the CMainFrame::ActivateFrame() virtual method which is typically invoked after complete UI initialization. But now, after the experimental fix listed above is applied, the placement of the main frame window is invoked inside the CExtControlBar::ProfileBarStateLoad() static method and the CMainFrame::OnCreate() method do some final UI initialization after restoring bars. This may be not good for some applications which have long and heavy UI initialization and does not expect the main frame window to appear on the screen before the CMainFrame::ActivateFrame() virtual method is invoked. What we need is the Win32 API similar to the SetWindowPlacement() API but not displaying window on the screen. Very unfortunately, we don’t know such API.

In fact, the fix provided above is the same as manual loading of the main frame’s window placement before loading bar states.

Hi,

the classes CExtGridCellFolder and CExtGridCellFile now using the new ShellControls. My question is how i can customize these ShellControls to show for example german texts.

Ulrich

 

Hello.

I stick a dialog on ContorlBar

A domain does not accord.

I want to match a dialogue with the size of the bar.

Please teach a method.

Hello.

I want to receive only specific ID by a command message in PostMessage

I am derived in CExtBarButton, and is it necessary to improve it?

void CExtBarButton::OnDeliverCmd()

{

    :

    :

    :

    pCmdItem->Deliver(

        pBar,

        true  <--- false

        );

}

I’m using a CExtTabPageContainerWnd with CExtNCW<CExtResizableDialog> pages.  When the containing dialog (also (CExtNCW<CExtResizableDialog>) initially opens, the tab only shows the current page (grayed out)

 As soon as the mouse moves over the tab area it displays correctly.  And THIS is wierd: if I move the mouse to the title are of the containing dialog, just left of the close button, the appearance switches back to the single grayed tab.  I’ve tried setting all kinds of stuff with no luck.

BOOL CDlgPrefs::OnInitDialog() 
{
 CExtNCW<CExtResizableDialog>::OnInitDialog();
 if ((m_dlgBdCd.Create( IDD_PREFS_BDCD,  &m_wndTab) == FALSE)
   ||(m_dlgCvt.Create( IDD_PREFS_CVT,  &m_wndTab) == FALSE)
   ||(m_dlgDwg.Create( IDD_PREFS_DRAWING, &m_wndTab) == FALSE)
   ||(m_dlgGen.Create( IDD_PREFS_GEN,  &m_wndTab) == FALSE)
   ||(m_dlgPrt.Create( IDD_PREFS_PRT,  &m_wndTab) == FALSE)
   ||(m_dlgXHair.Create( IDD_PREFS_CLOSEUP, &m_wndTab) == FALSE))
 {
  TRACE0("Failed to create dialogs\n");
  return -1;  // fail to create
 }
 VERIFY(m_wndTab.PageInsert(&m_dlgDwg, _T("Drawing")));
 VERIFY(m_wndTab.PageInsert(&m_dlgXHair, _T("Close-up")));
 VERIFY(m_wndTab.PageInsert(&m_dlgGen, _T("General")));
 VERIFY(m_wndTab.PageInsert(&m_dlgCvt, _T("Conversion")));
 VERIFY(m_wndTab.PageInsert(&m_dlgPrt, _T("Printing")));
 VERIFY(m_wndTab.PageInsert(&m_dlgBdCd, _T("Bid Codes")));
 m_wndTab.AutoHideScrollSet(true);
 m_wndTab.CenterTextSet(true);
 m_wndTab.FullWidthSet(true);
 m_wndTab.SelectionBoldSet(true);
 m_wndTab.OrientationSet(__ETWS_ORIENT_TOP);
 m_wndTab.ShowBtnCloseSet(false);
 m_wndTab.ShowBtnHelpSet(false);
 m_wndTab.ShowBtnTabListSet(false);
 m_wndTab.PageSelectionSet(2);
 return (TRUE);
}

All the code after the PageInsert commands are stuff I added trying to fix this.  I also tried Invalidating the tab control and the containing dialog.

We think you can use the following dialog as a property sheet window:

http://www.prof-uis.com/download/forums/TestTabPageContainerInDialog.zip

Could you please send us a screenshot demonstrating the incorrectly looking tab page container window?

os : vista

tools : visual studio 2008

 

i orderd Prof-UIS v2.84 ...

but, i don’t receive email for download..

where is file?

where is license key ??

 

 

Hello.

When I clicked a menu , I want to display the dialogue in top-level.