Forum

We are moving a large MFC product to Prof-UIS 2.84.



We have a project that has the following structure:



An EXE

DLL1

DLL2



The EXE links to MFC regular DLL1 and MFC regular DLL2. as well as the standard Prof-UIS libraries ProfUIS284md.dll



The DLLs use CExt_ProfUIS_ModuleState::InitExtension( ::AfxGetStaticModuleState() ); in their InitInstance as well as define __PROF_UIS_FOR_REGULAR_DLL so they link to ProfUIS284md-RDE.dll



The problem appears to be that g_pExternalModuleState is a singleton and when DLL2 get initialized it resets the state for any calls from DLL1.  Any DoModal calls from DLL1 try to locate the resources from Dll2.



Is there a way to get the automatic state management in Prof-UIS to handle this or is there a way to manually manage the Prof-UIS state?





Thanks

Jon Ort

Part of our program is implemented in a DLL.  Both this DLL and the main EXE do ProfUIS interface stuff, but we get a few problems when doing ProfUIS stuff from the DLL.

One problem is that if we derive our dialog from CExtNCW <CExtResizableDialog> instead of CDialog and call CExtNCW <CExtResizableDialog>::Create(id, parent) it fails to find the resource with the given ID.  If we use CDialog instead then it works fine.  Any thoughts about this?

Thanks,

Rob.

Please provide us with a couple of very important details:

- Whether your DLL is regular or extension type?

- Which configurations of Prof-UIS are used in your EXE and DLL projects?

If your DLL is regular, you should use RDE version of Prof-UIS in it.
If your DLL is extension, then please check whether the resource identifiers of your DLL are not intersected with EXE resource identifiers and with Prof-UIS 29000...31000 range of identifiers too.

Hmm, that might be the problem.  I believe ours is a regular DLL, but I link it to the same non-RDE ProfUIS DLL as our main exe.  I don’t really understand why they both need to use different configurations of the ProfUIS library.  Seems a pity to have to include the same library twice.

Anyway, I’m now trying to compile our DLL against the RDE ProfUIS DLL instead, but have an interesting problem.  Here’s some of the output:

3>TypeManager.cpp
3>   Automatically linking with Prof-UIS library: ProfUIS287nd-RDE.lib
3>	  (Professional User Interface Suite)
3>Generating Code...
3>Linking...
3>LINK : fatal error LNK1104: cannot open file ’ProfUIS283nd-RDE.lib’

But why is it trying to link to version 2.8.3 at the end??  All along it says it is automatically linking to 2.8.7, then right at the end it complains about the 2.8.3 library not being available.  I searched through our code and project files and there doesn’t seem to be anything explicitly linking in 283.  I can’t find anything in ProfUIS to cause this either.  Have you seen this before?  Any suggestions?

Thanks,

Rob.

You should compile the ANSI Debug RDE configuration of the ProfUISDLL project first.
Please also read this:
http://www.prof-uis.com/prof-uis/tech-support/faq/miscellaneous.aspx#how-to-use-prof-uis-in-my-dll-project

I’m using 2.85 version.

I refer from the example of "MDI_DynamicInnerOuterBars ".

I ’m trying to use CExtListCtrl in place of CSimpleDynamicEdit in the sy

The source of CSimpleDynamicEdit is

in MainFrm.cpp
pLogEdit = new CSimpleDynamicEdit;
VERIFY(pLogEdit->Create(
m_parrControlBars[i]->m_hWnd,
NULL) );
pCpriEdit->SetWindowText("Log Monitor");
How to use CExtListCtrl in place of CSimpleDynamicEdit?

=> I sent my project code to you(support@prof-uis.com ).

Please,check up the project source.

Thanks.

The problem was solved with your suggestion.

Thank you very much. 

We received your project. The code at line 400 in Mainfrm.cpp is absolutely OK:

. . . . .
#if 1
      CSimpleDynamicListViewCtrl * pList = new CSimpleDynamicListViewCtrl;
      CWnd * pWnd = CWnd::FromHandle(m_parrControlBars[i]->m_hWnd);
      VERIFY(
          pList->Create(
            WS_CHILD|WS_VISIBLE,
            CRect(0,0,1,1),
            pWnd,
            UINT(555)
            )
          );

