Forum

Hi,
When I press the alt key in some circumstances I get numbers appearing at the top of my ribbonBar. I assume this is default behaviour that allows access to the shortcut icons via the keyboard.

This would be useful if it were consistent throughout the application, but it is not. Can you tell me the circumstances in which it should happen?

Could you also tell me how to disable it.

Thanks

This is interesting as my CMainFrame did not have PreTranslateMessage overridden. If I put in code similar to yours (without the commenting out) the key tip mode is much more consistent, working 90% of the time.

I now have 2 ways to go:
1. Get key tip mode working consistently, recreate the crash seen by my users & fix it.

2. Stop key tip mode completely.

I would prefer option 1, and your help has got me a long way towards it.

With my auto hidden bars, if I move over their tab to temporarily display the window then click on the title bar, the title bar highlights then the alt key no longer starts key tip mode (with the exception of the first autohidden bar).
Can you suggest how this can be corrected?

I am also a little concerned that if I have this code missing I may have other code missing. I started using prof-UIS at v2.62 and my app was originally based on the RibbonBar example. I presume this extra code was added to support updates in prof-UIS since v2.62. If so, is there any other code I need to ensure is there?

My problem is that ’key tip mode’ is not consistent.
Most of the time, pressing ALT appears to do nothing at all (the ribbon bar and shortcut keys are always displayed).
However, I have had reports of other behaviour from users:
After pressing CExtButtons on one autohiding dialog, pressing ALT enters what I now think is ’key tip mode’.
Other users have reported ALT causing crashes.

What I would like from you is to know:
a) how to suppress ’key tip mode’ in the code.
b) how to trap ’key tip mode’ in the code (in a way similar to using OnConstructPopupMenuCB to trap & suppress inbuilt popups)

The key tip mode in the ribbon bar works exactly like the keyboard activation in the menu bar except for popup key tip windows which are displayed in the ribbon bar. So it is really weird that your customers have the problems with that. If you help us reproduce the problem in some way, we will certainly fix it. You can suppress key tips by not pretranslating messages for the ribbon bar in the main frame, e.g.:

BOOL CMainFrame::PreTranslateMessage(MSG* pMsg) 
{
	if( m_wndToolBarUiLook.PreTranslateMessage( pMsg ) )
		return TRUE;
//	if( m_wndRibbonBar.TranslateMainFrameMessage(pMsg) )
//		return TRUE;
	return CExtNCW < CFrameWnd > :: PreTranslateMessage(pMsg);
}

I am using a CExtReportGridWnd..

1) I am setting up a 2 column grid, but I can’t seem to get the column widths to be 25% and 75% (the displayed grid is more like 95% and 5%)
    
CExtReportGridColumn* columns[2]={
m_grid.ReportColumnRegister(_T("Color"), _T("Category")),
m_grid.ReportColumnRegister(_T("Survey Line"), _T("Category"))};

m_grid.BseModifyStyleEx(__EGBS_BSE_EX_PROPORTIONAL_COLUMN_WIDTHS,0);

columns[0]->ExtentPercentSet(0.25) ;
columns[1]->ExtentPercentSet(0.75) ;
columns[0]->SortingEnabledSet(false);
columns[1]->SortingEnabledSet(false);
columns[0]->DragDropEnabledSet(false);
columns[1]->DragDropEnabledSet(false);


2) Is there a way to remove the column headers so that just the data cells are displayed?

Dear Support,

In your ReportGrid sample, the grid is filled during initialization, so ReportGridStateLoad is called after the ReportItemRegister calls. If in the registry any of the columns are set to an alignment different from the default, ReportGridStateLoad sets the cells of that column accordingly.

In our application, the grid is filled from a file, during application run, so we need to call ReportSortOrderUpdate after the grid is filled with lines. I read in Help file, that ReportSortOrderUpdate updates the "content according to the current sorting and grouping rules". But column Alignment is not updated, so if user changes the default alignment of any of the columns, filling the grid in runtime causes that only the column header cell is with the appropiate alignment, but not the inner cells. Could ReportSortOrderUpdate set proper alignment as well?

Thank you!

The following code adjusts alignment for a column:

CExtReportGridWnd * pRGW = . . .
CExtReportGridColumn * pRGC = . . .
DWORD dwAlignment = pRGC->GetStyle()&__EGCS_TA_HORZ_MASK;
pRGW->ReportColumnAdjustTextAlignmentH( pRGC, dwAlignment );

The below code does the same for all columns:

