Forum

Dear Support,

I need to keep extra information for a grid-cell or a grid row.
I could not find any SetItemData function like the one found in any other control.

Please advise.

Thanks,
Ron.

Dear Support,

I have a grid with an outer column.
When clicking cells in this column nothing happens.
Is there a way to make the click select the whole row?

Thanks,
Ron.

Dear Support,

I have a grid that the left column (a fixed column) has a running number.
The grid can be sorted, using the default sort - the flag __EGWS_BSE_SORT_COLUMNS
I would like the numbers to remain in order (1,2,3...) even when the grid is sorted by another column.

Is there a way to prevent the left column from being sorted? If not, is there any event / virtual function I can use when the sorting is over so that I will change the texts in all the cells of the left column?

Thanks,
Ron.

Dear Support,

I have a grid derived class which i initialize to have one header row on the left side, and one at the top.
I would like to access the top-left cell for writing something in it.

How do I do it?

Thanks,
Ron.

Question

In MDI application I have created 2 ribbonbar. When application starts I show default ribbonbar which is similar to MDI application default menu(fig 1.).

1. First problem is that in my application TestApp Name is not coming in middle of title bar. Its Left aligned. Can you tell me how to make this text Middle aligned on title bar of ribbonbar?

2. On click of File/New from application bar. I’m displaying my customized 2nd ribbonbar shown in second fig. and destroying first one. Again when I click on File/Close I’m again creating default ribbonbar once again and hiding customize ribbonbar. When I again open any file in my application then its showing title bar and below that Its creating ribbonbar. Please see the difference in both images. And can you tell me how to hide this title bar in fig 2?


Detailed pictures are send to support@prof-uis.com with from Address Kuna.

Is it possible to make intellisense working with your library in VC6.0 ?
Thank you

I’ve included includes only, it works, thank you!

I have those options already set in my VC but it’s not working :(

We are sorry: the Include and Src folders folders should be added to the Source files directories list

It seems there is some bug in CExtGridCellNumber / variant.
Assigning 64 bit value (for example _VariantAssign((__int64)val)) is not working on Windows 98.
(In win XP it works). I’ve tried release/statical exe in win 98.
Can you please check this ?
Thank you

P.S.
I guess there is also typo in the library - compilation is printing MCBS Selected instead of MBCS ;)

Thank you for response.
I apologize for bad report, the "MCBS" mistake is in another library I’m using I’ve thought it is your library :)

I’m a newbie but I searched the forum and couldn’t find a similar issue. I used the sample code found in ProfUIS_Controls_800 project for the comboBox. I select from my comboBox which has the dropdown arrow. Instead of seeing a dropdown list, there are tiny scrollbars which only allows one item to appear at a time. I want the combobox to dropdown the entire list. I’ve checked the properties in my project and the sample project. Any help is appreciated.

How do I get CExtGridCellDropListComboBox to sort the strings?

For some reason I wanted to test your SDI_DynamicBars sample, so I compiled and ran its Static Unicode Debug configuration on my VS2003. I was playing with its fullscreen-normal state closing the application and starting again many times. Some times, when I closed the application, it crashed. I couldn’t find out what I need to do to make it crash or not crash, it just happened randomly.

- Error message: Access violation reading location 0x018da3c4.
- Value of this in CArray at that point: 0x018da3bc.
- Call Stack:
    SDI_DynamicBars-sud.exe!CArray<CExtHookSink *,CExtHookSink *>::GetSize() Line 272 + 0x26    C++
    SDI_DynamicBars-sud.exe!CExtHookSink::HookChains_t::HookChainsWindowProc(unsigned int nMessage=130, unsigned int & wParam=0, long & lParam=0) Line 239 + 0xb    C++
    SDI_DynamicBars-sud.exe!CExtHookSink::HookChains_t::g_HookWndProc(HWND__ * hWnd=0x00200a20, unsigned int nMessage=130, unsigned int wParam=0, long lParam=0) Line 287 + 0x14    C++
    user32.dll!77d48734()     
    user32.dll!77d4d05b()     
    user32.dll!77d4b4c0()     
    user32.dll!77d4dabd()     
    ntdll.dll!7c90eae3()     
    user32.dll!77d4daf6()     
    SDI_DynamicBars-sud.exe!CWnd::DestroyWindow() Line 988 + 0xd    C++
    ...