#else
. . . . .

It simply creates фт un-initialized list view control without items and columns.

I would like to try the 2.87 version, but I din’t find the link to download. Where can I get it?

Hello.

In the IWebBrowser inside, I want to display Excel.

Excel is never displayed.

I am troubled very much.

Advice please. 

 

Is not there the sample program good somewhere?

Advice please.  

We don’t know any ready to use sample. But it should not be very difficult to create an ActiveX control which will display an Excel or any other document. Please create two MFC based projects. One is ActiveX control. Second is the SDI active document container application. Then embed the active document view, WS_CHILD-based analog of main frame and document classes of the second project into the first project. As result, your ActiveX control will display OLE documents and you can create this ActiveX inside any ActiveX container applications like IE.

Hello.

http://www.prof-uis.com/prof-uis/tech-support/support-forum/a-grid-is-slow-65574.aspx

I want a command to optimize the selection of the cell.

void CSampleMuGridDlg::OnButton2() 
{
    POINT  pt;    int iRow;
    for ( iRow = 0 ; iRow < m_pMuMlGrid->RowCountGet() ; iRow++ ){
	 if ( m_Flag[iRow] == true ){
	   pt.x = -1;
	   pt.y = iRow;
	   m_pMuMlGrid->Selection1Line( pt , true );
	  }
    }
}
bool CNxL_MlGrid::Selection1Line(
    POINT  pt,
    bool blFlag
    )
{
    if ( blFlag == true ){
	 if ( SelectionGetForCell( -1, pt.y ) == false ){
	  SelectionSet( pt , false );
	 }
    }else{
	 if ( SelectionGetForCell( -1, pt.y ) == true ){
	  SelectionSet( pt , false );
	 }
    }
    return true;
}

 

 

Optimization takes too much time.

By the optimization of 75 lines, it takes the processing time of 120 seconds. 

Optimization does not depend on the number of columns in the case of full row selection based grid control. We tested it using 200 rows in your sample project - not 75 rows. It does not take any visually noticeable time on 200 rows. So, we suspect you have some special conditions besides 75 rows in the selection region. We suspect you didn’t told us something important. Please try to repeat the long optimization delay problem in the sample project you sent us.

Hello.

I’m sorry.

SelectionOptimize worked quickly.

Thanks,

 

We added a new CExtGridBaseWnd::SelectionOptimize() virtual method:

// DECLARATION:
virtual bool SelectionOptimize();