CExtReportGridWnd * pRGW = . . .
POSITION pos = pRGW->ReportColumnGetStartPosition();
      for( ; pos != NULL; )
      {
            CExtReportGridColumn * pRGC = pRGW->ReportColumnGetNext( pos );
            DWORD dwAlignment = pRGC->GetStyle()&__EGCS_TA_HORZ_MASK;
            pRGW->ReportColumnAdjustTextAlignmentH( pRGC, dwAlignment );
      }

We could add some method which does the same for one report item (row) only. So you believe it would be helpful, please let us know.

Dear Support,

In our readonly ReportGrid we have a column which shows Male/Female data as little icons. I used 2 CExtBitmap objects as class variables and CExtGridCellPictureRef cells, for which I set one of these CExtBitmaps with BitmapSetBuffer method. But when the user tries to group by that column, it doesn’t work: every line is grouped as a one-item group, as if every CExtGridCellPictureRef cell had different values.

I need to keep this column "groupable". Please, advise. Since the cells are of PictureRef class, can’t the reportgrid check if the pointers associated with them are the same (they point to the same CExtBitmap)?

Thank you!

If you look at the CExtGridCellPictureBase::Compare() method, you will see that the two bitmaps are compared by their size. If the they have the same size, the two cells are compared in the CExtGridCell::Compare() virtual method where the comparison is performed using VARIANT data types. The VARIANT variable is created in the CExtGridCellPictureBase::GetVariant() virtual method. We would not recommend you change this algorithm. Instead you could create a CExtGridCellPictureRef-derived cell where, in the overridden Compare() virtual method, you could perform your custom comparison using the bitmap pointers.

True, I didn’t step into the code to check why it doesn’t work, but reading your post it seems to me that grouping should work without me having to create any derived classes or override any method. Comparing the pointers was just a suggestion, and I agree with you, I’d prefer not changing your algorithm. Shall I try making a sample application showing the problem?

Ok, I made a sample application (actually just added a dialog to your ThemeColorizer sample, but the dialog itself is really what demonstrates the problem. Downloadable from here) A reportgrid occupies the dialog, in the grid I added 2 columns and 10 lines. First column is CExtGridCellPictureRef-column, second is just a simple CExtGridCellString. The same way as in my own application, I added 2 CExtBitmap objects to the dialog class and one by one, the cells of the first column got associated with one of those 2 pictures using BitmapSetBuffer. Second column was filled with unique strings.

When trying to sort by the first column, the result is not as should be, lines seem to be sorted randomly. And this time I stepped through your code, and as you wrote in your last post, it all boils down to CExtGridCellPictureBase::GetVariant() method. It is called twice from CExtGridCell::Compare(), once for each cell being compared. When those 2 cells have the same picture associated with them, BitmapGetBuffer() inside GetVariant() returns the very same pointer, but the created VARIANT variables still differ!! I think this is a bug, the created VARIANT should be the same!

I’m using ProfUIS v2.64.1 with VS2003 in Static Unicode Debug configuration. If a newer version has an improved CExtGridCellPictureBase::GetVariant(), please, let me know. Thank you!

We have no chance to compare pictures universally. Even if we could compare the content of picture surfaces using some AI algorithms, the pictures would be definitively equal or unequal to each other but not greater or less. In your project, we would not recommend to use CExtGridCellPictureBase-based classes at all. Instead you could register two icons in the report grid window using the CExtGridWnd::GridIconInsert() method and use these icons in the CExtGridCell/CExtGridCellComboBox/CExtGridCellCheckBox objects using the CExtGridCell::IconIndexSet() method. The combo box cell could display Male/Female strings in the popup list box. The check box cell could display the male/female status in the check box.

Sorry, last post went to the wrong thread!

I will go for this icon-solution, situation is even easier in our case as the grid is readonly.

Dear Support,

I’m trying to use the above method, but it doesn’t seem to work. I’ve stepped through its code and I can’t see any code which would assign the new name to the column. Very close to the end of the method, I can see this line:

m_mapColumns.SetAt( pMovingRGC, pMovingRGC );

I guess this line is supposed to assign the new name, but with different second parameter. I’ve tested it with both old and new category names being NULL, old column name being name of an existing column, so pMovingRGC is a valid pointer.

Please, advise! (Using v2.64.1)

This method requires the exact names of categories or NULL if you are going to rename a column only without changing its owner category. Please let us know the exact set of parameters which we should use to test this method. We guess we can easily check any problem with column renaming using the ReportGrid sample.

