Forum

Hello.

class MUXDLL_EXPORT CMuGridCellEditStr : public CExtGridInplaceEdit

This class is virtual in CExtGridInplaceEdit.
By this program, I want to judge the input character.
For example, DeleteKey or numerical value.

Please teach a sample code.

Then I cannot catch VK_DELETE.

With the following CODE, a message does not flow.

bool CExtGridWnd::OnGbwBeginEdit(
 LONG nVisibleColNo,
 LONG nVisibleRowNo,
 LONG nColNo,
 LONG nRowNo,
 INT nColType,
 INT nRowType,
 const RECT & rcCellExtra,
 const RECT & rcCell,
 const RECT & rcInplaceControl,
 bool bContinueMsgLoop, // = true
 __EXT_MFC_SAFE_LPCTSTR strStartEditText, // = NULL
 HWND hWndParentForEditor // = NULL
 )
{
 :
 :
 :
 :
	 if( (!bCtrl) && (!bShift) && int(msg.wParam) == VK_DELETE )
	 {
	  if( msg.message != WM_CHAR )
	  {
	   if( ! g_pEditCell->_OnQueryInplaceVkDeleteProcessingEnabled() )
	   {
		::PeekMessage(&msg,NULL,msg.message,msg.message,PM_REMOVE);
		continue;
	   }
	   LRESULT lResult = 0L;
	   g_pEditCell->OnInplaceControlWindowProc(
		lResult, msg.message, msg.wParam, msg.lParam, msg.hwnd, *this,
		nVisibleColNo, nVisibleRowNo, nColNo, nRowNo, nColType, nRowType,
		rcCellExtra, rcCell, rcInplaceControl
		);
 :
 :

The CExtGridWnd::OnGbwBeginEdit() will be invoked only if the WindowProc virtual method of your in-place editor control invokes the parent class’s WindowProc virtual method for WM_KEY*** messages.

The CExtGridWnd::OnGbwBeginEdit() will be invoked only if the WindowProc virtual method of your in-place editor control will invoke the parent class WindowProc virtual method for WM_KEY*** messages.

How do I RowInsert() into hidden rows whilst a filter is applied?

Thanks ... that works great.

Can the same be done with CExtTreeGridWnd?

Yes, you can do the same with tree grid, but you need to perform per-item un-hiding.

Are you really saying there is no way to do it?

We mean there is no reason to do this. But you can show all rows (CExtGridWnd::RowUnHideAll()), insert any new rows anywhere, refresh filters (CExtGridWnd::OnGridFilterUpdateForRows()). This can be done without repainting the grid control several times.

Hello,
I have a simple MFC Project with a child view. The Child view is handling the WS_INPUT Data for RAW INPUT. When I include the Prof-UIS.h inside my StdAfx.h I got a compilation Error.

To reproduce the Issue:
- Create a simple MFC Project with the Application Wizard.
- Add the following Code to the WndProc Function of the ChildView.

    switch(message)
    {
    case WM_INPUT:
        {
            UINT dwSize;

            GetRawInputData((HRAWINPUT)lParam, RID_INPUT, NULL, &dwSize, sizeof(RAWINPUTHEADER));

            LPBYTE lpb = new BYTE[dwSize];
            if(lpb == NULL)
                return 0;
        }
        break;
    }

- Compile. You can see the Application running.
- Now include the Prof-UIS.h inside the StdAfx.h
- Compile again and you’ll get a strange error.

What can I do to prevent this.

We provided you with the solution we found using Visual Studio 2008. It can be different on other Visual Studio versions.

That solution doesn’t seem to work...

Instead I have found a work around but I don’t know what happens if I do that in Prof-UIS. In the File ExtMfcDef from Prof-UIS there is the following code block:

#if _MFC_VER >= 0x900    
    #ifndef HRAWINPUT
        #define HRAWINPUT DWORD
    #endif
    struct tagMENUGETOBJECTINFO;
    typedef tagMENUGETOBJECTINFO MENUGETOBJECTINFO;
    typedef tagMENUGETOBJECTINFO * PMENUGETOBJECTINFO;
#endif

If I modify that to

#if _MFC_VER >= 0x900    
/*
    #ifndef HRAWINPUT
        #define HRAWINPUT DWORD
    #endif
*/
    struct tagMENUGETOBJECTINFO;
    typedef tagMENUGETOBJECTINFO MENUGETOBJECTINFO;
    typedef tagMENUGETOBJECTINFO * PMENUGETOBJECTINFO;
#endif

all seems to work....

Hello,

I use a split view with 2 formView. The first contains a CExtTreeGridWnd.

When I set focus with  ItemFocusSet function the item is highlighted. But when I click on the second view. The CExtTreeGridWnd loses its focus and then the item loses its highlighting.

Is it possible not to lose highlighting?      ( I want to keep the highlighting all the time).

(I’m using 2.87)

BR,

Stephane

Dear Support Team,

the bug with the 3 digits is still exist (2.90). Link: http://www.prof-uis.com/prof-uis/tech-support/support-forum/cextgridcellipaddress-58516.aspx You can produce the bug with the ProfUIS_Controls sample. Just reduce the column size and then try to type a 3 digits number.

Best Regrads,

Lars

Hello.

When there is not a focus, I want to draw bounds in ComboBox.

Hello.

Can only a specific line of ComboBox acquire a color?

It is not the background of the ComboBox.

Hi,

I would like to bake in pagination to the grid control. Could you please give some guidance.

The problem is specially when the grid is sorted, or the filters are active.

The application I am working on potentially can have 1000+ rows. Pagination with user selection of how many records he wants to see - would be useful.

Thank you,

Saayan

Thank you. Much appreciated.

Thank you for your reply.

This will be a good start. I do not have a DB - the records are read from a serialized file. I shall use the approach that you have mentioned.

Yes. Virtually cacheable grids require a recordset data provider component. Here is another sample app dedicated to virtually cacheable grid, but not related to databases:

www.prof-uis.com/download/forums/CacheableGrid2.zip

Hello.

I want to add a menu dynamically.

Even if, after LoadFrame, I add a menu

It is not displayed.

Please teach a method to add dynamically.

    CMainFrame* pFrame = new CMainFrame;
 m_pMainWnd = pFrame;
 if( ! pFrame->LoadFrame(
   IDR_MAINFRAME,
//   IDR_NXBKTYPE,
   WS_OVERLAPPEDWINDOW|FWS_ADDTOTITLE,
   NULL,
   NULL
   )
  )
  return FALSE;
 // window placement persistence
		 :
		 :
		 :

int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
 if( CExtNCW < CFrameWnd > :: OnCreate( lpCreateStruct ) == -1 )
  return -1;
 // メニューバーの作成
 if( ! m_wndMenuBar.Create(
   NULL,
   this,
   ID_VIEW_MENUBAR
   )
  )
 {
  TRACE0("Failed to create menubar\n");
  return -1;
 }
    m_wndMenuBar.InitMenuMCB();
		 :
		 :
		 :

void CNxbkMenuControlBar::InitMenuMCB()
{
 CMenu popupMenu;
 BOOL bCreate;
 bCreate = popupMenu.CreatePopupMenu ();
 // メインメニュー
 bCreate = popupMenu.AppendMenu ( MF_STRING, 123 , "aaa" );
 bCreate = popupMenu.AppendMenu ( MFT_SEPARATOR  );
 bCreate = popupMenu.AppendMenu ( MF_STRING, 444 , "bbbb" );
 bCreate = popupMenu.AppendMenu ( MFT_SEPARATOR  );
 CMenu* pMenu = GetMenu();
 bCreate = pMenu->AppendMenu ( MF_POPUP, ( UINT ) popupMenu.Detach() , "AddMenu" );
}

 

Thank you for the test project. The approach you are using in your app works only in the SDI environment. The MDI environment changes menus on-the-fly. Your code is almost OK. You only forgot to re-build menu bar buttons from the changed menu:

void CNxbkMenuControlBar::InitMenuMCB()
{
CMenu popupMenu;
            BOOL bCreate;
            bCreate = popupMenu.CreatePopupMenu ();
            bCreate = popupMenu.AppendMenu ( MF_STRING, 123 , "aaa" );
            bCreate = popupMenu.AppendMenu ( MFT_SEPARATOR  );
            bCreate = popupMenu.AppendMenu ( MF_STRING, 444 , "bbbb" );
            bCreate = popupMenu.AppendMenu ( MFT_SEPARATOR  );
CMenu* pMenu = GetMenu();
            bCreate = pMenu->AppendMenu ( MF_POPUP, ( UINT ) popupMenu.Detach() , "_POPUP_" );
            UpdateMenuBar( FALSE ); // THIS LINE IS IMPORTANT
}

Could you send the complete source code for CMainFrame and CNxbkMenuControlBar classes to the support mail box at this web site?

Hi,



Do you have something similar to the custom background inheritance for the text color ?

I would like to set it per view and for all of its descendants



thank you



David

Hi,

Could you please suggest a simple way to combine date picker (CExtDatePickerWnd) with an edit box. I wish to use this in a dialog.

When I tried to make display a CExtDatePickerWnd object on the fly (on a button click) the rendering had problems. Other dialog controls showed on top of the date picker. I tried with wndTop and wndTopMost styles - it did not work.

(pls see attachment).

Thank you,

Saayan

Thank you for your help.

Hi,

When I select an item in my CExtTreeCtrl, it highlights in dark blue.  If the window loses focus, the selected item changes to a light grey.  On some machines this is hard to distinguish from the white background.  How can we make the selected item maintain its dark blue colour even when the window loses focus?  I had hoped ShowSelectionAlwaysSet() would do it, but it seems not to.

Thanks,

Rob.

Please override the CExtTreeCtrl::OnQueryWindowFocusedState() virtual method. Your method should return true.

Dear support,



In a skinned application,

Is it possible to use a color instead of an image to draw, for example, a background.



I would like to do it without having to change my application.

(like editing the xml skin file)



thank you.

Using 2.90 of the MFC library, have noticed on XP (32-bit) if you attempt the XP look and feel (even in your sample applications) via either the "Native" toolbar option, or the VIsual Studio options, or the Office options prior to Office 2007, the normally rounded corners of the application will "square off" with the extra pixels being black.  Mind you, the application will start up just fine with whatever theme was in use when it last exited.  But as soon as you change the theme/skin to one of those I mentioned, the corners go back to black, when after reselecting the theme/skin you started with.

Is there anything I can change to fix this?

K.

I’m trying to get skinned scroll bars to work with a CScrollView.  Searching the forum, I see where you recommended the PageContainer sample for an example of how to add skinned scroll bars to a view.  The sample uses CExtNCSB < CExtWS < CExtAFV < CFormView > > > with the class definition.  I tried adding this to my view class definition, and adding it in calls to the base class in the cpp file. 

When I try to run the program, it asserts down in the windows libraries, in the Child Frame OnCreateClient on the CreateView() call.

What am I doing wrong?

Bill

That was it.  The scroll bars look good now.

Thanks,

Bill

Here is the class definition:

class CFrmSwitch : public CExtNCSB < CExtWS < CExtAFV < CFormView > > >

The constructor:

CFrmSwitch::CFrmSwitch():CExtNCSB < CExtWS < CExtAFV < CFormView > > > ( CFrmSwitch::IDD, ((CWnd *)NULL) )

OnCreate:

int CFrmSwitch::OnCreate(LPCREATESTRUCT lpCreateStruct)

{

    if (CExtNCSB<CExtWS<CExtAFV<CFormView> > >::OnCreate(lpCreateStruct) == -1)

        return -1;



    // TODO:  Add your specialized creation code here



    return 0;

}

I have a couple of other calls that call the default function with the same Prof-UIS functions ahead of it.  Changing CExtNCSB to CExtWA works, but does not skin the scroll bars.

When it stops, all the debugger says is that the program triggered a break point.  This happens even if no break points are set.  This is VS 2005 BTW.

Here is the stack when the debugger breaks:

     ntdll.dll!7c90120e()    

     [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]   

>    MultiTraceVI.exe!_CrtDbgBreak()  Line 89    C

     MultiTraceVI.exe!_VCrtDbgReportA(int nRptType=0x00000002, const char * szFile=0x01594948, int nLine=0x00000149, const char * szModule=0x00000000, const char * szFormat=0x00000000, char * arglist=0x00125f28)  Line 290    C

     MultiTraceVI.exe!_CrtDbgReportV(int nRptType=0x00000002, const char * szFile=0x01594948, int nLine=0x00000149, const char * szModule=0x00000000, const char * szFormat=0x00000000, char * arglist=0x00125f28)  Line 300 + 0x1d bytes    C

     MultiTraceVI.exe!_CrtDbgReport(int nRptType=0x00000002, const char * szFile=0x01594948, int nLine=0x00000149, const char * szModule=0x00000000, const char * szFormat=0x00000000, ...)  Line 317 + 0x1d bytes    C

     MultiTraceVI.exe!AfxAssertFailedLine(const char * lpszFileName=0x01594948, int nLine=0x00000149)  Line 25 + 0x13 bytes    C++

     MultiTraceVI.exe!CWnd::Attach(HWND__ * hWndNew=0x00dc159c)  Line 329 + 0x18 bytes    C++

     MultiTraceVI.exe!_AfxCbtFilterHook(int code=0x00000003, unsigned int wParam=0x00dc159c, long lParam=0x00126240)  Line 530    C++

     user32.dll!7e42b372()    

     user32.dll!7e44f8ee()    

     ntdll.dll!7c90e473()    

     user32.dll!7e42e389()    

     user32.dll!7e42e34f()    

     ntdll.dll!7c92770a()    

     ntdll.dll!7c927784()    

     ntdll.dll!7c96e5df()    

     ntdll.dll!7c96f8e8()    

     ntdll.dll!7c96f8cc()    

     ntdll.dll!7c96f8cc()    

     ntdll.dll!7c94bc4c()    

     ntdll.dll!7c927784()    

     ntdll.dll!7c918f21()    

     ntdll.dll!7c9101db()    

     gdi32.dll!77f193e4()    

     gdi32.dll!77f193ec()    

     ntdll.dll!7c927784()    

     ntdll.dll!7c927573()    

     ntdll.dll!7c91005d()    

     user32.dll!7e419c2e()    

     user32.dll!7e419c17()    

     user32.dll!7e419d4d()    

     user32.dll!7e419d60()    

     ntdll.dll!7c91005d()    

     kernel32.dll!7c8099fa()    

     kernel32.dll!7c809a0d()    

     gdi32.dll!77f1a6fc()    

     kernel32.dll!7c809a0d()    

     gdi32.dll!77f1a782()    

     user32.dll!7e42c68a()    

     user32.dll!7e42c70b()    

     gdi32.dll!77f17598()    

     user32.dll!7e42c68a()    

     user32.dll!7e42c70b()    

     user32.dll!7e426423()    

     user32.dll!7e4249b1()    

     user32.dll!7e43a956()    

     MultiTraceVI.exe!_output_s_l(_iobuf * stream=0x00a5160e, const char * format=0x00188190, localeinfo_struct * plocinfo=0x00188418, char * argptr=0x00012012)  Line 1166 + 0x17 bytes    C++

     user32.dll!7e4664a2()    

     user32.dll!7e450877()    

     user32.dll!7e45082f()    

     MultiTraceVI.exe!__crtMessageBoxA(const char * lpText=0x00126eec, const char * lpCaption=0x01647334, unsigned int uType=0x00012012)  Line 168 + 0x13 bytes    C

     MultiTraceVI.exe!__crtMessageWindowA(int nRptType=0x00000002, const char * szFile=0x01594de0, const char * szLine=0x00128f60, const char * szModule=0x00000000, const char * szUserMessage=0x00127f60)  Line 420 + 0x16 bytes    C

     MultiTraceVI.exe!_VCrtDbgReportA(int nRptType=0x00000002, const char * szFile=0x01594de0, int nLine=0x00000272, const char * szModule=0x00000000, const char * szFormat=0x00000000, char * arglist=0x0012cff4)  Line 420 + 0x28 bytes    C

     MultiTraceVI.exe!_CrtDbgReportV(int nRptType=0x00000002, const char * szFile=0x01594de0, int nLine=0x00000272, const char * szModule=0x00000000, const char * szFormat=0x00000000, char * arglist=0x0012cff4)  Line 300 + 0x1d bytes    C

     MultiTraceVI.exe!_CrtDbgReport(int nRptType=0x00000002, const char * szFile=0x01594de0, int nLine=0x00000272, const char * szModule=0x00000000, const char * szFormat=0x00000000, ...)  Line 317 + 0x1d bytes    C

     MultiTraceVI.exe!AfxAssertFailedLine(const char * lpszFileName=0x01594de0, int nLine=0x00000272)  Line 25 + 0x13 bytes    C++

     MultiTraceVI.exe!AfxHookWindowCreate(CWnd * pWnd=0x02e18078)  Line 626 + 0x18 bytes    C++

     MultiTraceVI.exe!CWnd::CreateEx(unsigned long dwExStyle=0x00100000, const wchar_t * lpszClassName=0x01673e90, const wchar_t * lpszWindowName=0x01673e90, unsigned long dwStyle=0x46000000, int x=0x00000000, int y=0x00000000, int nWidth=0x00000000, int nHeight=0x00000000, HWND__ * hWndParent=0x00010016, HMENU__ * nIDorHMenu=0xffffffff, void * lpParam=0x00000000)  Line 694    C++

     MultiTraceVI.exe!CWnd::CreateEx(unsigned long dwExStyle=0x00100000, const wchar_t * lpszClassName=0x01673e90, const wchar_t * lpszWindowName=0x01673e90, unsigned long dwStyle=0x46000000, const tagRECT & rect={...}, CWnd * pParentWnd=0x02dcf9a8, unsigned int nID=0xffffffff, void * lpParam=0x00000000)  Line 659    C++

     MultiTraceVI.exe!CExtNCSB_ScrollContainer::Create(CWnd * pWndParent=0x02dcf9a8)  Line 3259 + 0x2e bytes    C++

     MultiTraceVI.exe!CExtNCSB_Impl<CExtWS<CExtAFV<CFormView>,301> >::NCSB_InstantiateAndCreateContainer(CExtNCSB_ScrollContainer::e_mode_t eMode=__EM_HORIZONTAL_SCROLL_BAR, CWnd * pWndParent=0x02dcf9a8)  Line 589 + 0x16 bytes    C++

     MultiTraceVI.exe!CExtNCSB_Impl<CExtWS<CExtAFV<CFormView>,301> >::NCSB_EnsureContainersCreated()  Line 630 + 0x18 bytes    C++

     MultiTraceVI.exe!CExtNCSB_Impl<CExtWS<CExtAFV<CFormView>,301> >::NCSB_RepositionContainers(bool bRescanScrollPositions=true)  Line 897 + 0x12 bytes    C++

     MultiTraceVI.exe!CExtNCSB_Impl<CExtWS<CExtAFV<CFormView>,301> >::PreSubclassWindow()  Line 1058 + 0x14 bytes    C++

     MultiTraceVI.exe!_AfxCbtFilterHook(int code=0x00000003, unsigned int wParam=0x00c6158e, long lParam=0x0012dec4)  Line 532    C++

     user32.dll!7e42b372()    

     user32.dll!7e44f8ee()    

     ntdll.dll!7c90e473()    

     user32.dll!7e42e389()    

     user32.dll!7e42e34f()    

     ntdll.dll!7c92770a()    

     ntdll.dll!7c927784()    

     ntdll.dll!7c96e5df()    

     ntdll.dll!7c96f8e8()    

     ntdll.dll!7c96f8cc()    

     ntdll.dll!7c96f8cc()    

     ntdll.dll!7c94bc4c()    

     ntdll.dll!7c927784()    

     gdi32.dll!77f19320()    

     gdi32.dll!77f192fb()    

     gdi32.dll!77f193e4()    

     gdi32.dll!77f193ec()    

     ntdll.dll!7c927784()    

     ntdll.dll!7c927573()    

     ntdll.dll!7c91005d()    

     MultiTraceVI.exe!ATL::CSimpleStringT<wchar_t,0>::SetString(const wchar_t * pszSrc=0x00000000, int nLength=0x02734fb8)  Line 663 + 0x10 bytes    C++

     user32.dll!7e42c70b()    

     gdi32.dll!77f17598()    

     gdi32.dll!77f16b25()    

     user32.dll!7e42c70b()    

     user32.dll!7e42f2cf()    

     user32.dll!7e426423()    

     user32.dll!7e42683e()    

     user32.dll!7e43f03a()    

     MultiTraceVI.exe!CWnd::CreateDlgIndirect(const DLGTEMPLATE * lpDialogTemplate=0x017ebd70, CWnd * pParentWnd=0x02e191d0, HINSTANCE__ * hInst=0x00400000)  Line 315 + 0x2a bytes    C++

     MultiTraceVI.exe!CWnd::CreateDlg(const wchar_t * lpszTemplateName=0x00000084, CWnd * pParentWnd=0x02e191d0)  Line 226 + 0x14 bytes    C++

     MultiTraceVI.exe!CFormView::Create(const wchar_t * __formal=0x00000000, const wchar_t * __formal=0x00000000, unsigned long dwRequestedStyle=0x50800000, const tagRECT & rect={...}, CWnd * pParentWnd=0x02e191d0, unsigned int nID=0x0000e900, CCreateContext * pContext=0x0012fabc)  Line 105 + 0x16 bytes    C++

     MultiTraceVI.exe!CFrameWnd::CreateView(CCreateContext * pContext=0x0012fabc, unsigned int nID=0x0000e900)  Line 594 + 0x33 bytes    C++

     MultiTraceVI.exe!CChildSwitch::OnCreateClient(tagCREATESTRUCTW * __formal=0x0012ede8, CCreateContext * pContext=0x0012fabc)  Line 61 + 0x11 bytes    C++

     MultiTraceVI.exe!CFrameWnd::OnCreateHelper(tagCREATESTRUCTW * lpcs=0x0012ede8, CCreateContext * pContext=0x0012fabc)  Line 634 + 0x18 bytes    C++

     MultiTraceVI.exe!CMDIChildWnd::OnCreate(tagCREATESTRUCTW * lpCreateStruct=0x0012ede8)  Line 1044    C++

     MultiTraceVI.exe!CChildSwitch::OnCreate(tagCREATESTRUCTW * lpCreateStruct=0x0012ede8)  Line 503 + 0xc bytes    C++

     MultiTraceVI.exe!CWnd::OnWndMsg(unsigned int message=0x00000001, unsigned int wParam=0x00000000, long lParam=0x0012ede8, long * pResult=0x0012eaf4)  Line 2000 + 0xd bytes    C++

     MultiTraceVI.exe!CWnd::WindowProc(unsigned int message=0x00000001, unsigned int wParam=0x00000000, long lParam=0x0012ede8)  Line 1741 + 0x20 bytes    C++

     MultiTraceVI.exe!CExtNCW<CMDIChildWnd>::WindowProc(unsigned int message=0x00000001, unsigned int wParam=0x00000000, long lParam=0x0012ede8)  Line 375 + 0x14 bytes    C++

     MultiTraceVI.exe!AfxCallWndProc(CWnd * pWnd=0x02e191d0, HWND__ * hWnd=0x00711680, unsigned int nMsg=0x00000001, unsigned int wParam=0x00000000, long lParam=0x0012ede8)  Line 240 + 0x1c bytes    C++

     MultiTraceVI.exe!AfxWndProc(HWND__ * hWnd=0x00711680, unsigned int nMsg=0x00000001, unsigned int wParam=0x00000000, long lParam=0x0012ede8)  Line 389    C++

     user32.dll!7e418734()    

     user32.dll!7e418816()    

     user32.dll!7e428ea0()    

     user32.dll!7e42ce7c()    

     ntdll.dll!7c90e473()    

     MultiTraceVI.exe!CExtUxTheme::GetThemeInt(int iPartId=0x0012f210, int iStateId=0x00000000, int iPropId=0x7e410000, int * piVal=0x7e4100d8)  Line 777 + 0x2b bytes    C++

     ntdll.dll!7c910323()    

     ntdll.dll!7c910385()    

     ntdll.dll!7c910323()    

     ntdll.dll!7c910385()    

     ntdll.dll!7c912465()    

     user32.dll!7e42cecb()    

     user32.dll!7e42ed8d()    

     user32.dll!7e42cecb()    

     user32.dll!7e42ed8d()    

     user32.dll!7e42ec6d()    

     user32.dll!7e42ebb2()    

     user32.dll!7e42cecb()    

     user32.dll!7e43fda4()    

     user32.dll!7e43fa8c()    

     user32.dll!7e43fcb3()    

     user32.dll!7e42e442()    

     MultiTraceVI.exe!CExtUxTheme::GetThemeInt(int iPartId=0x00000000, int iStateId=0x00400000, int iPropId=0x0012fabc, int * piVal=0x7e43049b)  Line 777 + 0x2b bytes    C++

     MultiTraceVI.exe!CExtUxTheme::GetThemeInt(int iPartId=0x00000000, int iStateId=0x00400000, int iPropId=0x0012fabc, int * piVal=0x7e43049b)  Line 777 + 0x2b bytes    C++

The assert happened a few lines back in the stack, but it’s in wincore.cpp here:

BOOL CWnd::Attach(HWND hWndNew)

{

>Here>    ASSERT(m_hWnd == NULL);     // only attach once, detach on destroy

    ASSERT(FromHandlePermanent(hWndNew) == NULL);

        // must not already be in permanent map



    if (hWndNew == NULL)

        return FALSE;



    CHandleMap* pMap = afxMapHWND(TRUE); // create map if not exist

    ASSERT(pMap != NULL);



    pMap->SetPermanent(m_hWnd = hWndNew, this);

You encountered a conflict of MFC’s window creation hooking mechanism. It does not like any new windows to be created until the creation of currently hooked window is complete. To resolve this conflict you should use delayed initialization of scroll bars in the CExtNCSB template class. This means you should invoke the constructor of the CExtNCSB template class explicitly. Here is how we did this in the FunnyBars sample application:

CChildView::CChildView()
            : CExtNCSB < CExtWS < CExtAFV < CFormView > > > ( CChildView::IDD, ((CWnd *)NULL), true )

Hi,

In a standard MFC application, the current displayed popup menu will be killed automatically when a modal dialog is displayed. But, in a Prof-Uis application, the standard popup menu (CMenu, not Prof-Ui menu) stays on and the application is locked. Neither the menu nor the modal dialog is responsive. Unless you click outside of the application, the menu is gone and then you can click the dialog. Is this prof-Uis bug?

You can easily reproduce the problem with the Prof-Uis sample "SDI" with the following code changes

Add a context menu and a Start Timer menu item. When the timer is fired, a modal message box is displayed. 

void CChildView::OnContextMenu(CWnd* pWnd, CPoint point)

{

    CMenu menu;

   

    menu.CreatePopupMenu();

    menu.AppendMenu(MF_STRING, 1, "Menu 1");

    menu.AppendMenu(MF_STRING, 2, "Menu 2");

    menu.AppendMenu(MF_STRING, 3, "Menu 3");



    menu.TrackPopupMenu(TPM_LEFTALIGN, point.x, point.y, pWnd);



}



void CChildView::OnTimer(UINT nIDEvent)

{

    AfxMessageBox("Hi");

   

    CWnd ::OnTimer(nIDEvent);

}



void CChildView::OnEditStarttimer()

{

    SetTimer(0, 5000, NULL);

}

 

Now, Run the application and click the Start Timer menu firstly then right-click the View area to display the propup menu and wait.

Please let me know if you can fix this problem or other suggestions? Thanks

Prof-UIS remembers any customized changes to toolbars and menus that a user may have made.  It remembers this info even if they haven’t made any changes (which is fine).

However, if we add a new control to a toolbar or menu, it won’t appear when our users download the new version.  Instead the old state of the toolbar has been remembered.  Also if we remove a control from the program, it is still remembered by the customization stuff, though it may no longer have an icon etc.

We don’t wish to over-write the user’s customization, but we do want changes that we make to show up in new versions.  This must be a common problem.  Is there a standard way to deal with it?

What would be great is if Prof-UIS handled this for us transparently, and I don’t think it would be hard.  All Prof-UIS needs to do is remember not just the current list of controls on a toolbar/menu, but also the original list of default controls.  When the program is run, if the new default list doesn’t match the stored default list, then you know exactly which controls have been removed or added to the program.  The customized state can be maintained, but any changes to the default are also added/removed automatically.

What do you think?  And any alternative solution in the meantime?

Thanks,

Rob.

Not sure about unregistering of old commands.  A command may be removed by us from a toolbar, but kept as a legacy item in the list of registered commands, even if it no longer appears in the interface by default (or at least not on that specific toolbar).

I don’t follow your statement that "Your new app should support all the commands of your previous app (this is important)".  This should not be required.

You just need to store the default arrangement of controls, eg the default set of buttons for a toolbar.  Then if this doesn’t match the new default setup, we know the change is from the developer not the user, and Prof-UIS knows which buttons to add, and which to remove.  Yes, if the user has re-ordered their buttons there’ll be some guesswork as to where new buttons go, but that’s fine.  Also, you know to remove a control if a command ID no longer exists at all (eg user put a button onto a toolbar it isn’t normally on, then developer removes the control).

What about my second post above?  Why after removing the button does it keep coming back?!

Thanks,

Rob.

Still interested in an answer to the above.  In the meantime I’ve been trying to get this to work for one specific case.  Luckily we are deleting an old control in addition to adding a new one, so we are able to recognise when the user’s customized state needs updating based on the presence of the old control.

When a user first uses the new version, which no longer has the old control, their customized state will bring it back regardless.  So after loading the customization, we look for the old control, and if found we replace it with a new one.  I have this working fine for a menu item, but on a toolbar it is doing something very strange.  It works, but even though the old control is no longer in the toolbar when they exit, it STILL writes out the old control into the customized state.  This old control then loads again next time (and our code once again replaces it with the new one).  I don’t get it.  Is the toolbar state cached somewhere and it’s writing out an old cache?  Even weirder, if the user drags some other control into the toolbar, this is remembered correctly in the customization (although it seems to move to a different place in the toolbar when reloaded), but our new control is STILL reverted back to the old one.  I’m pulling my hair out as none of this makes any sense.

To find and replace the old toolbar button after loading the serialization, we use something like this:

int index = bar->CommandToIndex(ID_OF_OLD_CONTROL);
if (index >= 0)
{
    // Delete the old button and add the new one.
    bar->RemoveButton(index, false);
    bar->InsertButton(index, ID_OF_NEW_CONTROL);
}

CExtCustomizeSite::CustomizeStateSerialize(archive);

Please shed some light on what I’m doing wrong.  How is it possible for my old button to keep coming back?!

Thanks,

Rob.

I am attempting to create my own application, and wanted an outer bar like you have in the MDI_DynamicInnerOuterBar sample.  I noticed that the app wizard for my new application put the following in the MainFrame::OnCreate()

[code]

In the MDI_DynamicInnerOuterBars example, the same block of code is:

[code]

I found that if I used the pApp->pszProfileName as it is used in the sample, I got an assert in CExtCmdManager::ProfileWndAdd() when it got pProfile:

[code]

pProfile would come back 0.  Looking at this in the debugger in the sample, it comes back with a value.

Initially, I didn’t care too much about it until I tried to create the outer bar and got the same assert in the same location when I created the bar and had this line a few lines later:

[code]

I assume there is something in the initialization of the main frame that I missed from the sample, but I can’t find it.  I have compared the code between the sample and my code and as far as I can tell, I’m doing all the same initialization.  What sets the value so pProfile is not NULL?

That did it. 

Thanks,

Bill

Hi,

We have users of our software complaining that the file menu is slow to respond when they move the mouse over an arrow to open a submenu.  We have a ribbon bar and one of those big file menus with the MRU list beside it.  When they move the mouse over an arrow, the submenu is slow to appear, and I think also slow to go away once they move elsewhere.  They described it as "sticky".  I can see that there’s a delay on my machine, but it’s not bad for me.  Has anyone else reported this?

Is a timer used between moving the mouse over a submenu-arrow and the submenu appearing?  Is there a way we can get rid of this?  That is, set the time to zero?

I also notice even when moving the mouse from one item with a submenu to the next item which also has a submenu, the MRU list flashes up in between which is distracting.  This doesn’t happen in MS Word.

Another observation: if you move the mouse over the arrow in a split-item, and keep the mouse moving within the arrow button, the submenu never comes up, not till you stop moving.  On non-split submenus this doesn’t seem to happen.  Again, this doesn’t happen in Word.

Another thing: when moving the mouse over a split item, but on the item side rather than the arrow, the MRU remains rather than showing the submenu.  The submenu only comes up if the mouse is moved over the arrow.  In Word, the submenu comes up even when moving to the item part, not just the arrow.  I think this makes more sense as the user can see their other options more easily.

Finally, when the file menu is closed, it can take a very long time to fade out when the software is busy with other things, eg because you just selected a large file from the MRU list.  I presume you’re using a Windows timer to fade out, and restarting it each time.  But these timers can take much longer than requested when the process is busy elsewhere.  A better approach would be to use timers, but to test the real time elapsed when the timer event arrives and skip ahead if more time has passed.

Oh, and one more thing before I forget.  We also had complaints about unpinned control bars sliding in and out far too slow.  The same logic would apply here.  Skip ahead if more real time has passed rather than replying on timer events which can take orders of magnitude longer to return than requested.  Alternatively, is there a way we can get rid of the animation here and make them slide in/out instantly?

Thanks,

Rob.

This occurred in Prof-UIS 2.90. The HTML engine is used for painting both plain text and HTML everywhere. The bad performance is caused by massive CSS style computations performed even for each word in plain text. We already fixed this issue. You should re-download the latest Prof-UIS 2.91.