// IMPLEMENTATION:
bool CExtGridBaseWnd::SelectionOptimize()
{
      ASSERT_VALID( this );
INT nAreaNumberOuter, nAreaNumberInner, nAreaCount = SelectionGetAreaCount();
      if( nAreaCount <= 1 )
            return false;
bool bSubtractSelectionAreas = SubtractSelectionAreasGet();
bool bOptimized = false;
      for( nAreaNumberOuter = 0; nAreaNumberOuter < (nAreaCount-1); )
      {
            bool bRemovedOuter = false, bMixWidthOuter = false;
            CRect rcSelectionOuter( SelectionGet( true, nAreaNumberOuter ) );
            for( nAreaNumberInner = nAreaNumberOuter + 1; nAreaNumberInner < nAreaCount; )
            {
                  CRect rcSelectionInner( SelectionGet( true, nAreaNumberInner ) );
                  if( bSubtractSelectionAreas )
                  {
                        if( rcSelectionOuter == rcSelectionInner )
                        {
                              VERIFY( SelectionRemoveAt( nAreaNumberOuter, false ) );
                              VERIFY( SelectionRemoveAt( nAreaNumberInner, false ) );
                              nAreaCount -= 2;
                              ASSERT( nAreaCount == SelectionGetAreaCount() );
                              bOptimized = bRemovedOuter = true;
                              break;
                        }
                        if( rcSelectionOuter.left == rcSelectionInner.left && rcSelectionOuter.right == rcSelectionInner.right )
                        {
                              if( rcSelectionOuter.top <= rcSelectionInner.top )
                              {
                                    if( rcSelectionOuter.bottom == ( rcSelectionInner.top - 1 ) )
                                          bOptimized = bMixWidthOuter = true;
                              }
                              else if( rcSelectionOuter.bottom >= rcSelectionInner.bottom )
                              {
                                    if( rcSelectionOuter.top == ( rcSelectionInner.bottom + 1 ) )
                                          bOptimized = bMixWidthOuter = true;
                              }
                              if( bMixWidthOuter )
                              {
                                    rcSelectionOuter.top = min( rcSelectionOuter.top, rcSelectionInner.top );
                                    rcSelectionOuter.bottom = max( rcSelectionOuter.bottom, rcSelectionInner.bottom );
                              }
                        }
                        else if( rcSelectionOuter.top == rcSelectionInner.top && rcSelectionOuter.bottom == rcSelectionInner.bottom )
                        {
                              if( rcSelectionOuter.left <= rcSelectionInner.left )
                              {
                                    if( rcSelectionOuter.right == ( rcSelectionInner.left - 1 ) )
                                          bOptimized = bMixWidthOuter = true;
                              }
                              else if( rcSelectionOuter.right >= rcSelectionInner.right )
                              {
                                    if( rcSelectionOuter.left == ( rcSelectionInner.right + 1 ) )
                                          bOptimized = bMixWidthOuter = true;
                              }
                              if( bMixWidthOuter )
                              {
                                    rcSelectionOuter.left = min( rcSelectionOuter.left, rcSelectionInner.left );
                                    rcSelectionOuter.right = max( rcSelectionOuter.right, rcSelectionInner.right );
                              }
                        }
                  } // if( bSubtractSelectionAreas )
                  else
                  {
                        if( rcSelectionOuter == rcSelectionInner )
                        {
                              VERIFY( SelectionRemoveAt( nAreaNumberInner, false ) );
                              nAreaCount --;
                              ASSERT( nAreaCount == SelectionGetAreaCount() );
                              continue;
                        }
                        if( rcSelectionOuter.left == rcSelectionInner.left && rcSelectionOuter.right == rcSelectionInner.right )
                        {
                              if( rcSelectionOuter.top <= rcSelectionInner.top )
                              {
                                    if( rcSelectionOuter.bottom >= ( rcSelectionInner.top - 1 ) )
                                          bOptimized = bMixWidthOuter = true;
                              }
                              else if( rcSelectionOuter.bottom >= rcSelectionInner.bottom )
                              {
                                    if( rcSelectionOuter.top <= ( rcSelectionInner.bottom + 1 ) )
                                          bOptimized = bMixWidthOuter = true;
                              }
                              if( bMixWidthOuter )
                              {
                                    rcSelectionOuter.top = min( rcSelectionOuter.top, rcSelectionInner.top );
                                    rcSelectionOuter.bottom = max( rcSelectionOuter.bottom, rcSelectionInner.bottom );
                              }
                        }
                        else if( rcSelectionOuter.top == rcSelectionInner.top && rcSelectionOuter.bottom == rcSelectionInner.bottom )
                        {
                              if( rcSelectionOuter.left <= rcSelectionInner.left )
                              {
                                    if( rcSelectionOuter.right >= ( rcSelectionInner.left - 1 ) )
                                          bOptimized = bMixWidthOuter = true;
                              }
                              else if( rcSelectionOuter.right >= rcSelectionInner.right )
                              {
                                    if( rcSelectionOuter.left <= ( rcSelectionInner.right + 1 ) )
                                          bOptimized = bMixWidthOuter = true;
                              }
                              if( bMixWidthOuter )
                              {
                                    rcSelectionOuter.left = min( rcSelectionOuter.left, rcSelectionInner.left );
                                    rcSelectionOuter.right = max( rcSelectionOuter.right, rcSelectionInner.right );
                              }
                        }
                        if(         rcSelectionOuter.left <= rcSelectionInner.left && rcSelectionOuter.right >= rcSelectionInner.right
                              &&    rcSelectionOuter.top <= rcSelectionInner.top && rcSelectionOuter.bottom >= rcSelectionInner.bottom
                              )
                        {
                              rcSelectionOuter.top = min( rcSelectionOuter.top, rcSelectionInner.top );
                              rcSelectionOuter.bottom = max( rcSelectionOuter.bottom, rcSelectionInner.bottom );
                              rcSelectionOuter.left = min( rcSelectionOuter.left, rcSelectionInner.left );
                              rcSelectionOuter.right = max( rcSelectionOuter.right, rcSelectionInner.right );
                              bOptimized = bMixWidthOuter = true;
                        }
                  } // else from if( bSubtractSelectionAreas )
                  if( bMixWidthOuter )
                  {
                        VERIFY( SelectionRemoveAt( nAreaNumberInner, false ) );
                        nAreaCount --;
                        ASSERT( nAreaCount == SelectionGetAreaCount() );
                        break;
                  }
                  nAreaNumberInner ++;
            } // for( nAreaNumberInner = nAreaNumberOuter + 1; nAreaNumberInner < nAreaCount; )
            if( bMixWidthOuter )
            {
                  SelectionSetAt( nAreaNumberOuter, rcSelectionOuter, false );
                  nAreaNumberOuter = 0;
            }
            else if( ! bRemovedOuter )
                  nAreaNumberOuter++;
      } // for( nAreaNumberOuter = 0; nAreaNumberOuter < (nAreaCount-1); )
      return bOptimized;
}