To reproduce the problem (Column name does not change), change your ReportGrid as so:

1. When Registering "Name" column, change it’s category to NULL in InitReportGridContent:
    ReportColumnRegister(
        _T("Name"),
        NULL,
        bInitiallyActive,
        false
        );

2. I’ve put the testing code in OnRgExportToExcel:
void CChildView::OnRgExportToExcel()
{
    ReportColumnRename(_T("Name"), NULL, _T("Testing ReportColumnRename..."), NULL);
    return;
    ...
}

For the test to reproduce the problem, Registry has to be clean of sample application’s settings.
ReportColumnRename returns true, and stepping through its code I can see that OnSwDoRedraw() is called (When calling OnSwDoRedraw() myself, after ReportColumnRename, result is the same), column name is not changed in column header.

Thank you for your comments. We changed the method signature and body because it logically requires two first parameters to be specified:

      bool ReportColumnRename(
            __EXT_MFC_SAFE_LPCTSTR strColumnNameOld,
            __EXT_MFC_SAFE_LPCTSTR strCategoryNameOld,
            __EXT_MFC_SAFE_LPCTSTR strColumnNameNew = NULL,
            __EXT_MFC_SAFE_LPCTSTR strCategoryNameNew = NULL,
            bool bRedraw = true
            );

bool CExtReportGridWnd::ReportColumnRename(
      __EXT_MFC_SAFE_LPCTSTR strColumnNameOld,
      __EXT_MFC_SAFE_LPCTSTR strCategoryNameOld,
      __EXT_MFC_SAFE_LPCTSTR strColumnNameNew, // = NULL
      __EXT_MFC_SAFE_LPCTSTR strCategoryNameNew, // = NULL
      bool bRedraw // = true
      )
{
      ASSERT_VALID( this );
      if(         strColumnNameOld == NULL
            ||    _tcslen( strColumnNameOld ) == 0
            )
            return false;
      if(         strCategoryNameOld == NULL
            ||    _tcslen( strCategoryNameOld ) == 0
            )
            return false;
      if(         strColumnNameNew == NULL
            ||    _tcslen( strColumnNameNew ) == 0
            )
            strColumnNameNew = strColumnNameOld;
      if(         strCategoryNameNew == NULL
            ||    _tcslen( strCategoryNameNew ) == 0
            )
            strCategoryNameNew = strCategoryNameOld;
LONG nIndex, nCount;
CExtReportGridColumn * pMovingRGC = NULL;
CTypedPtrArray < CPtrArray, CExtReportGridColumn * >
            * pArrCategoryColumns = NULL;
      if( _tcscmp(strCategoryNameNew,strCategoryNameOld) != 0 )
      {
            if(   m_mapColumnCategories.Lookup(
                        strCategoryNameOld,
                        (void*&)pArrCategoryColumns
                        )
                  )
            {
                  ASSERT( pArrCategoryColumns != NULL );
                  nCount = LONG( pArrCategoryColumns->GetSize() );
                  ASSERT( nCount > 0 );
                  if( nCount > 1 )
                  {
                        for( nIndex = 0; nIndex < nCount; nIndex ++ )
                        {
                              CExtReportGridColumn * pRGC =
                                    pArrCategoryColumns->GetAt( nIndex );
                              ASSERT_VALID( pRGC );
                              ASSERT( pRGC->m_pRGW == this );
                              if( _tcscmp(
                                          pRGC->ColumnNameGet(),
                                          strColumnNameOld
                                          ) == 0
                                    )
                              {
                                    pMovingRGC = pRGC;
                                    pArrCategoryColumns->RemoveAt( nIndex );
                                    break;
                              }
                        } // for( nIndex = 0; nIndex < nCount; nIndex ++ )
                        if( pMovingRGC == NULL )
                              return false; // not found
                        ASSERT_VALID( pMovingRGC );
                  } // if( nCount > 1 )
                  else
                  {
                        ASSERT( nCount == 1 );
                        pMovingRGC = pArrCategoryColumns->GetAt( 0 );
                        ASSERT_VALID( pMovingRGC );
                        if(   _tcscmp(
                                    pMovingRGC->ColumnNameGet(),
                                    strColumnNameOld
                                    ) != 0
                              )
                              return false; // not found
                        delete pArrCategoryColumns;
                        m_mapColumnCategories.RemoveKey( strCategoryNameOld );
                        OnReportGridColumnCategoryRemoved( strCategoryNameOld );
                  } // else from if( nCount > 1 )
            }
            ASSERT_VALID( pMovingRGC );
            pArrCategoryColumns = NULL;
            if(   ! m_mapColumnCategories.Lookup(
                        strCategoryNameNew,
                        (void*&)pArrCategoryColumns
                        )
                  )
            {
                  pArrCategoryColumns = new
                        CTypedPtrArray < CPtrArray, CExtReportGridColumn * >;
                  m_mapColumnCategories.SetAt( strCategoryNameNew, pArrCategoryColumns );
                  OnReportGridColumnCategoryAdded( strCategoryNameNew );
            }
#ifdef _DEBUG
            else
            {
                  ASSERT( pArrCategoryColumns != NULL );
            }
#endif // _DEBUG
            pArrCategoryColumns->Add( pMovingRGC );
      } // if( _tcscmp(strCategoryNameNew,strCategoryNameOld) != 0 )
      else
      {
            if(   _tcscmp(
                        strColumnNameOld,
                        strColumnNameNew
                        ) == 0
                  )
                  return true; // both names are equal
            if(   ! m_mapColumnCategories.Lookup(
                        strCategoryNameNew,
                        (void*&)pArrCategoryColumns
                        )
                  )
                  return false; // not found
            ASSERT( pArrCategoryColumns != NULL );
            nCount = LONG( pArrCategoryColumns->GetSize() );
            ASSERT( nCount > 0 );
            for( nIndex = 0; nIndex < nCount; nIndex ++ )
            {
                  CExtReportGridColumn * pRGC =
                        pArrCategoryColumns->GetAt( nIndex );
                  ASSERT_VALID( pRGC );
                  ASSERT( pRGC->m_pRGW == this );
                  if( _tcscmp(
                              pRGC->ColumnNameGet(),
                              strColumnNameOld
                              ) == 0
                        )
                  {
                        pMovingRGC = pRGC;
                        break;
                  }
            } // for( nIndex = 0; nIndex < nCount; nIndex ++ )
            if( pMovingRGC == NULL )
                  return false; // not found
            ASSERT_VALID( pMovingRGC );
      } // else from if( _tcscmp(strCategoryNameNew,strCategoryNameOld) != 0 )
      ASSERT_VALID( pMovingRGC );
      m_mapColumns.SetAt( pMovingRGC, pMovingRGC );
      pMovingRGC->CExtGridCellHeader::TextSet( strColumnNameNew );
      if( bRedraw && GetSafeHwnd() != NULL )
      {
            OnSwUpdateScrollBars();
            OnSwDoRedraw();
      } // if( bRedraw && GetSafeHwnd() != NULL )
      return true;
}