Could you check this please? Thank you.

I have the same problem now since I switched from 2.62 to 2.64... Is there a solution for this?

Please let us know what is the library version you are using? The thing is we fixed it in the last version.

I’ve gone through installation, reinstallation (moved installation to different partition), and manual "unregister"ing and re"register"ing from the Prof-UIS/Help directory, and there does not appear to be integrated help for VS2005. My Visual Studio 6 installation seems fine. This is Prof-UIS 2.64.

Please let us know if unfiltered is selected in the Filtered by: combo box.

Hi,

I’m currently working with Prof-UIS 2.63-4

My application manages many MDIFrame.
I use a CExtToolControlBar in my mainframe to easily open the others MDIFrame.

I face a strange behaviour when I click in the CExtToolControlBar to open one of the MDIFrame, the newFrame open up and display correctly over the currently active mainframe.

When I try to click on the just spawned MDIFrame, it is the MainFrame that receives the event.
I’m also using the same spawn code on one of my mainFrame menu command (not in a CExtControlMenuBar) and it works perfectly.

The toolbar seems to force its parent frame to stay on top.
Do you have any ideas about how i can fix this issue. ?

Best Regards,

Hi,

An error is displayed when I use CToolBar in Prof.

Must not I use CToolBar in Prof?

Hi

I want to do processing totally similar to the following samples in CExtControlToolBar.

Thank You

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

struct    stToolBarInfo
{
int btnId; //
int imgIdx; //
int strId; //
};

#define XXX_TBAR_BUTTON_NUM 4
const stToolBarInfo cstTBarInfo[XXX_TBAR_BUTTON_NUM] =
{ {ID_BUTTON_1,0,IDS_BUTTON_1},
{ID_BUTTON_2,1,IDS_BUTTON_2},
{ID_BUTTON_3,2,IDS_BUTTON_3},
{ID_BUTTON_4,3,IDS_BUTTON_4} };

CToolBar m_wndToolBar;

int XXX::Load()
{

m_wndToolBar.ModifyStyle(0,TBSTYLE_LIST);
m_wndToolBar.LoadBitmap(IDB_XXX_TBAR_IMG);
m_wndToolBar.SetButtons(NULL,XXX_TBAR_BUTTON_NUM);
m_wndToolBar.SetBarStyle( m_wndToolBar.GetBarStyle()
&~CBRS_BORDER_TOP
| CBRS_BORDER_BOTTOM
&~CBRS_BORDER_RIGHT
&~CBRS_BORDER_LEFT );

for(int i=0;i<XXX_TBAR_BUTTON_NUM;i++){
m_wndToolBar.SetButtonInfo(i,cstTBarInfo[i].btId,TBBS_BUTTON,cstTBarInfo[i].imgIdx);
CString str(_T(""));
str.LoadString(cstTBarInfo[i].strId);
m_wndToolBar.SetButtonText(i,(LPCTSTR)str);
}
}

I create some CTreeCtrl in CExtPageNavigatorWnd object, and all CTreeCtrl seem to be not scrollable.
How could I do ?

That line looks strange. Why do you create a new tree (m_TreeCtrl_AllFolder) as a child of another tree (m_wndPNAllFolders)?

m_TreeCtrl_AllFolder.Create(WS_VISIBLE|WS_CHILD|TVS_HASLINES|TVS_HASBUTTONS|TVS_LINESATROOT,
    recta, &m_wndPNAllFolders, IDC_TREEDIR);

Sorry, I lose a line in my post code:

///////////////////////////// MainFrm.h //////////////////////////////////
...
    CDirTreeCtrl m_TreeCtrl_AllFolder;
...