You can invoke it either after adding 200 selection areas or after adding each one new selection rectangle. We checked it using your test project:

void CSampleMuGridDlg::OnButton2() 
{
    POINT  pt;
    int iRow;
    for ( iRow = 0 ; iRow < m_pMuMlGrid->RowCountGet() ; iRow++ ){
      pt.x = -1;
      pt.y = iRow;
            m_pMuMlGrid->Selection1Line( pt , true );
      }

      m_pMuMlGrid->SelectionOptimize();
}

Your question is related to the incorrect usage of the grid control - not to Prof-UIS bug. Every app will work slow if you load to much data into it.

Now let’s discuss some additional details. The selection inside all the Prof-UIS grid controls is described as array of rectangles. This does not depend whether the grid control allows user to perform full row selection, single cell selection or multiple cells selection. Each rectangle contains row/column indices of selected sub-region of grid cells. If the grid cell needs to detect whether it’s selected, then it should review all the rectangles in the selection array and check whether cell’s row/column numbers are inside at least one of selection rectangles. This means you should not insert too much selection sub-regions into the grid control. We cannot make the grid control marking each cell as selected because this technique brings even greater performance disadvantages.

Hello.

http://www.prof-uis.com/prof-uis/tech-support/support-forum/a-grid-is-slow-65574.aspx

I want a command to optimize the selection of the cell.

void CSampleMuGridDlg::OnButton2() 
{
    POINT  pt;    int iRow;
    for ( iRow = 0 ; iRow < m_pMuMlGrid->RowCountGet() ; iRow++ ){
	 if ( m_Flag[iRow] == true ){
	   pt.x = -1;
	   pt.y = iRow;
	   m_pMuMlGrid->Selection1Line( pt , true );
	  }
    }
}
bool CNxL_MlGrid::Selection1Line(
    POINT  pt,
    bool blFlag
    )
{
    if ( blFlag == true ){
	 if ( SelectionGetForCell( -1, pt.y ) == false ){
	  SelectionSet( pt , false );
	 }
    }else{
	 if ( SelectionGetForCell( -1, pt.y ) == true ){
	  SelectionSet( pt , false );
	 }
    }
    return true;
}

 

Hello.

A thing of the same ID is piled up, and it is displayed.

If same ID, the list wants to display only one.

Hello.

The name of the list of drop-downs is non-display.

Is this non-the item which should be displayed?

I downloaded the 2.87 beta (profuis287(2009-09-27).zip) from the FTP site and noticed that all changes of the past few weeks are made undone. Is this by accident or on purpose?