Now you can use this method for renaming columns:

void CChildView::OnRgExportToExcel() 
{
//    ReportColumnRename( _T("Name"), NULL, _T("Testing ReportColumnRename..."), NULL );
      ReportColumnRename( _T("Name"), _T("Main Information"), _T("Testing ReportColumnRename..."), NULL );
return;
}

This looks good (haven’t tested it yet), but I won’t be able to use it in my case.

In our application, we don’t have many columns, so I didn’t set any category names for them when registering ( strCategoryName parameter of ReportColumnRegister is always NULL). I also disabled Field Chooser dialog (the command for displaying it has been removed from context menu of reportgrid), so not having a category name doesn’t produce any problems. But now I won’t be able to use ReportColumnRename as I can’t fill second parameter to be valid.

If ReportColumnRegister allows a column to be registered without category, renaming should work as well.

Hello

When I display plural dialogues.
A dialogue interferes each other.

With an arrow button, it is displayed a dialogue greatly.
ttp://profuis0.tripod.com/20070724/image01.jpg

With an arrow button, it is displayed a dialogue small.
ttp://profuis0.tripod.com/20070724/image02.jpg

I want these functions.
Even a sample is good.

Hello,

Will it be feasible if I use WM_NCPAINT?

I have a control that is a set size on a dialog. The data that the control displays generally does not take up the entire control. Before bringing in Prof-UIS I would get the dialog brush through a system call:

    hbr = GetSysColorBrush(COLOR_3DFACE);

and paint the "background" or empty areas with that brush.

How do I paint the proper background theme in my control when using Profi-UIS?

As well, how do we get a standard CFile dialog to appear in the correct theme?

Thanks
Jon

Forgot the details: Profi-UIS 2.80 and Dev Studio 2005.

(PS: It would be nice to be able to edit our own posts so that we don’t have to keep replying to ourselves :>)