CDirTreeCtrl look like : http://picasaweb.google.com.tw/ooy.yoo/Others/photo#5039047524469930946
CDirTreeCtrl inheri from CTreeCtrl class

My unscrollable problem seem to have no concern with CDirTreeCtrl, but to m_wndResizableBarTree(CExtControlBar class) which I use for replacing the m_wndSplitter(CExtSplitterWnd class)

PS:

Original Structure in PageNavigator:
CPNSplitterWnd --[contain]--> CExtPageNavigatorWnd --[constain]--> CTreeCtrl
My Structure:
CExtControlBar --[contain]--> CExtPageNavigatorWnd --[constain]--> CTreeCtrl --[contain]--> CDirTreeCtrl

The different (may cause of my unscrollable problem) is I use CExtControlBar instead of CPNSplitterWnd

Your Structure should look like

CExtControlBar -- [contain] --> CExtPageNavigatorWnd --[contain]--> CDirTreeCtrl

So the CDirTreeCtrl control should be created as a child of the CExtPageNavigatorWnd, not CTreeCtrl. You can send the CDirTreeCtrl class to us so we can help you insert it into the page navigator.

Ok, I fix that problem now, thanks.

But the other problem:
However I change the theme from UI Theme Switcher Toolbar, the Scrollbar look always is default gray

How could I change the theme of Scrollbar ??

The scrollbars you see are the scrollbars of the CDirTreeCtrl class, which I think is derived from CTreeCtrl, a pure MFC class, that’s why those scrollbars are not themed, because they have nothing to do with ProfUIS. But you can override CWnd::GetScrollBarCtrl method and have ProfUIS scrollbars created, thus they will be themed properly. Here’s how I think it should look like:

class CDirTreeCtrl : public CTreeCtrl
{
...
protected:
	CExtScrollBar m_wndScrollBarH, m_wndScrollBarV;
public:
	virtual CScrollBar * GetScrollBarCtrl( int nBar ) const
	{
		ASSERT_VALID( this );
		if( m_hWnd == NULL || (! ::IsWindow(m_hWnd) ) )
			return NULL;
		ASSERT( nBar == SB_HORZ || nBar == SB_VERT );
		if( nBar == SB_HORZ )
		{
			if( m_wndScrollBarH.GetSafeHwnd() != NULL )
				return ( const_cast < CExtScrollBar * > ( &m_wndScrollBarH ) );
		} // if( nBar == SB_HORZ )
		else
		{
			if( m_wndScrollBarV.GetSafeHwnd() != NULL )
				return ( const_cast < CExtScrollBar * > ( &m_wndScrollBarV ) );
		} // else from if( nBar == SB_HORZ )
		return NULL;
	}
	virtual LRESULT WindowProc( UINT message, WPARAM wParam, LPARAM lParam )
	{
		LRESULT lResult = CTreeCtrl::WindowProc( message, wParam, lParam );
		if ( message == WM_CREATE )
		{
			m_wndScrollBarH.m_eSO = CExtScrollBar::__ESO_BOTTOM;
			m_wndScrollBarV.m_eSO = CExtScrollBar::__ESO_RIGHT;
			if( ! m_wndScrollBarV.Create(
					WS_CHILD|WS_VISIBLE|SBS_VERT|SBS_RIGHTALIGN,
					CRect(0,0,0,0),
					this,
					1
					)
				)
			{
				ASSERT( FALSE );
				break;
			}
			if( ! m_wndScrollBarH.Create(
					WS_CHILD|WS_VISIBLE|SBS_HORZ|SBS_BOTTOMALIGN,
					CRect(0,0,0,0),
					this,
					2
					)
				)
			{
				ASSERT( FALSE );
				break;
			}
			m_wndScrollBarH.SyncReservedSpace( &m_wndScrollBarV );
			m_wndScrollBarV.SyncReservedSpace( &m_wndScrollBarH );
			//OnSwRecalcLayout( true ); // I’m not sure what to call instead of this and whether it’s needed at all.
		}
		return lResult;
	}
...
};

Or if you already have a CDirTreeCtrl::OnCreate method implemented, the code snippet from WindowProc should be placed there.