This might be the reason that Ron, for example, reports that his issues aren’t fixed.





Kind regards,

Marco

 

Hello.

Whenever I set it by customization of QAT,

Existing QA data increase.   

Memory Image :

 CExtRibbonNodeQuickAccessButtonsCollection * pRibbonNode = Ribbon_GetQuickAccessRootNode();
 INT nIndex, nCount = pRibbonNode->GetNodeCount();
 CExtCustomizeCmdScreenTip * pTip;
 for( nIndex = 0; nIndex < nCount; nIndex ++ )
 {
  CExtCustomizeCmdTreeNode * pNode = pRibbonNode->ElementAt( nIndex );
  ASSERT_VALID( pNode );

But the data which increased are non-display.

Therefore it works officially not to have any problem.

But , there is a problem.

Please revise it.

 

The quick access toolbar contains command nodes of two types: initial buttons and current/customized buttons. If you didn’t customized the quick access tool bar yet, then it contains initial nodes only. The customized quick access toolbar contains hidden initial command nodes and visible current command nodes. The hidden ribbon bar buttons (CExtBarButton) have the TBBS_HIDDEN button styles. The customized (non-initial) command tree nodes (CExtCustomizeCmdTreeNode) have the __ECTN_RIBBON_QA_CLONED_COPY node style.

Why will you have to perform QA_CLONED_COPY?

Hello.

I want to non-display RibbonNode with this screen.

And a user can not choose node.

Thanks you

 

 

Hello.

Please improve the movement of the tab.

A mouse drug function.

There is a standard ItemDrag function.

However, it is hard to handle this function.

When I clicked a tab, I move a tab by mistake.

I want you to make operation dragging a tab clear.

As follows,

The tab which I chose floats, and it is displayed.

In the place that wants to move a tab , I want to let a user drop a tab.

We reproduced and fixed the tab control drag-n-dropping issues. You can download the newer source code.

What’s exactly wrong with our implementation? Would you like to hide a drag-n-dropped tab shape?

>What’s exactly wrong with our implementation?

>Would you like to hide a drag-n-dropped tab shape?

Yes

(1)

When the items of the tab increased,

When it is not drag & drop type, operation is difficult.

(2)

When a user clicked a tab frequently ,

The user complained that tabs moved well.

Implemented. We added the __ETWS_EX_TAB_SHAPE_ITEM_DRAGGING extended tab window style. If it’s specified, then the tab shape is displayed during drag-n-drop. If not, then a drag-n-drop cursor is displayed instead of tab item shape. Please re-download Prof-UIS 2.87.

Hello.

I have a user be happy about this

Thank you very much for your advice.

 

By the way, __ETWS_ITEM_DRAGGING does not work normally.

 m_wndTabInnerTop.ModifyTabWndStyle( 0 , __ETWS_ITEM_DRAGGING , true );
 m_wndTabInnerTop.ModifyTabWndStyleEx(
  0 , 
  0 , // __ETWS_EX_TAB_SHAPE_ITEM_DRAGGING | __ETWS_EX_EXTENDED_ITEM_DRAGGING , 
  true
 );

The old __ETWS_ITEM_DRAGGING-based drag-n-dropping works OK. It was mainly designed for tabbed groups of resizable control bars. Could you please describe step-by-step what’s wrong with it?

I move to right and left in a drug.

There is time when I cannot drag it.

http://ifreeta.dee.cc/20091005/result3.avi

Fixed. Please re-download newer source code from the same FTP location.

I also do have problems with tab dragging. Dragging a tab from right to the left works ok. However dragging a tab from left to the right doesn’t seem to work!

Fixed. Please re-download newer source code from the same FTP location

Unfortunately it still doesn’t seem to work as expected when dragging from left to right:



1) After dragging, TWO tabs are selected at the same time

2) The dragged tab is inserted in the wrong place.

We cannot confirm this. Which tabs exactly should we use in for reproducing this?

I checked this with a regular CExtMdiTabWnd.