I should also add that the entire control is being painted via a single GDI+ object. Therefore I need to paint the background onto a GDI+ surface.

Jon

The background of all controls and dialogs is based on bitmaps and gradients, which depend on the current paint manager (theme). For some themes it is a gradient fill, for other ones it is a solid color fill (painted with FillSolidRect() method).

Your custom controls should paint a valid background which is compatible with the dialog background and current theme. Here is how your OnPaint() may look:

void CYourWnd::OnPaint() 
{
    ASSERT_VALID( this );
    CPaintDC dcPaint( this );
    CRect rcClient;
    GetClientRect( &rcClient );
    if( rcClient.IsRectEmpty() )
        return;

    CExtMemoryDC dc(
        &dcPaint,
        &rcClient
        );

    CRgn rgnClient;
    if( rgnClient.CreateRectRgnIndirect( &rcClient ) )
        dc.SelectClipRgn( &rgnClient );

    // draw themed background first
    bool bTransparent = false;
    if( g_PaintManager->GetCb2DbTransparentMode( this ) )
    {
        CExtPaintManager::stat_ExcludeChildAreas(
            dc,
            GetSafeHwnd(),
            CExtPaintManager::stat_DefExcludeChildAreaCallback
            );
        if( g_PaintManager->PaintDockerBkgnd( true, dc, this ) )
            bTransparent = true;
    }
    if( ! bTransparent )
        dc.FillSolidRect(
            &rcClient,
            g_PaintManager->GetColor( CExtPaintManager::CLR_3DFACE_OUT, this )
            );


    //////////////////////////////////////////////////////////////////////
    // PLACE CONTROL PAINTING CODE HERE
    //////////////////////////////////////////////////////////////////////


    if( rgnClient.GetSafeHandle() != NULL )
        dc.SelectClipRgn( &rgnClient );    
    g_PaintManager->OnPaintSessionComplete( this );
}

As for the file dialog, the is no theme support for it at the moment.

Thanks for the paintmanager info, that worked well for me.

The file dialog is a pretty major issue for us. Is there no way to get a skinned file dialog at all (not using the CFile MFC class?)

How are people handling this in their applications when the file open and file save look jarringly different from the rest of the program?

Thanks
Jon

If you move your mouse over a string gadget placed in a Ribbon (for example the Font selection gadget in the RibbonBar example), the left and bottom borders are not always drawn with the Office 2007 R2 themes.

Also, is it possible to change the height of the string control or its font height? It would be great if the height of the string control would be adjusted so that the font could fit in it. At the moment letters like g,y, etc are clipped.

Is there any way to add some "dummy" objects to a ribbon that just take up space and don’t draw anything? I could use something like that for some extra padding between elements.

Regards.

Thanks for you reply!

About the string controls, please see this link. You can clearly see that the letters like g are clipped at the bottom. This happens when the control is active.

I also noticed that the node group does not get highlighted if you move a mouse over one of it’s children fast enough. The easiest way to spot it is to place the mouse on the right or left side, outside of the ribbon and then quickly move the mouse over the very 1st button in it. You’ll see that the button does get highlighted, but its group node doesn’t. My lucky guess is that the mouse move offset "skips" over the small space between the button and the group node frame so the node group never gets a message with mouse coords inside its boundaries.

Regards

We confirm both problems. These will be fixed in the next release. Thank you.

Dear Support,

When I place a grid inside a tab control, and the grid occupies the whole area of the tab, There is no border on the right and bottom sides of the tab control.

How can I add the border?

Thanks,
Ron.

Any progress?
Regards,
Ron.

Dear Support,

I use the class CExtTabPageContainerWnd, derive it and override the function OnTabWndSelectionChange.
In this function I try to get the pointer to the pages (CExtResizableDialog dialogs in my case), and do some manipulation on them.
What I see is that the original pointer of the dialog I’ve inserted, and the pointer to the dialog I get from PagePermanentWndGet are not the same.
Is this behavior normal? If so, is there a way I can get the original pointers, or I need to keep them myself?

Thanks,
Ron.

When a dialog has 2 children of type CExtEdit and CExtScrollBar and the the edit control has the focus. Clicking on the Scroll bar control doesnt cause the edit control to loose the focus. You can try reproducing the issue with the ProfUIS Controls sample. Go to the Status Bar Page, add a scroll bar to the status bar, set focus to the position edit box (spin control) and click on the scrollbar. The scrollbar doesnt get the WM_SETFOCUS message.