Everything work find except "OnSwRecalcLayout(true)"
How could I make sure how to use something like "OnSwRecalcLayout(true)"

You can learn more about this if you look at this sample.

In other words, I need the TreeCtrl in the PageNavigator sample (allfolder, favorite, shortcut) to be scrollable

How can I custom my own dialog theme like the ABOUT Dialog in the sample code?
That means when I click CExtThemeSwitcherToolControlBar item, not only change form style but also change all dialog which I made.
Thanks.
Peace.ˆ.ˆ

If you look at the declaration of CExtResizableDialog, you will see that its parent classes are wrapped in templates. One of these templates is CExtWS, which adds a theme-based background to a resizable dialog window. The skinned non-client area is provided by the CExtNCW template. So to make your dialog consistent with Prof-UIS themes, replace CDialog base class with CExtNCW < CExtResizableDialog >.

if we select any of the Office2007(release1/2/3) themes and then
make mouse movement over the bar (any of restore/minimize/close button) a strong blinking takes place however if we select
the theme other than that mentioned above it works fine.

Similarly in the Ribbonbar example from Prof-UIS if we select any of the themes of Office2007 and observe the Home -> Style Tab we can
observe such similar effect where style gallery control looks twice.

How do we avoid the blinking and flickering?

Thank you for reporting the bug. We fixed it and emailed you the information about how to download the update.

we are getting a following errors with new source code....

ExtGridWnd.cpp
Prof-UIS is automatically linking with oleaut32.lib
(OLE automation)
\Program Files\FOSS Software Inc\Prof-UIS\Src\ExtGridWnd.cpp(44624) : error C2666: ’pow’ : 7 overloads have similar conversions
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(620): could be ’long double pow(long double,int)’
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(618): or ’long double pow(long double,long double)’
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(572): or ’float pow(float,int)’
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(570): or ’float pow(float,float)’
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(534): or ’double pow(int,int)’
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(532): or ’double pow(double,int)’
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(195): or ’double pow(double,double)’
while trying to match the argument list ’(int, double)’
\Program Files\FOSS Software Inc\Prof-UIS\Src\ExtGridWnd.cpp(44648) : error C2666: ’pow’ : 7 overloads have similar conversions
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(620): could be ’long double pow(long double,int)’
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(618): or ’long double pow(long double,long double)’
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(572): or ’float pow(float,int)’
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(570): or ’float pow(float,float)’
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(534): or ’double pow(int,int)’
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(532): or ’double pow(double,int)’
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\math.h(195): or ’double pow(double,double)’
while trying to match the argument list ’(int, double)’

Dear Support,

We are just about to release a new version of our product, but while testing the Release version, we encountered a crash while closing the application. The crash happens somewhere inside CFrameWnd::DestroyWindow(), but only in Release, never in Debug.

We have tried to narrow down the possible causes of the crash. Our application is multilanguage, and we use the following code to set the correct text for the command with ID nCmdId:

void RcStrings::set_command_strings(UINT nCmdId, HWND hWnd)
{
	CExtCmdItem * pCmdItem =
			g_CmdManager->CmdGetPtr(
				g_CmdManager->ProfileNameFromWnd(hWnd),
				nCmdId
				);
	ASSERT (pCmdItem != NULL );

	TCHAR *pctCmdString = SysMem::alloc_string(get_rc_string(nCmdId));
	TCHAR *pctBegin = pctCmdString;
	TCHAR *pctEnd = SysChar::strchr(pctBegin, ’\n’); if (pctEnd) *pctEnd = EOS;
	TCHAR *pctTab = SysChar::strchr(pctBegin, ’\t’); if (pctTab) *pctTab = EOS;
	pCmdItem->m_sMenuText = pctBegin;
	if (pctTab) pCmdItem->m_sAccelText = pctTab + 1; 
	if (pctEnd) {
		pctBegin = pctEnd + 1;
		pctEnd = SysChar::strchr(pctBegin, ’\n’); if (pctEnd) *pctEnd = EOS;
		//pCmdItem->m_sTipStatus = pctBegin; 
		if (pctEnd) {
			pctBegin = pctEnd + 1;
			pctEnd = SysChar::strchr(pctBegin, ’\n’); if (pctEnd) *pctEnd = EOS;
			pCmdItem->m_sTipTool = pctBegin;
		}
	}
	SysMem::mem_free(pctCmdString, __FILE__, __LINE__);
}