As I do not return to the office before Monday I cannot give you much details on this right now. It only seems to happen when a tab is being dragged from left to right and dropped to a position somewhere before the last tab. Any peculiarities? The texts on the tabs are quite long, tabs are at the bottom, no close buttons, with icons, with the dragging styles set as mentioned earlier in this thread, office2k3 theme, XP pro sp2, latest 2.87 from ftp.



If you can’t reproduce it I’ll be happy to create a sample application later on.



Marco

Implemented. We added a __ETWS_EX_EXTENDED_ITEM_DRAGGING extended tab window style and a CExtTabWnd::OnTabWndDrawDraggedTabItemContent() virtual method. Please re-download the latest 2.87 from the same location.

Hi, this has been driving me mad for a week or two, but our view keeps repainting repeatedly.  I eventually tracked it down to the following sequence of events:

- The WM_MDIREFRESHMENU message keeps being sent to the MDI tabs window.

- ProfUIS catches this in CExtTMWI::OnHookWndMsg() and sets the __EXTTAB_MDI_UPDATE_TIMER_ID timer.

- The timer event is handled in CExtTMWI::WindowProc(), and calls _SyncAllItems()

- Downstream from this I think RecalcLayout() gets called and that probably causes a repaint of the current view itself.

It’s only in some types of view we have that this happens.  My guess is that I redraw and the window is marked as valid, but the timer is set before this and acted on after this, causing a loop.

First, why does WM_MDIREFRESHMENU ever cause a redraw of the view?  Especially when nothing in the menu has changed.  I don’t even know why that event keeps arriving.

Second, why is a timer used at all??  It seems a really bad way to delay an update till there’s a spare moment.  Isn’t OnIdle() the place for this?  Seems like a much safer way to do things.

Any other thoughts about why this is happening?  Currently I am overriding OnHookWndMsg() to catch the WM_MDIREFRESHMENU event and ignore it, and the MDI tabs bar menu still seems to remain valid, but I’m sure this is just hiding the real problem rather than fixing it.  And since doing it I have other problems, but not sure if they’re related.

Thanks,

Rob.

The Spy++ utility can help you and us to find out what’s really wrong. You can spy all the window message in the main UI thread of your application. There must be something what makes this infinite repainting occur. Something like timer based code which repaints parts of UI independently from whether repainting is needed or not. Please run your app, make it infinite repainting and put the code like this into any of methods which are invoked in this infinite magic:

if( CExtPopupMenuWnd::IsKeyPressed( VK_CONTROL ) )
{
int nNumericVariable = 0; nNumericVariable; // Please set breakpoint to this line of code.
}

The code snippet above will break into debugger if the Ctrl key is pressed. You can put it into your project or into Prof-UIS source code. Then you can start the infinite repainting show and Ctrl anytime. This will stop the app execution at the breakpoint. Now you can copy the content of the Call Stack window and show it to us. Please try to do this experiment several times and show us the most detailed and long call stack listing.

Hello.

A grid is slow

I add 200 lines to a grid.

Then I do a selection of all lines of the grid.

When I let a grid scroll, scroll is abnormally slow. 

Yes. It’s slow. You are added too many rectangles into the selection region. This is the same as to select manually a lot of rows by clicking on each of them while Ctrl key is pressed. This will never occur in the real life because nobody will select 200 rows via 200 mouse clicks. If you select the first row and press Shfit+End keys, then all the rows become selected and selection region contains only one rectangle. As a result, the grid works fast. If you need to compose selection of many grid rows programmatically, then your code should combine selection rectangles to minimize the number of rectangles in the selection region.

>This will never occur in the real life because nobody will select 200 rows via 200 mouse clicks.

It is to be possible programmatically.

After having executed the following processing.

I want a command optimizing a cell range.

void CSampleMuGridDlg::OnButton2() 
{
    POINT  pt;
    int iRow;
    for ( iRow = 0 ; iRow < m_pMuMlGrid->RowCountGet() ; iRow++ ){
     pt.x = -1;
     pt.y = iRow;
  m_pMuMlGrid->Selection1Line( pt , true );
 }
}
bool CNxL_MlGrid::Selection1Line(
    POINT  pt,
    bool blFlag
    )
{
    if ( blFlag == true ){
	    if ( SelectionGetForCell( -1, pt.y ) == false ){
		    SelectionSet( pt , false );
	    }
    }else{
	    if ( SelectionGetForCell( -1, pt.y ) == true ){
		    SelectionSet( pt , false );
	    }
    }
    return true;
}