Is support looking into this? I havent got any response to this query/finding.

Dear Support,

I have a cell of type CExtGridCellDropListComboBox, and I override the grid’s OnGridCellInputComplete to catch when selected item in the cell have changed.
If the user selects some item, I need to show him a message-box with some information.

The problem is that the drop-down list of the cell does not close, and appears on top of the message-box.
Even more strange is that I can keep on selecting items in the dropped list.
Shouldn’t the OnGridCellInputComplete be called after the drop-list is already closed?

Please advise.

Thanks,
Ron.

Dear Support,

Any progress/estimation for this task?

Regards,
Ron.

Author: Technical Support
Subject: Re:Re:Re:Re:Re:Grid In-Place control Jun 15, 2007 - 12:09 PM
Thank you for your feedback. We agree that a tutorial would be helpful and added this to our task list.

Dear Support,

This is from a thread a month ago.
Is there any estimation when this feature will be ready?

Regards,
Ron.

Subject: Re:Re:Re:CExtComboBox scroll-bar not skinned
Author: Technical Support
E-mail: support@prof-uis.com
We agree with you. This feature is still in our to-do list. The main problem is that such a scroll bar in a standard control is not a separate window but part of the controlaˆ™s non-client area. So the HWND-based CExtScrollBar cannot be used here. There is an article at CodeProject that demonstrates an approach to using scroll bar common controls with other common controls instead of built-in scroll bars. You can also download our test project that implements the approach given in the article (with regard to CExtScrollBar windows).

Dear Support,

This is a thread from last year regarding skinning in MDI application problem.
Any progress? Is there any estimation when this feature will be ready?

Regards,
Ron.

Author: Offer Har
Subject: MDI problem Nov 23, 2006 - 8:32 AM
Hi,
When i added CExtNCW support to my CMDIChildWnd derived class, the tile & cascade commands stopped working correctly.
Please verify and fix for the next version.
Author: Suhai Gyorgy
Subject: Re:MDI problem Nov 23, 2006 - 8:43 AM
Hereaˆ™s Supportaˆ™s answer for almost the same question from Oct 17th:
---Begin quote---
You should not use the CExtNCW template class with child windows and MDI child frames. First, CExtNCW currently supports captions of popup frame and dialog windows only. Second, the CExtNCW template class is not compatible with MDI child frames because the standard Windows MDI interface cannot work with windows which implement the custom non-client area. The custom NC area requires the WS_BORDER|WS_CAPTION styles to be removed from the window to make Windows API unable to overdraw the non-client area. The Windows MDI interface does not work with MDI child frames that do not have the WS_BORDER|WS_CAPTION style. We plan to recode the MDI interface from scratch to solve this problem.
---End Quote---
Author: Offer Har
Subject: Re:Re:MDI problem Nov 23, 2006 - 10:15 AM
Bug this means that i cannot fully theme my application, doesnaˆ™t it?
Author: Technical Support
Subject: Re:Re:Re:MDI problem Nov 27, 2006 - 1:04 PM
You cannot use CExtNCW for that. But this already is in our to-do list.
Author: Offer Har
Subject: Re:Re:Re:Re:MDI problem Nov 27, 2006 - 2:27 PM
When will this feature be ready?
Author: Offer Har
Subject: Re:MDI problem Dec 18, 2006 - 8:17 PM
Dear Support,

Is there is any knowledge when this feature will be implemented?

Regards,
Ron.

Dear Support,

Please find below a thread of a CExtDateTimeWnd problem (from the forum).
This is an open issue since January - any progress?

Regards,
Ron.

Hi,

I am using CExtDateTimeWnd in my dialog next to other controls.
All the other CExtEdit do not have frame by default, and when hovering over them, they have a frame.
The CExtDateTimeWnd have a black frame, which does not conform with the rest of the controls.

The style I apply to the custom controls are:
0x56030000, which do not enforce any frame.

Please change it for the next version.

Thanks.
Author: Technical Support
Subject: Re:CExtDateTimeWnd problem Nov 20, 2006 - 12:15 PM
We confirm this and will fix it in one of the next versions. Thank you reporting this problem.
Author: Offer Har
Subject: Re:Re:CExtDateTimeWnd problem Nov 29, 2006 - 10:27 PM
Was this fixed in the 2.62 version?
Author: Technical Support
Subject: Re:Re:Re:CExtDateTimeWnd problem Dec 1, 2006 - 8:48 AM
No, it is not fixed yet.

