Subject |
Author |
Date |
|
Jon Ort
|
Oct 2, 2009 - 3:56 PM
|
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
|
|
Technical Support
|
Oct 5, 2009 - 8:06 AM
|
There are only two solutions available:
1) Good solution. Link your regular DLLs with Prof-UIS RDE library statically. I.e. you should use static RDE version of Prof-UIS.
2) Bad solution. Create several copies of Prof-UIS RDE library as DLL. All the copies must have different names.
|
|
Robert Webb
|
Oct 1, 2009 - 2:00 AM
|
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.
|
|
Technical Support
|
Oct 1, 2009 - 12:45 PM
|
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.
|
|
Robert Webb
|
Oct 2, 2009 - 1:55 AM
|
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.
|
|
Technical Support
|
Oct 2, 2009 - 1:58 PM
|
|
|
Robert Webb
|
Oct 2, 2009 - 2:35 AM
|
I should add that when I was linking with the non-RDE version (ie when I didn’t have __PROF_UIS_FOR_REGULAR_DLL defined) it all compiled and ran fine (didn’t try to link with any old 283 version files). Does it makes sense that it used to link and run without problems for the most part if I was linking the non-RDE version into our regular DLL? I tried copying ProfUIS287nd-RDE.lib to ProfUIS283nd-RDE.lib just to see what happened, and sure enough it compiled happily, although really, why is it looking for 283?? However it crashes now as soon as I run it. Stack ends like this: ProfUIS287nd-RDE.dll!CExtWA<CExtWS<CExtADLG<CExtResDlg>,301> >::NcFrameImpl_GetMinMaxInfo(tagMINMAXINFO * pMMI=0x00000000) Line 1775 + 0x12 bytes C++
> ProfUIS287nd-RDE.dll!CExtNCW<CExtResizableDialog>::NcFrameImpl_GetMinMaxInfo(tagMINMAXINFO * pMMI=0x00000000) Line 639 C++ The line in question looks like this: pMMI->ptMinTrackSize = m_ptMinTrackSize; pMMI is NULL, hence the crash. The stack seems to be missing some calls after the two above. Thoughts? Rob.
|
|
Halfdom LCap
|
Sep 30, 2009 - 10:05 PM
|
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.
|
|
Halfdom LCap
|
Oct 21, 2009 - 12:47 PM
|
The problem was solved with your suggestion.
Thank you very much.
|
|
Technical Support
|
Oct 3, 2009 - 6:34 AM
|
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.
|
|
Halfdom LCap
|
Oct 6, 2009 - 12:26 PM
|
Can you show me the example? I don’t know how to do.
|
|
Antonio Pelli Neto
|
Sep 30, 2009 - 2:04 PM
|
I would like to try the 2.87 version, but I din’t find the link to download. Where can I get it?
|
|
Technical Support
|
Oct 1, 2009 - 12:37 PM
|
Please drop us an e-mail to the support mail box at this web site so we will provide you with the FTP download information.
|
|
tera tera
|
Sep 30, 2009 - 4:00 AM
|
Hello. In the IWebBrowser inside, I want to display Excel.
Excel is never displayed.
I am troubled very much.
Advice please. 