We have grids with 200 and more lines in our sample projects provided with Prof-UIS. They scroll OK. We need to know how you initialize your grid control? It would be very interesting to debug this issue using your test project.

 

When I execute scroll in the following procedures

Such a phenomenon occurs.

http://ifreeta.dee.cc/20090926/SampleMuGrid200904.lzh

 

We have an application, which must be maintained using MFC, as well as uses the Prof-UIS library (different build targets).  In several locations throughout the code, menu items are inserted dynamically to the CMenu instances, and this works fine for MFC.  I have discovered that we must ignore the m_pMenu referenced within the pCmdUI parameter when running under Prof-UIS - this is OK.

However, the observation is that when running with Prof-UIS, the menu item inserted with InsertMenu(), does not appear in the menu until the drop-down menu is dropped down a second time.  I have read about using OnExtMenuPrepare() to to dynamic menu creation, but this method is not compatible with our desire to maintain the MFC version in the mannor it is currently being used.  What I hope to do is use OnExtMenuPrepare() to force a new transfer of the CMenu items to the CExtPopupMenuWnd items (I guess through UpdateFromMenu(), but the following snippet closes the menu and causes an assertion):

LRESULT CMainFrame::OnExtMenuPrepare(WPARAM wParam, LPARAM lParam) {

 CExtPopupMenuWnd::MsgPrepareMenuData_t * pData = reinterpret_cast< CExtPopupMenuWnd::MsgPrepareMenuData_t * > (wParam);                                        

 ASSERT( pData != NULL );

 CExtPopupMenuWnd * pPopup = pData->m_pPopup;

 ASSERT( pPopup != NULL );

 CMenu *pMenu = m_wndMenuBar->GetMenu();

 pPopup->UpdateFromMenu( GetSafeHwnd(), pMenu, true, false );

return TRUE;

}

In addition, the menu pMenu is not the one which I think should be bound with this instance of pData->m_pPopup.   Any sugguestions as to how to make this scheme work?

Thanks

Could you please create a small test project reproducing the assertions and crashing and send it to the support mail box at this web site?

You forgot to invoke the pData->m_bMenuChanged; line of code.

Hello.

Can you make DropDown buttons and etc Buttons non-display temporarily?

Dear Support,

I have a CExtDateTimeWnd control in a dialog, where the OK is the default value. The user enters time, and presses OK.

The problem is that even though the OK is the default button, pressing enter does not simulate the OK button pressing. It seems that the time control eats the enter, and it’s not passed to the dialog.

Please fix,

Regards,

Ron.

Please re-download it again. It looks we had an invalid FTP upload.
You can also use the following smallest possible test project for testing the date time control on a dialog:
http://www.prof-uis.com/download/forums/TestDateTimeWndInDialog.zip

Fixed, please download 2.87 from the same location.

Dear Support,

I switched to the latest 2.87 to fix the grid print when having more then one page bug. I have no several issues with the print I need to resolve:

1. I see that the grid print ignores the width of columns in the grid - I hide columns by setting them 0 width like this:

pHdrCell->ExtentSet(0,0);

pHdrCell->ExtentSet(0,-1);

pHdrCell->ExtentSet(0,1);

But the column still appears in the print preview and print. Other columns, that I make narrower or wider still get the default width the column was created with.

2. I need to control the styling of the grid - add/remove grid lines when printing, color the header rows & columns’ background etc. How can this be done?

3. I need to add a couple of text lines to be printed before the grid begins.

4. I need to add page numbers

5. I need to add header & footer to each page.

Thanks,

Ron.