Author: Offer Har
Subject: Re:CExtDateTimeWnd problem Dec 18, 2006 - 8:19 PM
Dear Support,

Any estimation when this bug will be fixed?

Regards,
Ron.
Author: Offer Har
Subject: Re:CExtDateTimeWnd problem Jan 1, 2007 - 12:50 AM
Dears Support,

Any idea as to in which version this will be fixed?

Regards,
Ron.
Author: Technical Support
Subject: Re:Re:CExtDateTimeWnd problem Jan 4, 2007 - 4:58 AM
We will make CExtDateTimeWnd more consistent with CExtEdit approximately in two weeks.

Dear Support,

This is a thread from three month ago. Is there any progress with this feature?

Regards,
Ron.

Author: Technical Support
Subject: Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Tooltip for cells Apr 20, 2007 - 8:50 AM
This feature seems to be worth to be added to the library. Please give us some time so we can add it as a standard feature in one of the next versions.
Author: Offer Har
Subject: Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Tooltip for cells Apr 20, 2007 - 8:55 AM
OK...

Will be waiting...

Regards,
Ron.
Author: Technical Support
Subject: Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Tooltip for cells Apr 20, 2007 - 10:43 AM
The next version is being tested and will be released approximately within a week. So we will add it in the version that follows (within one, maximum two months).
Author: Offer Har
Subject: Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Tooltip for cells Apr 20, 2007 - 11:19 AM
Great.

Will be waiting...

Hi

I sent the following email
Were you able to understand bug contents?

>When I carry out printing
>DoModal of Dialog-A becomes invalid.
>I can operate Window of bottom of Dialog.

We failed to compile your project. The following "include" is not found in the StdAfx.h file:

#include <BaseTsdEx.h>

The following "include"s are not found in the ChildView.h, MuPrintGridPrPage.h and MuPrintGrid.h files:

#include "MTBASE\MtTempl.h"
#include "MTBASE\MtDefine.h"

As a result, many things like DECLARE_SMART_PTR cannot be compiled.

Hi

Because I revised a program, please try to test it with a thing of this place.

ttp://profuis0.tripod.com/20070723/SimpleGrids.lzh

------------------------------------------------------------------------

When I carry out printing
DoModal of Dialog-A becomes invalid.
I can operate Window of bottom of Dialog.

ttp://profuis0.tripod.com/20070723/image01.jpg

We compiled and run your test project successfully. The dialog with a grid in print preview mode becomes displayed over the main frame window and occupies the same position on the desktop. But the real problem is that these both dialogs are children (descendent) of the main frame window and you are trying to let both of them to run the modal message loop. You should destroy the first dialog before displaying the dialog with the grid window in the print preview mode. Please update the source code for the following method:

void Dialog2::OnOK() 
{
      CDialog::OnOK();
      m_PrtPreviewDlg = new CPrtPreviewDlg ;
      m_PrtPreviewDlg->Create ( CPrtPreviewDlg::IDD , ::AfxGetMainWnd() );
      m_PrtPreviewDlg->GoPrint( 0 );
}

Hello

I do not want to destroy Dialog2(Print setting dialogue).
Is not there another technique?

Hello,

almost four weeks ago I posted a bug report re. resizing of floating CExtDynamicControlBar windows (see original report below). My collegue also sent you a proposal, how this could be eventually fixed. On June 28th you asked for further information how to test the problem or possible bug fixes. We answered promptly. However, we didn’t get any feedback re. this issue for about three weeks now. Could you please provide any information about the current status?

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Original problem report from June 22th, 2007:

the following problem/bug can be reproduced with the MDI_DynamicBars sample:

- Build and start the sample.
- Make one of the bars floating.
- Activate another bar.
- Now move the mouse cursor to the right or bottom border of the (now inactive) floating bar, until the cursor becomes a double headed horizontal or vertical cursor.
- Now click the left mouse button without moving the mouse cursor.

Bug: even if the mouse position is not changed during clicking of the button, the width and/or height of the floating bar may be decreased by a few pixel.

In this sample this is just a minor visual defect. For our programs this bug is very annoying: some of our bars contain a scroll view with an "ideal size". The scroll sizes of these views are set to the ideal size and the bars are initially created with this ideal size as client area. But as soon as the user clicks to the right or bottom border of such bar (without moving the mouse !), the ideal size of the bar becomes disordered and nasty scroll bars appear (due to the decrease of the bar’s size, which causes a decrease of the scroll view’s size, too).