get_rc_string(nCmdId) takes care of getting the appropiate command texts in "MenuText\tAccelText\nStatusTip\nToolTip" format (\tAcceltext part is optional).

Crash always happens while closing the window, but only if I clicked on a command while running the application, or sometimes even enough if I just pop up one of the submenus.
In our CMainFrame::OnCreate, we go through all the commands (they are listed in an array) to change their texts with RcStrings::set_command_strings. If I just command this loop, the crash dissappears. I tried to modify one of your samples to reproduce the problem, but didn’t succeed for now. I was hoping you could point me to a direction, what things I should check, what kind of changes were made around CExtCmdItem’s texts since your last version. The very same code runs smoothly when compiling with your v2.63. Our version release is stuck at the moment because of this.

Thank you,
Chris

Sorry, I forgot to add exception message: Access violation reading location 0x00000000.

Dear Chris,

This exception is not related to the CExtCmdItem class. Please let me know more details about the string initialization APIs listed in the root message of this thread. Where the text lines are really stored in? I mean the get_rc_string() API. Does this API access any cross-thread/cross-process COM-based interfaces?

To clarify it isn’t the string initialization to blame, I changed the mentioned method and removed call of get_rc_string():

void RcStrings::set_command_strings(UINT nCmdId, HWND hWnd)
{
	CExtCmdItem * pCmdItem =
			g_CmdManager->CmdGetPtr(
				g_CmdManager->ProfileNameFromWnd(hWnd),
				nCmdId
				);
	ASSERT (pCmdItem != NULL );

	//TCHAR *pctCmdString = SysMem::alloc_string(get_rc_string(nCmdId));
	TCHAR pctCmdString[] = _T("Test\tTest\nTest\nTest");
	TCHAR *pctBegin = pctCmdString;
	TCHAR *pctEnd = SysChar::strchr(pctBegin, ’\n’); if (pctEnd) *pctEnd = EOS;
	TCHAR *pctTab = SysChar::strchr(pctBegin, ’\t’); if (pctTab) *pctTab = EOS;
	pCmdItem->m_sMenuText = pctBegin;
	if (pctTab) pCmdItem->m_sAccelText = pctTab + 1; // van Accel a Command-hoz
	if (pctEnd) {
		pctBegin = pctEnd + 1;
		pctEnd = SysChar::strchr(pctBegin, ’\n’); if (pctEnd) *pctEnd = EOS;
		pCmdItem->m_sTipStatus = pctBegin;
		if (pctEnd) {
			pctBegin = pctEnd + 1;
			pctEnd = SysChar::strchr(pctBegin, ’\n’); if (pctEnd) *pctEnd = EOS;
			pCmdItem->m_sTipTool = pctBegin;
		}
	}
	//SysMem::mem_free(pctCmdString, __FILE__, __LINE__);
}

Crash still happens with this changed code, but if I comment out loop with calling of RcStrings::set_command_strings in CMainFrame::OnCreate, crash disappears. And as I wrote earlier, the very same code runs fine with previous version of Prof-UIS.

Seems your project requires more detailed testing. In a simple case, the ASSERT( AfxCheckMemory() ); code should be inserted at all reasonable places in all the memory management code provided by the SysMem namespace. But this requires the memory allocations based on the debug versions of the new/delete operators provided by MFC (i.e. the DEBUG_NEW should be defined at the beginning of the source files). The better memory crashing testes can be done with the Rational’s Purify software even trial version.