The grid cells are measured before the printed/previewed content is generated. We supposed there are no reasons to print/preview some partial content.
The HTML engine is mostly ready. It’s implemented as very fast parser and DOM object tree. Most of HTML tags with parameters and CSS are supported. The only "small" thing we need to do is to make it used inside Prof-UIS everywhere. We think this is enough for releasing one Prof-UIS versions with this feature only. Prof-UIS 2.87 is ready to be released but it will be dedicated to paint manager improvements including Office 2010 theme. HTML is the next step.

1) The print preview subsystem uses all the range of rows/columns displayed in the grid. You should hide rows/columns which must not appear in the printed/previewed content. The CExtGridWnd::ColumnHide(), CExtGridWnd::RowHide(), CExtGridWnd::ColumnUnHideAll(), CExtGridWnd::RowUnHideAll(), CExtTreeGridWnd::ItemHide(), CExtTreeGridWnd::ItemHideSubTree() and CExtReportGridWnd::ReportColumnActivate() methods should be used for that. You should override the CExtPPVW_Printable::OnPreparePrinting() virtual method, hide everything needed, invoke parent class method and then unhide what was hidden.

2) The CExtGridCell::TextColorSet() and CExtGridCell::BackColorSet() methods allow you to specify several different text and background colors for the grid cell and it will use them depending on the state of the cell. Prof-UIS 2.85 introduced the new __ECS_PPV color type which allows to use a completely different text and background colors when printing cells.

3, 4 and 5) This is not available right now. We are working on the new HTML everywhere feature which should provide each component with ability to draw HTML instead of plain text. The grids must have two additional HTML based features: highlighting of filtering results like Outlook 2007 / 2010 and HTML based headers/footers in printed/previewed output.

In (1) How do I catch the event that the print or print preview was finished so that I can get back my columns? I tried OnEndPrinting but it didn’t work.

It’s simple. Both printing and previewing use the same algorithm. The entire print-out document is measured and painted into an array of metafiles. Each metafile is the one printed or previewed page. The metafiles are saved into the system temporarily folder and they have GUID based names. They are removed when the printing is finished or preview is closed. The CExtPPVW_Printable::OnPreparePrinting() virtual method does this work. It measures entire the printed/previewed content, splits it into array of pages in both horizontal and vertical direction and initialized metafiles for all the printed/previewed pages. The CExtPPVW template class has two parent classes: first is the class name of some control which should obtain the printing/previewing features and second is the CExtPPVW_Printable class. Prof-UIS provides specialized template versions of the CExtPPVW template class for all the Prof-UIS grid controls. Each of specialized versions, of course, implements the virtual CExtPPVW_Printable::OnPreparePrinting() method. So, you should override it, remember some flag variable indicating that the printed output is currently to be generated, invoke the parent class method and, finally, clear the remembered flag. That’s how your grid control can really know that all the painting and measurement virtual method of it and its cells is invoked for printing/previewing or for display rendering. But this is not the only available solution. Each implementation of the CExtPPVW_Printable::OnPreparePrinting() virtual method in each specialized version of the CExtPPVW template class invokes the CExtPPVW_Printable::OnPreparePrinting_Begin() virtual method at startup, the CExtPPVW_Printable::OnPreparePrinting_End() virtual method before returning execution control and the CExtPPVW_Printable::OnPreparePrinting_Progress() virtual method during generation of page metafiles array. You can override these virtual methods. The begin/end virtual methods can save some flag which indicates whether the printed/previewed content is currently generated and your grid control and its grid cells should perform some specific measurement and/or painting. The progress method allows you to watch the printing/previewing content generation step by step and to perform some displaying of it in some progress common control. The CExtPPVW_Printable::OnPreparePrinting_Progress() virtual method can return a false() flag and the printed/previewed content generation will be immediately canceled. So, if your app can potentially generated 10000 pages to print/preview and your users don’t want until such count of pages will be ready to print/preview, then you have an ability to cancel the printing/previewing process. If your users have some patience to wait until 10000 pages will be ready for printing/previewing, the it’s OK. The previewing of 10000 pages will work OK because only the temporarily enhanced metafile file names are kept in memory - the printing/previewing subsystem will not eat 10000 file handles.

Hello.

Is not the size of the dialog memorized?