You can reproduce the annoying effect, too:

- Build and start the sample.
- Make one of the bars floating.
- Enlarge the height of the floating bar carefully just to the point, where the vertical scroll bar is disabled.
- Activate another bar.
- Now move the mouse cursor to the right or bottom border of the (now inactive) floating bar, until the cursor becomes a double headed horizontal or vertical cursor.
- Now click the left mouse button without moving the mouse cursor.

Bug: even if the mouse cursor is not moved the height of the bar changes and the scroll bar is activated again.

Hello,

in our application we need to create a CExtPageNavigatorWnd item with three panes. The height of the top pane shall be initially set to -1.

The following code creates the three panes in correct order:

// correct: ////////////////////////////////////////////////////////////////////////

    CExtPageNavigatorWnd::PAGE_ITEM_INFO * pPII =
        m_wndPageNavigator.ItemInsert(
            -1,
            _T("Correct"),
            (HICON)NULL,
            (HICON)NULL
            );

    CEditView* poView = new CEditView;
    poView->Create(NULL, NULL, WS_CHILD | WS_VISIBLE, CRect(0, 0, 0, 0), this, 0);

    CExtPageNavigatorWnd::ITEM_PANE_INFO * pIPI =
        pPII->PaneInsert(
            poView->GetSafeHwnd(),
            -1,
            _T("Top"),
            100,
            true
            );
    pIPI;

    poView = new CEditView;
    poView->Create(NULL, NULL, WS_CHILD | WS_VISIBLE, CRect(0, 0, 0, 0), this, 0);

    pIPI =
        pPII->PaneInsert(
            poView->GetSafeHwnd(),
            -1,
            _T("Center"),
            100,
            true
            );

    pIPI->Expand(CExtPageNavigatorWnd::ITEM_PANE_INFO::__ET_COLLAPSE);

    poView = new CEditView;
    poView->Create(NULL, NULL, WS_CHILD | WS_VISIBLE, CRect(0, 0, 0, 0), this, 0);

    pIPI =
        pPII->PaneInsert(
            poView->GetSafeHwnd(),
            -1,
            _T("Bottom"),
            -1,
            true
            );

    pIPI->Expand(CExtPageNavigatorWnd::ITEM_PANE_INFO::__ET_COLLAPSE);

// end of correct ////////////////////////////////////////////////////////////////////////

But as soon as we create the panes as we need them, with the height of the top pane set to -1, then the panes appear in wrong order:
"Top" over "Bottom" over "Center". The code below shows the wrong behaviour. It can be easily reproduced with the PageNavigator sample.

The order, in which these panes appear on the screen, should not depend on which of the panes has height -1.

(We cannot simply swap the order of "Bottom" and "Center" on creation of the panes as a workaround, because we additionally need to assign the height of -1 to different panes at runtime - by calling CExtPageNavigatorWnd::ITEM_PANE_INFO::HeightSet() programmatically. This again causes the items to appear in arbitrary order during runtime, which does not look very good).

// wrong ////////////////////////////////////////////////////////////////////////

    pPII =
        m_wndPageNavigator.ItemInsert(
            -1,
            _T("Wrong"),
            (HICON)NULL,
            (HICON)NULL
            );

    poView = new CEditView;
    poView->Create(NULL, NULL, WS_CHILD | WS_VISIBLE, CRect(0, 0, 0, 0), this, 0);

    pIPI =
        pPII->PaneInsert(
            poView->GetSafeHwnd(),
            -1,
            _T("Top"),
            -1,
            true
            );
    pIPI;

    poView = new CEditView;
    poView->Create(NULL, NULL, WS_CHILD | WS_VISIBLE, CRect(0, 0, 0, 0), this, 0);

    pIPI =
        pPII->PaneInsert(
            poView->GetSafeHwnd(),
            100,
            _T("Center"),
            100,
            true
            );

    pIPI->Expand(CExtPageNavigatorWnd::ITEM_PANE_INFO::__ET_COLLAPSE);

    poView = new CEditView;
    poView->Create(NULL, NULL, WS_CHILD | WS_VISIBLE, CRect(0, 0, 0, 0), this, 0);

    pIPI =
        pPII->PaneInsert(
            poView->GetSafeHwnd(),
            100,
            _T("Bottom"),
            100,
            true
            );

    pIPI->Expand(CExtPageNavigatorWnd::ITEM_PANE_INFO::__ET_COLLAPSE);

// end of wrong ////////////////////////////////////////////////////////////////////////