|
|
tera tera
|
Oct 2, 2009 - 3:32 AM
|
Is not there the sample program good somewhere? Advice please. 
|
|
Technical Support
|
Oct 2, 2009 - 2:00 PM
|
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.
|
|
Technical Support
|
Oct 1, 2009 - 6:30 AM
|
Excel is an OLE server and container rather than an ActiveX control. You cannot display it inside ActiveX containers like IE browser. You should create control like DsoFramer inside ActiveX container (IE), then ask the DsoFramer control to display an OLE document inside it.
|
|
tera tera
|
Sep 30, 2009 - 12:30 AM
|
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;
}
|
|
tera tera
|
Oct 5, 2009 - 3:49 AM
|
Optimization takes too much time.
By the optimization of 75 lines, it takes the processing time of 120 seconds.  
|
|
Technical Support
|
Oct 5, 2009 - 12:49 PM
|
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.
|
|
tera tera
|
Oct 7, 2009 - 2:36 AM
|
Hello. I’m sorry.
SelectionOptimize worked quickly. Thanks,
|
|
Technical Support
|
Oct 2, 2009 - 2:04 PM
|
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();
}
|
|
Technical Support
|
Oct 1, 2009 - 6:30 AM
|
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.
|
|
tera tera
|
Oct 2, 2009 - 3:45 AM
|
I want a sample program to minimize a selection appointment domain...............
|
|
tera tera
|
Sep 30, 2009 - 12:30 AM
|
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;
}
|
|
Technical Support
|
Oct 1, 2009 - 6:30 AM
|
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.
|
|
tera tera
|
Sep 30, 2009 - 12:07 AM
|
Hello. A thing of the same ID is piled up, and it is displayed.
If same ID, the list wants to display only one. 
|
|
Technical Support
|
Oct 1, 2009 - 6:31 AM
|
Thank you very much for reporting us this issue. Please update the source code for the following two methods:
BOOL CExtRibbonBar::SetButtons(
CExtCustomizeCmdTreeNode * pNode
)
{
ASSERT_VALID( this );
m_bRibbonSimplifiedLayoutDelayedFlush = true;
if( m_pPopupPageMenuGroup->GetSafeHwnd() != NULL )
m_pPopupPageMenuGroup->DestroyWindow();
if( m_pPopupPageMenuAutoHide->GetSafeHwnd() != NULL )
m_pPopupPageMenuAutoHide->DestroyWindow();
if( m_pExtNcFrameImpl == NULL )
m_pExtNcFrameImpl =
CExtNcFrameImpl::NcFrameImpl_FindInstance(
m_hWnd,
this
);
if( m_pExtNcFrameImpl != NULL )
m_pExtNcFrameImpl->m_bNcFrameImpl_PivotPmSyncMode = true; // RibbonLayout_IsFrameIntegrationEnabled();
_RibbonPageRslaResetStateData();
m_arrGroupButtons.RemoveAll();
m_arrTabPageButtons.RemoveAll();
m_pFileTBB = NULL;
MenuInfoRemove();
CategoryRemoveAll();
if( pNode == NULL )
{
CExtMenuControlBar::SetButtons();
m_pRibbonNode = NULL;
return TRUE;
}
if( m_pRibbonNode == pNode )
return TRUE;
CExtMenuControlBar::SetButtons();
m_pRibbonNode = NULL;
ASSERT_VALID( pNode );
m_pRibbonNode = DYNAMIC_DOWNCAST( CExtRibbonNode, pNode );
if( m_pRibbonNode == NULL )
return FALSE;
m_pRibbonNode->Ribbon_InitCommandProfile( m_hWnd, true );
m_pRibbonNode->Ribbon_InitBar( this, NULL, false );
MenuInfoAddEmpty( this, _T("Default"), true );
CExtRibbonNodeTabPageCollection * pColNode = Ribbon_GetTabPageRootNode();
if( pColNode != NULL )
OnRibbonBuildCommandCategories( pColNode );
int nCatIdx, nCatCnt = CategoryGetCount();
for( nCatIdx = 0; nCatIdx < nCatCnt; nCatIdx ++ )
{
CExtCustomizeCmdTreeNode * pCatNode = CategoryGetTreeAt( nCatIdx );
ASSERT_VALID( pCatNode );
CExtSafeString str = pCatNode->GetTextUser();
CategoryMakeCmdsUnique( LPCTSTR(str) );
}
CategoryAppendAllCommands();
CategoryMakeAllCmdsUnique();
OnUpdateAccelGlobalInfo( true );
Ribbon_FileButtonInit();
_RibbonPageRslaResetStateData();
Ribbon_OnCalcMinMaxILE();
if( m_pExtNcFrameImpl != NULL )
m_pExtNcFrameImpl->NcFrameImpl_AdjustVistaDwmCompatibilityIssues();
_RecalcPositionsImpl();
return TRUE;
}
BOOL CExtRibbonPage::SetButtons(
CExtCustomizeCmdTreeNode * pNode
)
{
ASSERT_VALID( this );
m_bRibbonSimplifiedLayoutDelayedFlush = true;
_RibbonPageRslaResetStateData();
m_arrGroupButtons.RemoveAll();
m_arrTabPageButtons.RemoveAll();
MenuInfoRemove();
CategoryRemoveAll();
if( pNode == NULL )
{
CExtMenuControlBar::SetButtons();
m_pRibbonNode = NULL;
return TRUE;
}
if( m_pRibbonNode == pNode )
return TRUE;
CExtMenuControlBar::SetButtons();
if( m_bHelperPopupMode && m_pRibbonNode != NULL )
delete m_pRibbonNode;
m_pRibbonNode = NULL;
ASSERT_VALID( pNode );
m_pRibbonNode = DYNAMIC_DOWNCAST( CExtRibbonNode, pNode );
if( m_pRibbonNode == NULL )
return FALSE;
if( m_bHelperPopupMode )
m_pWndTop = GetMainRibbonPage()->GetCustomizeTopWnd();
m_pRibbonNode->Ribbon_InitCommandProfile( m_pWndTop->m_hWnd, true );
if( m_bHelperAutoHideMode )
m_pRibbonNode->CExtRibbonNode::Ribbon_InitBar(
this,
NULL,
false
);
else
m_pRibbonNode->Ribbon_InitBar( this, NULL, false );
if( ! m_bHelperPopupMode )
{
MenuInfoAddEmpty( this, _T("Default"), true );
OnRibbonBuildCommandCategories( m_pRibbonNode );
int nCatIdx, nCatCnt = CategoryGetCount();
for( nCatIdx = 0; nCatIdx < nCatCnt; nCatIdx ++ )
{
CExtCustomizeCmdTreeNode * pCatNode = CategoryGetTreeAt( nCatIdx );
ASSERT_VALID( pCatNode );
CExtSafeString str = pCatNode->GetTextUser();
CategoryMakeCmdsUnique( LPCTSTR(str) );
}
CategoryAppendAllCommands();
CategoryMakeAllCmdsUnique();
OnUpdateAccelGlobalInfo( true );
} // if( ! m_bHelperPopupMode )
m_bRibbonSimplifiedLayoutDelayedFlush = true;
_RibbonPageRslaResetStateData();
Ribbon_OnCalcMinMaxILE();
_RecalcPositionsImpl();
return TRUE;
}
|
|
tera tera
|
Sep 29, 2009 - 11:29 PM
|
Hello. The name of the list of drop-downs is non-display.
Is this non-the item which should be displayed? 
|
|
Technical Support
|
Oct 1, 2009 - 6:29 AM
|
We guess the split button is configured with auto-change identifier option and displaying text of last invoked from menu command. Please assign some unique text to the command node of this split button.
|
|
Rolf Boerkoel
|
Sep 29, 2009 - 7:37 AM
|
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
|
|
Technical Support
|
Sep 29, 2009 - 1:21 PM
|
We didn’t code any additional alignment modes for the touch inside/outside image painting modes yet. But the last version of the inside/outside image painting modes is present in Prof-UIS 2.87.
|
|
tera tera
|
Sep 29, 2009 - 12:10 AM
|
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.
|
|
Technical Support
|
Sep 29, 2009 - 1:18 PM
|
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.
|
|
tera tera
|
Sep 29, 2009 - 6:55 PM
|
Why will you have to perform QA_CLONED_COPY?
|
|
Technical Support
|
Oct 1, 2009 - 6:28 AM
|
We need to keep the saved content of the original quick access toolbar somewhere.
|
|
tera tera
|
Sep 26, 2009 - 1:41 AM
|
Hello. I want to non-display RibbonNode with this screen.
And a user can not choose node. 
|
|
tera tera
|
Sep 28, 2009 - 12:49 AM
|
|
|
Technical Support
|
Sep 26, 2009 - 12:37 PM
|
There are two ways to hide any command in the commands list box:
1) Create your CExtRibbonNode -derived and/or CExtCustomizeCmdTreeNode -derived classes which implement the CExtCustomizeCmdTreeNode::OnGetCommandsListBoxInfo() virtual method. This method should return false for hiding command in the commands list box.
2) Override the CExtCustomizeSite::OnCanDragCustomizeCommand() virtual method in your CExtRibbonBar -derived class and return false for commands which should not appear in the commands list box.
|
|
tera tera
|
Sep 25, 2009 - 8:03 PM
|
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. 
|
|
Technical Support
|
Oct 10, 2009 - 5:15 AM
|
We reproduced and fixed the tab control drag-n-dropping issues. You can download the newer source code.
|
|
Technical Support
|
Sep 29, 2009 - 1:17 PM
|
What’s exactly wrong with our implementation? Would you like to hide a drag-n-dropped tab shape?
|
|
tera tera
|
Sep 30, 2009 - 1:10 AM
|
>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. 
|
|
Technical Support
|
Oct 1, 2009 - 12:48 PM
|
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.
|
|
tera tera
|
Oct 2, 2009 - 4:44 AM
|
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
);
|
|
Technical Support
|
Oct 2, 2009 - 2:03 PM
|
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?
|
|
tera tera
|
Oct 5, 2009 - 4:03 AM
|
|
|
Technical Support
|
Oct 5, 2009 - 1:09 PM
|
Fixed. Please re-download newer source code from the same FTP location.
|
|
Rolf Boerkoel
|
Oct 5, 2009 - 1:40 AM
|
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!
|
|
Technical Support
|
Oct 5, 2009 - 1:09 PM
|
Fixed. Please re-download newer source code from the same FTP location
|
|
Rolf Boerkoel
|
Oct 6, 2009 - 3:18 AM
|
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.
|
|
Technical Support
|
Oct 6, 2009 - 1:21 PM
|
We cannot confirm this. Which tabs exactly should we use in for reproducing this?
|
|
Rolf Boerkoel
|
Oct 6, 2009 - 1:59 PM
|
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
|
|
Technical Support
|
Sep 27, 2009 - 8:05 AM
|
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.
|
|
tera tera
|
Sep 28, 2009 - 12:46 AM
|
Hello. I downloaded it. ( profuis287(2009-09-26).zip ) However, __ETWS_ITEM_DRAGGING has a bug.
The drug of the tab does not work normally as before.
Will you incorporate the following functions?
It is hard to use the movement of the tab under the present conditions. http://ifreeta.dee.cc/20090928/result.avi Thanks,
Give my best regards.
|
|
Robert Webb
|
Sep 25, 2009 - 3:10 AM
|
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.
|
|
Technical Support
|
Sep 25, 2009 - 2:01 PM
|
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.
|
|
Robert Webb
|
Sep 28, 2009 - 2:08 AM
|
As I said the repainting is invoked during ProfUIS’s handling of the __EXTTAB_MDI_UPDATE_TIMER_ID timer event, which in turn is invoked when the WM_MDIREFRESHMENU message is handled. I have found now though that it was our own code sending too many WM_MDIREFRESHMENU messages. I have worked around that and it fixes the problem, although it’s maybe still a little odd that when ProfUIS handles that message it causes the view to be redrawn, even when the menu hasn’t actually changed. For now though, I seem to have fixed this one, Thanks, Rob.
|
|
tera tera
|
Sep 25, 2009 - 1:45 AM
|
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. 
|
|
Technical Support
|
Sep 26, 2009 - 12:38 PM
|
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.
|
|
tera tera
|
Sep 27, 2009 - 6:25 PM
|
>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;
}
|
|
Technical Support
|
Sep 25, 2009 - 12:18 PM
|
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.
|
|
tera tera
|
Sep 25, 2009 - 7:59 PM
|
|
|
tera tera
|
Sep 26, 2009 - 2:46 AM
|
|
|
Dave Foster
|
Sep 24, 2009 - 1:58 PM
|
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
|
|
Technical Support
|
Sep 25, 2009 - 2:02 PM
|
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?
|
|
Technical Support
|
Sep 25, 2009 - 6:44 AM
|
You forgot to invoke the pData->m_bMenuChanged; line of code.
|
|
Dave Foster
|
Sep 25, 2009 - 1:19 PM
|
I followed what happens when pData->bMenuChanged is set to TRUE, inside of OnExtMenuPrepare(), with and without the call to pPopup->UpdateFromMenu(), and the results are mixed. I can see that without the call "UpdateFromMenu", the response within the routine CExtPopupMenuWnd::_TrackPopupMenu() to call _SyncItems() and _UpdateCmdUI() would seem desirable, but _SyncItems() is geared towards making the CMenu reflect what has been changed on the instance of CExtPopupMenuWnd, and not visa-versa. Otherwise, if pData->bMenuChanged is set to TRUE, followed by a call to UpdateFromMenu(), the program still asserts, and then crashes. What I want to do is synchronize the chages made within our OnUpdateXXX( CCmdUI *pCmdUI) to the CMenu objects they are being called for to "instantly" update the instances of CExtPopupMenuWnd that are mirroring them. I notice that the protected function _BuildItems really is what is the essence of UpdateFromMenu() that is needing to be called, but too much else is being done. I think I am going to have to write my own reconciliator function, to update the instance of CExtPopupMenuWnd. BTW - the problem with the update of the menu is only on the first time the pull-down window is dropped-down. Subsequent calls seem fine.
|
|
tera tera
|
Sep 24, 2009 - 2:12 AM
|
Hello. Can you make DropDown buttons and etc Buttons non-display temporarily? 
|
|
Technical Support
|
Sep 25, 2009 - 6:40 AM
|
You should temporarily remove all the __EGWS_BSE_BUTTONS_*** styles and repaint the grid control.
|
|
Offer Har
|
Sep 24, 2009 - 1:09 AM
|
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.
|
|
Technical Support
|
Sep 29, 2009 - 1:21 PM
|
|
|
Technical Support
|
Sep 25, 2009 - 6:43 AM
|
Fixed, please download 2.87 from the same location.
|
|
Offer Har
|
Sep 29, 2009 - 12:47 AM
|
Dear Support,
I’ve download the latest version and it’s not fixed. Please read what I wrote and try to reproduce: 1. A standard modal dialog with OK as default button 2. A custom control of type ProfUIS-DurationWnd 3. Edit the time data and press enter. At this point you would expect that the dialog would close - nothing happens. Thanks, Ron.
|
|
Offer Har
|
Sep 24, 2009 - 1:07 AM
|
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.
|
|
Technical Support
|
Sep 25, 2009 - 12:04 PM
|
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.
|
|
Technical Support
|
Sep 25, 2009 - 6:43 AM
|
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.
|
|
Offer Har
|
Sep 25, 2009 - 3:21 PM
|
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.
|
|
Technical Support
|
Sep 26, 2009 - 9:43 AM
|
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.
|
|
Offer Har
|
Sep 25, 2009 - 8:29 AM
|
1) You missed the issue of the column widths - why does it not take the actual width of the column? 3,4,5) When will this be ready?
|
|
tera tera
|
Sep 24, 2009 - 12:08 AM
|
Hello. Is not the size of the dialog memorized? 
|
|
Technical Support
|
Sep 25, 2009 - 6:41 AM
|
It’s restored in the latest Prof-UIS 2.87.
|