I tested further(I turned on debugging in Release version). When debugging at the time of crash, Call stack shows:
    myApp.exe!CExtHookSink::HookChains_t::HookChainsWindowProc() + 0x167    C++
    myApp.exe!CExtHookSink::HookChains_t::g_HookWndProc() + 0x7b    C++
    user32.dll!77d48734()     
    user32.dll!77d48816()     
    user32.dll!77d4b4c0()     
    user32.dll!77d4b50c()     
    ntdll.dll!7c90eae3()     
    user32.dll!77d4daf6()     
    myApp.exe!CWnd::DestroyWindow() Line 989    C++
    myApp.exe!CMainFrame::DestroyWindow() Line 527    C++

So as I suspected, crash happens somewhere inside your piece of code. Please, check this issue!

Dear Chris,

I have tried to re-produce the crash by debugging the SDI sample application. I have stepped through the sub-tree of functions invoked from the CExtHookSink::HookChains_t::HookChainsWindowProc() method and tried to setup all the local variables to NULL values but I failed to re-produce exactly the same Call Stack window content like in your message.

Please let me know the following details:

1) Whether the customizable toolbars and menus are used in the crashed application (I guess - yes).

2) Whether any kind if APIs which can track their own message loops are invoked at shutdown (any kind of cross-thread/cross-process COM interface invocations).

I guess there is something exist in your application what makes the de-initialization sequence of window hooks not exactly corresponding to the their installation sequence (in the inversed order) and some of CExtHookSink-based objects become destroyed/deleted earlier than expected. If my guess is correct, then putting the following code into the beginning of CMainFrame::DestroyWindow() method will fix the problem:

// this line is needed if the CMainFrame class is derived from the CExtCustomizeSite class
CExtCustomizeSite::RemoveAllWndHooks();
// this line will preliminary remove menu bar’s hooks
m_wndMenuBar.RemoveAllWndHooks();

1) No, we are not using your customization subsystem.
2) In CMainFrame::DestroyWindow, we call CExtControlBar::ProfileBarStateSave; g_CmdManager->ProfileWndRemove; save two values in registry with the usual ::RegCreateKeyEx, ::RegSetValueEx, etc. APIs; kill a timer with CWnd::KillTimer and clear the clipboard with the following code:

 	COleDataObject oDataObject;
	if (oDataObject.AttachClipboard() && oDataObject.IsDataAvailable(ourClipboardFmt))
		::OleSetClipboard(NULL);

Thats all.

But m_wndMenuBar.RemoveAllWndHooks(); seems to solve our problem, no crash when that call is included right before calling CFrameWnd::DestroyWindow() at the end of CMainFrame::DestroyWindow. Even though, I still don’t know what CExtHookSink-based object could have caused the crash.

The Win32 APIs can pass hook calls during their invocations. But unfortunately we cannot find out which hook sink object is destroyed in the incorrect moment because its run-time type information in invalid and unavailable. Hook sinks are used by menu bar, MDI tabs, tab page containers, window non-client area skinning subsystem, some common controls, customize site and dynamic bar site. Even of two items of these list are used in your project, it is hardly possible to detect which of them is destroyed incorrectly. The only solution we see is to switch to using thread hooks in Prof-UIS.

We are only using the menu bar and some common controls from the above list. How could we switch to using thread hooks in Prof-UIS?

I dock a toolbar in the bottom of Mainframe[ in function of CMainFrame::OnCreate() ],
so I can initial my application with docking that toolbar in the botom.

My problem:
After I hide that toolbar by any click event, I can’t start my application with default toolbar by rebuild [it is hidden from last time use]
In other words, first time I start my application and I see the toolbar in the bottom, then after I hidden the toolbar, I can’t see the toolbar anymore in initial time

How could I do ?
I just need to see the default window behavior designed by programmer.

Thank for help.

PS:
I can use other method to reach my need,
that is,
1. comment the g_CmdManager->SerializeState() and if( !CExtControlBar::ProfileBarStateLoad ... ).
2. build and run, then get a terrible look interface.
3. uncomment what I comment in step 1.
4. build and run, the I can get the "default window behavior" in initial time.
But this is not a good idea.
How could I do ?