Forum

Dear Support,

I try to create a cell with these three - icon, check-box and radio button. I see that theck check-box and radio-button are mutuly exclusive - is this correct? can this be changed?

Thanks,

Ron.

Dear Support,

We have an MDI application, teh QA found a bug in it, that if they open many views, and then close them very fast, until they are all closed, and repeat that operation several times, the application crashed.

I was able to reproduce it in our application very easily, but not in the MDI sample application. However, it seems very Prof-UIS related, so I post here the stack. Can you please take a look and tell me how I can prevent it, or what is the source of the problem?

The assertion we get in the trace window is this:

 




Second Chance Assertion Failed: File f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\wingdi.cpp, Line 716




Many thanks,

Ron.

     ntdll.dll!7c90120e()    

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

>    msvcr80d.dll!_CrtDbgBreak()  Line 89    C

     msvcr80d.dll!_VCrtDbgReportA(int nRptType=2, const char * szFile=0x781df018, int nLine=716, const char * szModule=0x00000000, const char * szFormat=0x00000000, char * arglist=0x001251e4)  Line 290    C

     msvcr80d.dll!_CrtDbgReportV(int nRptType=2, const char * szFile=0x781df018, int nLine=716, const char * szModule=0x00000000, const char * szFormat=0x00000000, char * arglist=0x001251e4)  Line 300 + 0x1d bytes    C

     msvcr80d.dll!_CrtDbgReport(int nRptType=2, const char * szFile=0x781df018, int nLine=716, const char * szModule=0x00000000, const char * szFormat=0x00000000, ...)  Line 317 + 0x1d bytes    C

     mfc80d.dll!AfxAssertFailedLine(const char * lpszFileName=0x781df018, int nLine=716)  Line 25 + 0x14 bytes    C++

     mfc80d.dll!CDC::SetLayout(unsigned long dwSetLayout=0)  Line 716 + 0x18 bytes    C++

     ProfUIS284md.dll!CExtMemoryDC::__InitMemoryDC(CDC * pDC=0x00125338, const CRect * pRect=0x00125354, unsigned long dwOptFlags=3)  Line 97    C++

     ProfUIS284md.dll!CExtMemoryDC::CExtMemoryDC(CDC * pDC=0x00125338, const CRect * pRect=0x00125354, unsigned long dwOptFlags=3)  Line 222    C++

     ProfUIS284md.dll!CExtMiniDockFrameWnd::OnNcPaint()  Line 1195 + 0x15 bytes    C++

     mfc80d.dll!CWnd::OnWndMsg(unsigned int message=133, unsigned int wParam=0, long lParam=0, long * pResult=0x001254dc)  Line 2028    C++

     mfc80d.dll!CWnd::WindowProc(unsigned int message=133, unsigned int wParam=0, long lParam=0)  Line 1741 + 0x20 bytes    C++

     ProfUIS284md.dll!CExtMiniDockFrameWnd::WindowProc(unsigned int message=133, unsigned int wParam=0, long lParam=0)  Line 2357 + 0x14 bytes    C++

     mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x09fc13f0, HWND__ * hWnd=0x0007199a, unsigned int nMsg=133, unsigned int wParam=0, long lParam=0)  Line 240 + 0x1c bytes    C++

     mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x0007199a, unsigned int nMsg=133, unsigned int wParam=0, long lParam=0)  Line 389    C++

     mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x0007199a, unsigned int nMsg=133, unsigned int wParam=0, long lParam=0)  Line 411 + 0x15 bytes    C++

     user32.dll!7e418734()    

     user32.dll!7e42bdf1()    

     user32.dll!7e428ea0()    

     user32.dll!7e428eec()    

     ntdll.dll!7c90e453()    

     user32.dll!7e4194be()    

     user32.dll!7e42c174()    

     user32.dll!7e42f40b()    

     mfc80d.dll!CWnd::SendMessageA(unsigned int message=133, unsigned int wParam=0, long lParam=0)  Line 42 + 0x42 bytes    C++

     ProfUIS284md.dll!CExtMiniDockFrameWnd::OnNcActivate(int bActive=0)  Line 1472    C++

     mfc80d.dll!CWnd::OnWndMsg(unsigned int message=134, unsigned int wParam=0, long lParam=0, long * pResult=0x00125900)  Line 1890 + 0xd bytes    C++

     mfc80d.dll!CWnd::WindowProc(unsigned int message=134, unsigned int wParam=0, long lParam=0)  Line 1741 + 0x20 bytes    C++

     ProfUIS284md.dll!CExtMiniDockFrameWnd::WindowProc(unsigned int message=134, unsigned int wParam=0, long lParam=0)  Line 2357 + 0x14 bytes    C++

     mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x09fc13f0, HWND__ * hWnd=0x0007199a, unsigned int nMsg=134, unsigned int wParam=0, long lParam=0)  Line 240 + 0x1c bytes    C++

     mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x0007199a, unsigned int nMsg=134, unsigned int wParam=0, long lParam=0)  Line 389    C++

     mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x0007199a, unsigned int nMsg=134, unsigned int wParam=0, long lParam=0)  Line 411 + 0x15 bytes    C++

     user32.dll!7e418734()    

     user32.dll!7e418816()    

     user32.dll!7e428ea0()    

     user32.dll!7e428eec()    

     ntdll.dll!7c90e453()    

     user32.dll!7e4194be()    

     user32.dll!7e42c174()    

     user32.dll!7e42f40b()    

     mfc80d.dll!CWnd::SendMessageA(unsigned int message=134, unsigned int wParam=0, long lParam=0)  Line 42 + 0x42 bytes    C++

     mfc80d.dll!CMiniFrameWnd::OnFloatStatus(unsigned int wParam=8, long __formal=0)  Line 224    C++

     mfc80d.dll!CWnd::OnWndMsg(unsigned int message=877, unsigned int wParam=8, long lParam=0, long * pResult=0x00125d20)  Line 2004 + 0x11 bytes    C++

     mfc80d.dll!CWnd::WindowProc(unsigned int message=877, unsigned int wParam=8, long lParam=0)  Line 1741 + 0x20 bytes    C++

     ProfUIS284md.dll!CExtMiniDockFrameWnd::WindowProc(unsigned int message=877, unsigned int wParam=8, long lParam=0)  Line 2357 + 0x14 bytes    C++

     mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x09fc13f0, HWND__ * hWnd=0x0007199a, unsigned int nMsg=877, unsigned int wParam=8, long lParam=0)  Line 240 + 0x1c bytes    C++

     mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x0007199a, unsigned int nMsg=877, unsigned int wParam=8, long lParam=0)  Line 389    C++

     mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x0007199a, unsigned int nMsg=877, unsigned int wParam=8, long lParam=0)  Line 411 + 0x15 bytes    C++

     user32.dll!7e418734()    

     user32.dll!7e418816()    

     user32.dll!7e428ea0()    

     user32.dll!7e428eec()    

     ntdll.dll!7c90e453()    

     user32.dll!7e4194be()    

     user32.dll!7e42c174()    

     user32.dll!7e42f40b()    

     mfc80d.dll!CFrameWnd::NotifyFloatingWindows(unsigned long dwFlags=8)  Line 515    C++

     mfc80d.dll!CFrameWnd::OnActivate(unsigned int nState=0, CWnd * pWndOther=0x09fd5d98, int bMinimized=0)  Line 985    C++

     mfc80d.dll!CWnd::OnWndMsg(unsigned int message=6, unsigned int wParam=0, long lParam=858492, long * pResult=0x00126170)  Line 2105    C++

     mfc80d.dll!CWnd::WindowProc(unsigned int message=6, unsigned int wParam=0, long lParam=858492)  Line 1741 + 0x20 bytes    C++

     mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x08f85408, HWND__ * hWnd=0x001915b6, unsigned int nMsg=6, unsigned int wParam=0, long lParam=858492)  Line 240 + 0x1c bytes    C++

     mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x001915b6, unsigned int nMsg=6, unsigned int wParam=0, long lParam=858492)  Line 389    C++

     mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x001915b6, unsigned int nMsg=6, unsigned int wParam=0, long lParam=858492)  Line 411 + 0x15 bytes    C++

     user32.dll!7e418734()    

     user32.dll!7e418816()    

     user32.dll!7e42a013()    

     user32.dll!7e42a998()    

     ProfUIS284md.dll!CExtHookSink::HookChains_t::HookChainsWindowProc(unsigned int nMessage=6, unsigned int & wParam=0, long & lParam=858492)  Line 227 + 0x20 bytes    C++

     ProfUIS284md.dll!CExtHookSink::HookChains_t::g_HookWndProc(HWND__ * hWnd=0x001915b6, unsigned int nMessage=6, unsigned int wParam=0, long lParam=858492)  Line 291 + 0x14 bytes    C++

     user32.dll!7e418734()    

     user32.dll!7e418816()    

     user32.dll!7e428ea0()    

     user32.dll!7e428eec()    

     ntdll.dll!7c90e453()    

     user32.dll!7e42b11e()    

     user32.dll!7e43ada0()    

     user32.dll!7e418734()    

     user32.dll!7e42413c()    

     user32.dll!7e423b30()    

     user32.dll!7e43e577()    

     mfc80d.dll!CThreadSlotData::GetThreadValue(int nSlot=0)  Line 265    C++

     user32.dll!7e43e599()    

     user32.dll!7e418734()    

     user32.dll!7e43e577()    

     user32.dll!7e43e577()    

     user32.dll!7e418816()    

     user32.dll!7e43e577()    

     user32.dll!7e43e577()    

     user32.dll!7e418b26()    

     user32.dll!7e42a013()    

     user32.dll!7e43e577()    

     user32.dll!7e42a998()    

     user32.dll!7e43e577()    

     mfc80d.dll!_AfxActivationWndProc(HWND__ * hWnd=0x0012675c, unsigned int nMsg=1206372, unsigned int wParam=2017153533, long lParam=0)  Line 425 + 0x1a bytes    C++

     user32.dll!7e43e577()    

     user32.dll!7e418734()    

     user32.dll!7e418816()    

     user32.dll!7e428ea0()    

     user32.dll!7e428eec()    

     ntdll.dll!7c90e453()    

     user32.dll!7e4194be()    

     user32.dll!7e42c174()    

     user32.dll!7e42651a()    

     user32.dll!7e42b372()    

Please use on stack local GDI objects:

CDC & dc = . . .
CPen pen( . . . );
CPen * pOldPen = dc.SelectObject( &pen );
            . . .
            dc.SelectObject( pOldPen );

Then carefully check everything is restored (old GDI objects are selected finally). It’s a good style to restore selected objects in the exactly inversive order. Please do not invoke C++ operators like return, break or throw if they can affect to non restored GDI handles.
If you are using GDI handles like HBRUSH, HPEN, HGDIOBJ instead of MFC wrapper classes, then please check their usage even more carefully. Such handles are used in the same way as their MFC wrapper classes, but you should not forget to destroy them using the ::DeleteObject() Win32 API. The HICON handles must be destroyed using the ::DestroyIcon() Win32 API - not the ::DeleteObject() API.
The HBITMAP handles are assumed as heavy GDI resources. Do not cache too much HBITMAP / CBitmap objects. Switching to the CExtBitmap objects allows you to allocate zero count of HBITMAP handles in your application. You can cache any number of CExtBitmap objects in your application. The HICON handles are typically eating more than one GDI handle. The CExtBitmap class can replace HICON handle because our bitmap supports alpha blending on any Windows OS. To draw CExtBitmap images you can use the CExtBitmap::Draw() or CExtBitmap::AlphaBlend() methods.

Here is the source code of the CDC::SetLayout() method where the assertion is occurred:

DWORD CDC::SetLayout(DWORD dwSetLayout)
{
            ASSERT(m_hDC != NULL);

            HINSTANCE hInst = ::GetModuleHandleA("GDI32.DLL");
            ASSERT(hInst != NULL);

            DWORD dwGetLayout = LAYOUT_LTR;

            AFX_GDISETLAYOUTPROC pfn;
            pfn = (AFX_GDISETLAYOUTPROC) GetProcAddress(hInst, "SetLayout");

            // If the API is availalbe, just call it. If it’s not available,
            // setting anything other than LAYOUT_LTR is an error.

            if (pfn != NULL)
                        dwGetLayout = (*pfn)(m_hDC, dwSetLayout);
            else if (dwSetLayout != LAYOUT_LTR)
            {
                        dwGetLayout = GDI_ERROR;
                        SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
            }

            return dwGetLayout;
}

We suspect the assertion line is the ASSERT(m_hDC != NULL); code. This means the memory based HDC handle was not created successfully inside the CExtMemoryDC class. So, this means it’s time to check the GDI handle leaks. The number of total GDI handles on NT systems is limited to 10000. If this limit is reached then all the font handles become referred to the System proportional font, most of bitmaps and icons are not painted on the screen, etc. But the HDC handles become not created successfully even at lower limit of GDI handles. Please run your application, open the Windows Task Manager, select the Processes tab page in it, make it displaying the Handles, Threads, User Objects and GDI Objects columns, select you application in the process list and try to take a look at the handle counts when you opening new MDI child frame windows and closing them. The numbers of handles may increase after you several times open/close particular MDI child frames, but finally, all the handle counts should become persistent. This means you will open and close MDI child frames and each time return to some check point state of your application, probably, with no MDI child frames opened at all. At this check point, the number of handles should be persistent.

Please provide us with some details about the view windows inside MDI child frames in your application. Do you use something painted from scratch? If yes, then please do not cache any GDI handles. Do not cache the bitmap handles, we have the CExtBitmap class for that and it’s handle less and fast. Do not cache pens, brushes, and, especially, HDC handles. This means your classes should not have properties like CDC m_DC; or CBrush m_brush;.

Hello.

A Prof-Dialog is not closed even if I double-click by Vista.

 

An example.

Dear Support,

We have the problem with the persistence of main frame window position on the multi monitor systems.

Currently we use three paint managers in our product：

      CExtPaintManagerStudio2008

      CExtPaintManagerOffice2007_R1

      CExtPaintManagerOffice2007_Black

Whith CExtPaintManagerStudio2008 all works correct. We can expand main frame window on two monitors

save it position and then restore main frame window position on new aplication start.

But with CExtPaintManagerOffice2007_R1 and CExtPaintManagerOffice2007_Black managers this only works if we uses one monitor.

On two monitors system the main frame position restores incorrect. It seems that this managers cant detected that we use

two monitors.

Can you notify us how we can avoid this problem.

Regards,

Gevork Odabashyan.

The issue is fixed.

http://www.prof-uis.com/download/forums/tmp/DRAWCLI-test-build-for-GevorkOdabashyan.zip

Please contact is via email to get the update.

I have a color menu on a toolbar button set as follows:

    pCmdItem->StateSetColor();

    pCmdItem->StateSetColorBtnDefault();

How do I set the color that is used when the "Default" button is pressed. CExtPopupColorMenuWnd has m_clrDefault but I can’t see how to set that and reading the documentation hasn’t provided an answer.

Thanks,

Neville http://www.surfulater.com

Hello.

About an accelerator key

When there is a focus in the following points,

Accelerator key information is not notified MainFrame side of.

Please teach a good method notified MainFrame side of.

Please ensure how you are initializing the CExtHookSpy interface. In order to receive CExtHookSpy::OnHookSpyKeyMsg() and CExtHookSpy::OnHookSpyPreTranslateMessage() virtual method invocations for keyboard messages, you should initialize a spy object with the __EHSEF_KEYBOARD flag in the dwEHSEF parameter of the CExtHookSpy::HookSpyRegister() method invocation. It’s not enough to create your class derived from the CExtHookSpy class. You should register your spy object using the CExtHookSpy::HookSpyRegister() method.

Hello.

It is troublesome to do public of Hook every one class.

In the following commands,

   m_hKeyboardHook =
	::SetWindowsHookEx(
	 WH_KEYBOARD,
	 _HookKeyboardProc, 
	 0,
	 ::GetCurrentThreadId()
	 );

I want to transmit an accelerator key to main Window.

If there is a good command, please teach it

You don’t need any keyboard hooks for that. The keyboard accelerators are not translated due to specific implementation of the CDialog::PreTranslateMessage() virtual function. You should implement your accelerator key pre-translation by overriding the PreTranslateMessage() virtual method in your dialog class.

Hello.

By the control units such as a dialog unit or the combo box , It is troublesome to incorporate Pretransmessage.

I want to handle all just to declare Hook.

Is it impossible?

 

Yes, this is possible. You should derive some of your classes from CExtHookSpy. If your class is also derived from any MFC/Prof-UIS class (CObject, CCmdTarget, CWnd . . .), then the MFC/Prof-UIS class must be the first in the list of parent classes (class CYourClass : public CObject, public CExtHookSpy { . . . };). Then you should invoke the HookSpyRegister( __EHSEF_KEYBOARD | __EHSEF_PRE_TRANSLATION ); code in your class constructor and the HookSpyUnregister( __EHSEF_KEYBOARD | __EHSEF_PRE_TRANSLATION ); code in your class destructor. If your class is CWnd-based and you want it to be a spy only when it subclasses really created and valid HWND handle, then you should invoke the HookSpyRegister( __EHSEF_KEYBOARD | __EHSEF_PRE_TRANSLATION ); code in the PreSubclassWindow() virtual method and the HookSpyUnregister( __EHSEF_KEYBOARD | __EHSEF_PRE_TRANSLATION ); code in the PostNcDestroy() virtual method (this is what the CExtShellTreeCtrl and CExtResizableDialog classes do). After that you can implement the CExtHookSpy::OnHookSpyPreTranslateMessage() virtual method.

You should check invocation routes for the PreTranslateMessage() and OnCmdMsg() virtual methods in your project.

Hello.

My intention is not handed down to you well.

Please download this.

http://ifreeta.dee.cc/20090403/SampleTabRibbon5bug.lzh

Please click Assert-Menu1 several times.

RibbonMenu changes dynamically.

 

Please click Assert-Menu2 several times next.

RibbonMenu changes dynamically.

However, Assert appears when you operate it several times.

( This phenomenon occurs in for release conspicuously )

I want you to repair this malfunction.

 

Thank you for the video file. Unfortunately it does not help much. We suspect this issue should be gone if you update the source code for the following method:

void CExtToolControlBar::_UpdateButton( int nIndex )
{
CWnd * pTarget = GetOwner();
            if( pTarget == NULL && ( ! m_bPresubclassDialogMode ) )
                        pTarget = GetParentFrame();
            if( pTarget == NULL )
                        return;
BOOL bDisableIfNoHandler = TRUE;
            if( pTarget->IsKindOf( RUNTIME_CLASS(CFrameWnd) ) )
                        bDisableIfNoHandler = ((CFrameWnd *)pTarget)->m_bAutoMenuEnable;
CExtBarButton * pTBB = _GetButtonPtr( nIndex );
            if( pTBB == NULL )
                        return;
            ASSERT_VALID( pTBB );
            pTBB->OnUpdateCmdUI( pTarget, bDisableIfNoHandler, nIndex );
}

Thank you very much for your advice.

The application works normally.

No. Do we need some more details about what should we do? What, where and how should we click? etc.

 

Hello.

I made reproduction Video.

 

http://ifreeta.dee.cc/20090408/avitest.avi

 

Part(1)

Please click a place shown in a figure many times.

A "Debug" version sometimes reappears.

Part(2)

You build application by release.

Please click a place shown in a figure many times.

Assert appears immediately.

Does not the Assert reappear?

 

Hello.

You are for release, and please test it

"assert" is frequent.

Hello.

Did the bug reappear?

Thanks

 

I’m having a problem with several dynamic control bars in my project.  They initially start out as a tabbed document.  When I switched them to docked, then I press the auto-hide button, I get the following assert in objcore.cpp:

CObject* AFX_CDECL AfxDynamicDownCast(CRuntimeClass* pClass, CObject* pObject)
{
    if (pObject != NULL && pObject->IsKindOf(pClass))
        return pObject;
    else
        return NULL;
}

>    mfc90ud.dll!CObject::IsKindOf(const CRuntimeClass * pClass=0x02670848)  Line 45 + 0x8 bytes    C++

     mfc90ud.dll!AfxDynamicDownCast(CRuntimeClass * pClass=0x02670848, CObject * pObject=0x03fcbb30)  Line 53 + 0x12 bytes    C++

-        pClass    0x02670848 {"CExtDynTabControlBar"}    CRuntimeClass *

+        m_lpszClassName    0x0265faf4 "CExtDynTabControlBar"    const char *

        m_nObjectSize    528    int

        m_wSchema    65535    unsigned int

        m_pfnCreateObject    0x01d98fe8    CObject * (void)*

        m_pfnGetBaseClass    0x01d8772f    CRuntimeClass * (void)*

+        m_pNextClass    0x00000000 {???}    CRuntimeClass *

+        m_pClassInit    0x00000000    const AFX_CLASSINIT *

-        pObject    0x03fcbb30 {CObject}    CObject *

+        __vfptr    0xfeeefeee    *

+        classCObject    {"CObject"}    CRuntimeClass

Any help would be greatly appreciated.

The call stack listing in your message tells that there was an attempt to access an incorrect pointer or damaged instance of a tabbed container control bar. But we have no idea how to repeat this issue with any of our sample applications dedicated to the dynamic control bars (such as SDI_DynamicBars or MDI_DynamicBars). In the most convenient case it should be possible to reproduce this issue with our sample applications if we know the exact sequence of user actions to reproduce it. Otherwise, you should try to find why it crashes in scope of your project. This can be done using several different attempts. First of all, please try to remember when the crash happens and what was changed in your project recently. If nothing comes to mind, you may want to comment out some parts of your project to find such the code combination when the app does not crash. In other words, this allows you to narrow the search..

Hi,

I upgraded from 2.82 to 2.84 and now I get a crash in my application whenever I click on the title bar, if for example I try to move the window.

The crash happens in "extncframe.cpp" line 3003 or 3012, as a result of a call to AfxGetThread() that returns a null handle.

Please let me know how to fix this.

BTW, I think all the users and you yourselves would benefit from a better "forums" application. The current one has very poor performance and the search is virtually unusable - maybe my answer is already in here somewhere, but because I can’t do an advanced search, I get a flood of irrelevant results and then I have no choice but to post my question and waste your time and mine.

Thanks,

Adrian

Please provide more details about the crash. Did you rebuild your project(s) completely after switching to Prof-UIS 2.84? The ::AfxGetThread() API invocations mentioned in your e-mail are performed by the algorithms of the CExtNCW template class, which implements drag-n-drop and resizing of the window with skinned non-client area (caption and borders). If the ::AfxGetThread() API returns NULL pointer, then the global instance of the CWinApp-derived class in not available. Such situation should never occur. But it can occur if you are using some MFC regular DLLs or MFC based ActiveX modules which do incorrect MFC state management.

- I rebuilt all components of the project.
- My project contains a thin exe and a bunch of dlls and all the dll exported functions call     AFX_MANAGE_STATE(AfxGetStaticModuleState());
- the main window is in fact a dialog which runs in its own thread (DoModal is called in a thread procedure) and it’s on this thread that the crash occurs
- the application works fine as long as I don’t click on the title bar,
- the application didn’t have this problem with 2.82.

Here’s the call stack in case it matters:


>    ProfUIS284md-RDE.dll!CExtNcFrameImpl::NcFrameImpl_PreWindowProc(long & lResult=0x00000000, unsigned int message=0x000000a1, unsigned int wParam=0x00000002, long lParam=0x01d70510) Line 3003 + 0x11    C++
    ProfUIS284md-RDE.dll!CExtNCW<CExtResizableDialog>::WindowProc(unsigned int message=0x000000a1, unsigned int wParam=0x00000002, long lParam=0x01d70510) Line 604 + 0x27    C++
    mfc71d.dll!AfxCallWndProc(CWnd * pWnd=0x0214bf40, HWND__ * hWnd=0x00391676, unsigned int nMsg=0x000000a1, unsigned int wParam=0x00000002, long lParam=0x01d70510) Line 241 + 0x1a    C++
    mfc71d.dll!AfxWndProc(HWND__ * hWnd=0x00391676, unsigned int nMsg=0x000000a1, unsigned int wParam=0x00000002, long lParam=0x01d70510) Line 389    C++
    ydownloaderlibd.dll!AfxWndProcDllStatic(HWND__ * hWnd=0x00391676, unsigned int nMsg=0x000000a1, unsigned int wParam=0x00000002, long lParam=0x01d70510) Line 53 + 0x15    C++
    user32.dll!7e418734()     
    user32.dll!7e418816()     
    user32.dll!7e42a013()     
    user32.dll!7e42a998()     
    ProfUIS284md-RDE.dll!CExtHookSink::HookChains_t::HookChainsWindowProc(unsigned int nMessage=0x000000a1, unsigned int & wParam=0x00000002, long & lParam=0x01d70510) Line 227 + 0x20    C++
    ProfUIS284md-RDE.dll!CExtHookSink::HookChains_t::g_HookWndProc(HWND__ * hWnd=0x00391676, unsigned int nMessage=0x000000a1, unsigned int wParam=0x00000002, long lParam=0x01d70510) Line 291 + 0x14    C++
    user32.dll!7e418734()     
    user32.dll!7e418816()     
    user32.dll!7e4189cd()     
    mfc71d.dll!CWnd::WalkPreTranslateTree(HWND__ * hWndStop=0x00161610, tagMSG * pMsg=0x00000001) Line 3123 + 0x14    C++
    user32.dll!7e4196c7()     
    mfc71d.dll!AfxInternalPumpMessage() Line 188    C++
    mfc71d.dll!AfxPumpMessage() Line 198    C++
    mfc71d.dll!CWnd::RunModalLoop(unsigned long dwFlags=0x00000004) Line 4566 + 0x5    C++
    ProfUIS284md-RDE.dll!CExtResDlg::_DoModalImpl() Line 6370 + 0xc    C++
    ProfUIS284md-RDE.dll!CExtResDlg::DoModal() Line 6314 + 0x10    C++
    ydownloaderlibd.dll!GUIDownloader::run(simlib::ThreadBase::ThreadContext * context=0x00000000) Line 1481 + 0x14    C++
    miscd.dll!simlib::ThreadBase::threadProc(void * p=0x02101ed0) Line 1457 + 0x38    C++
    msvcr71d.dll!_threadstartex(void * ptd=0x020ce7f8) Line 241 + 0xd    C
    kernel32.dll!7c80b713()


Thanks,

Adrian

We still suspect the MFC state is not managed correctly in your project. Please try to insert the following line of code at the beginning of the InitInstance() virtual method of the CWinApp-derived class in your EXE project:

CExt_ProfUIS_ModuleState::InitExtension( ::AfxGetAppModuleState() );

I did this and now I’m getting an assert - see the call stack below:

ProfUIS284md-RDE.dll!CExtResDlg::_DoModalImpl() Line 6337 + 0x19    C++
    ProfUIS284md-RDE.dll!CExtResDlg::DoModal() Line 6314 + 0x10    C++
    ydownloaderlibd.dll!GUIDownloader::run(simlib::ThreadBase::ThreadContext * context=0x00000000) Line 1481 + 0x14    C++
    miscd.dll!simlib::ThreadBase::threadProc(void * p=0x02184ac0) Line 1457 + 0x38    C++
    msvcr71d.dll!_threadstartex(void * ptd=0x020ce810) Line 241 + 0xd    C
    kernel32.dll!7c80b713()     


The assert line is

    ASSERT( hInst != NULL );


thanks,

Adrian

This is another report from you which can be related to the MFC state switching problem. First of all, please ensure the DLL which uses the RDE version of Prof-UIS invokes the CExt_ProfUIS_ModuleState::InitExtension( ::AfxGetStaticModuleState() ); code in its InitInstance() virtual method of the CWinApp derived class. If this is done, then it’s time to do experiments with your main EXE project. You should try creating configurations of your EXE project which do not load particular DLLs and find configuration which does not have reported problems.

Added this line to the dll project but I’m still getting the same assert.

Do you have an explanation why the application ran fine using 2.82 or lower, but not with 2.84? Any change in 2.84 that may cause this?

Adrian

Prof-UIS versions 2.82 and 2.84 are different. Some classes have new message handlers and hooks, some have removed. We have consultations with our customers related to all the possible Prof-UIS library configurations and the MFC state management issues are reported enough rarely. We suspect it’s hardly possible to code a test project which emulates this issue. So, it would be easier to connect to your desktop remotely and debug this issue in your real project.

I reverted everything to the orginal code that worked with 2.82 and set a breakpoint in AfxGetThread. This function gets called many times and it returns the right value every time. Only when I click on the title bar the call fails in the 2.84 dll as shown in the first stack trace above. All these tests and the fact that it worked with 2.82 make me believe that there is a bug in 2.84 that’s causing this call to fail.

Let me know if you need any more info from me to diagnose and fix this bug.

I would appreciate a quick resolution, as I am blocked by this issue.

Thanks,

Adrian

Is it possible to connect to your desktop remotely and debug this issue in your real project?

Yes, I believe we could do that. What software do you use for this, and when would you be available?

You can email me at the address in my account and we can arrange the details.

Thanks,

adrian

We received your e-mail. We can connect to your desktop at any convenient time for you. Please provide us with information about how to do this. You can use a service like www.logmein.com.

This is revised in PROF-UIS 2.85x

However, prof-uis2.84 has degrade.

Is this slightly fatal....  OnGridCellInputComplete does not work....  

Where do I get 2.85? It’s not on the downloads page.

There is Prof2.85x in the Ftp site of Prof.

For details, you please ask support by an email.   support@prof-uis.com 

 

Hello.

The triangle mark is displayed definitely by a sample program

However,

caption text is not displayed.

Please teach a good method.

 

In the following commands, the text was displayed

However, black is displayed with transparence color.

CRect rcDraw, rcExclude;

GetWindowRect( &rcDraw );

GetClientRect( &rcExclude );

ClientToScreen( &rcExclude );

rcExclude.OffsetRect( -rcDraw.TopLeft() );

rcDraw.OffsetRect( -rcDraw.TopLeft() );



CWindowDC dcWindow( this );

dcWindow.ExcludeClipRect( &rcExclude );

CExtMemoryDC dc( &dcWindow, &rcDraw, CExtMemoryDC::MDCOPT_TO_MEMORY | CExtMemoryDC::MDCOPT_FORCE_DIB );

dc.FillSolidRect( &rcDraw, RGB(0,0,0) );





CDC * pCDC = &dc;



//------------------------------------------------

INT nOldBkMode = dc.SetBkMode( TRANSPARENT );

COLORREF clrOldText = dc.SetTextColor( RGB(55,55,55) );



CString csStr;

GetWindowText( csStr );

UINT nFormat =

DT_SINGLELINE

// |DT_VCENTER

// |DT_CENTER

|DT_LEFT

|DT_TOP

;



dc.DrawText(

csStr,

csStr.GetLength(),

rcDraw,

nFormat

);

dc.SetTextColor( clrOldText );

dc.SetBkMode ( nOldBkMode );

 

You should paint the window caption text with a glow effect. The DrawText() API cannot help you. You should use the DrawThemeTextEx() API which is a feature of Windows Vista only. Besides, you need additional tricks like memory DC with negative height to draw Vista text. Please take a look at the source code of the CExtPaintManagerOffice2007_Impl::Ribbon_NcOverPaint() for details.

Hello.

I was able to display the title in Dmw.

 

However, White gradation is not displayed around a character.

I want you to teach a probable cause.

 

Thanks,

 

Here is how we painted the same text with a glow effect in the CExtPaintManagerOffice2007_Impl::Ribbon_NcOverPaint() method:

   static const int g_nDwmGlowSize2007 = 10;
            . . .
            CExtUxTheme::__EXT_UX_DTTOPTS dto = { sizeof(CExtUxTheme::__EXT_UX_DTTOPTS) };
            dto.dwFlags = __EXT_UX_DTT_TEXTCOLOR;
            dto.iGlowSize = g_nDwmGlowSize2007;
            if( pWnd->IsZoomed() )
            {
                        dto.crText = RGB(0x0FF,0x0FF,0x0FF);
            }
            else
            {
                        dto.dwFlags |= __EXT_UX_DTT_COMPOSITED | __EXT_UX_DTT_GLOWSIZE;
                        dto.crText = bFrameActive ? RGB(0,0,0) : RGB(0x060,0x060,0x060);
            }
            g_PaintManager.m_UxTheme.DrawThemeTextEx(
                        dc32.m_hDC,
                        0,
                        0,
                        strWindowText,
                        -1,
                        DT_SINGLELINE|DT_CENTER|DT_VCENTER|DT_NOPREFIX,
                        rcText,
                        &dto
                        );
            dc32.SelectObject( pOldFont );
            if( bRTL )
            {
                        dc.SetLayout( dwOldLayout1 );
                        dc32.SetLayout( dwOldLayout2 );
            } // if( bRTL )

The dto.iGlowSize = g_nDwmGlowSize2007; line of code specifies the size of glow in pixels.

Hello

When the icon of the dialogue is unestablished, it is displayed.

I want to acquire this standard icon.

Please teach a good method.

You should assign a window icon or remove the WS_SYSMENU style.

Hello.

I made a dynamic menu.

A menu increases and decreases when I push Dynamic-Menu1.

Assert appears when I push Dynamic-Menu2 many times.

In addition, when I test it in application for release.

The application does Assert immediately.

Please cope as soon as possible

I sent the source by an email.

 

How did you implement your dynamic menu?

We would recommend the following approach:

1) Create only one menu node in the popup menu displayed by the ribbon button. This menu node is called a menu marker item. It’s the menu command item and it should have some known ID_MY_REPLACE_CMD command identifier.

2) Handle the CExtPopupMenuWnd::g_nMsgPrepareMenu registered message like described here:

http://www.prof-uis.com/prof-uis/tech-support/faq/pop-up-menus.aspx#how-to-insert-menu-items-at-run-time

But you should handle it in your CExtRibbonBar-derived class instead of the main frame class.

Hello.

The dynamic menu is not a pop-up menu.

I make a ribbon menu display and non-display.

I ask for a test with a sample.

When I click a pop-up menu of Dynamic-Menu2.

Display and the non-display handling of ribbon menu run.

It is the same as Dynamic-Menu1.

However, when I carry it out in Dynamic-Menu2 many times

Fatal Assert appears.

It occurs by release frequently.  

I am troubled.  Give my best regards

 

Hello.

I want to always display CStatic on the front.

Please teach it if you know a good method.

 

I wonder if there is only the following programming technique.

LRESULT CSampleBkPaintDlg::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)

{

   LRESULT lRes = CDialog::WindowProc(message, wParam, lParam);



   if ( message == WM_MOUSEMOVE ){

       m_Static.Invalidate();

       m_Static.UpdateWindow();

  }

If you want to display some text in the CExtLabel window using custom font and/or color, you should use the CWnd::SetWindowText() method for assigning the label text and use the following methods of the CExtLabel class to customize label’s font and/or color:

   void SetFontBold( bool bSet = true );
            void SetFontItalic( bool bSet = true );
            void SetFontUnderline( bool bSet = true );
            void SetFontStrikeOut( bool bSet = true );
            void SetBkColor( COLORREF clrBk );
            void SetTextColor(
                        bool bEnabled,
                        COLORREF clrText = COLORREF(-1L)
                        );

If you need to change this parameters of the CExtLabel control on mouse hover, please handle the WM_MOUSEMOVE message in your CExtLabel-derived class.

Hello.

Even if I choose other control

In defiance of those drawing, I want to always display CStatic in the front row

If there is a good idea, please teach it.

 

Hello.

The drawing of the frame is abnormal.

The following phenomena occur when they use the following command in a certain application.

It does not reappear even if I make sample application.

Please teach a probable cause.

If you need the CExtEdit control with borders of the CEdit control, then you should simply use the CExtEditBase class instead of the CExtEdit class.

Hello.

This is a phenomenon caused in the application that I made.

Though it employs CExtEdit, the display such as CEdit becomes.

I want to know a clue.

Thanks

 

It’s really weird. If you instantiate and create a CExtEdit, then it should be themed by the Prof-UIS editor. If you instantiate and create a CEdit, then it should be themed by the Windows editor. In any case, to help you more efficiently, we need a test project or more details about your project.

Hello.

Not HowTo of enable

I want to inquire bounds drawing (a line) of EditBox

Though I use PaintManager of Prof-UIS

Drawing of CEdit is normal.

I want you to teach a probable cause.

Hello.

I do not understand CExtNCW how to use.

Please teach a merit to use CExtNCW .

The CExtNCW template class adds a themed caption and borders to a windows It implements a custom non-client area. Of course, the non client area is themed only if the currently installed paint manager supports this feature.

The CExtNCW class is a template decorator class. So, if you have the main frame or dialog declared as follows:

class CMainFrameOrDialog : public CExtNCW < CBaseFrameOrDialog >
{
            . . .
};

Then you should replace it with the code like below:

class CMainFrameOrDialog : public CBaseFrameOrDialog
{
            . . .
};

You should also replace the CBaseFrameOrDialog class type with the CExtNCW < CBaseFrameOrDialog > template based type everywhere in all the source code of each method of the CMainFrameOrDialog class included explicit constructor invocations of parent class:

CMainFrameOrDialog::CMainFrameOrDialog(  . . . some parameters . . . )
: CExtNCW < CBaseFrameOrDialog > (  . . . the same parameters or some other parameters . . . )  // parent class constructor invocation
{
            . . . constructor body . . .
}

You should leave the BEGIN_MESSAGE_MAP( CMainFrameOrDialog, CBaseFrameOrDialog ) as is without any changes - this is the single exception.

Dear Support,

We use CExtTabMdiWnd with these flags:__ETWS_EX_CLOSE_ON_TABS|__ETWS_EX_CLOSE_ON_SELECTED_ONLY and we observe two problem as you can see in the image below:

1. The ’x’ button is too close to the edge of the tab.

2. In all the tabs, regardless if the ’x’ is displayed, you save a place for it. We use the __ETWS_EX_CLOSE_ON_SELECTED_ONLY to save space, but it’s wasted anyhow...

Thanks,

Ron.

 

We sent you e-mail with the FTP download information. Yes, the bold selected tabs are supported, but this behavior is assumed as old and obsolete.

The "X" button position issue is fixed. Thank you. We can provide you with the source code update. The space is really always saved for the "X" button. This allows tab items to have equal sizes when selected and unselected.

for example in case of YES NO CANCEL message box, when I change the focus button with the key "TAB", the default button YES is always called by pressing key "RETURN"

if it can help you, in a normal dialog box, pressing the key "TAB" change the m_nButtonType to BS_DEFPUSHBUTTON In case of MessageBox the style does not change by pressing "TAB", and when pressing "Return" in line 1151 of extButton.cpp, the function searches for default button even if it has the focus!!!!

 

 

We used the DRAWCLI sample for testing this issue. We painted several objects in it and pressed Ctrl+F4 to close the active document. The Yes | No | Cancel message box is displayed and the VK_RETURN key works right in it. The default button is Yes and pressing it will display file saving dialog. If the No</n> button is focused and VK_RETURN is pressed, then the IDNO command is invoked. The same is with <b>Cancel button.

We suspect the problem can depend on particular message box styles. Please show us how you initialize your message box so we will test it.

I tested with DRAWCLI, and for me it does not work.

I work with VS2005 in MBCS debug on Window XP SP1.

I run drawcli, i create an objet, I press Ctrl+F4 and I press TAB (the NO button gets focus) I press RETURN and then few seconds after the Save As dialog open to prompt me for a filename to save.

It takes a few seconds probably because of the file selector initialisation.

run drawcli, Ctrl+O (wait the file selector) click Cancel. draw an item, press Ctrl+F4 press TAB and press RETURN. In that case the Saves AS file selector open immedialtly.

feel free to ask me any more information to reproduce the problem.

Regards,

 

I’ve been using the sample Prof-UIS Controls for 2.84 to learn the CExtShellDialogBrowseFor class usage.  I’ve noticed that I can only make a new folder when a folder is selected.  I can not create a new folder when a root drive, say c:, is selected.  Is there a way to create a new folder at the root?

Hello.

Because even one color is good, cannot I appoint the color of the frame?

Or,

I want you to emphasize the color of the frame more

Your should override the CExtPaintManager::PaintControlFrame() virtual method.

Hello.

Please teach a virtual function of the frame drawing.

Give my best regards.

 

There are no virtual functions for controlling the non client area of inner list box window inside the CExtComboBox window in the simple mode. The non client area of this list box is computed in the CExtComboBoxPopupListBox::WindowProc() method and this the single place to compute it as we did. We cannot change the non client area size, make it larger and paint some border in it because the combo box common control always over paints this non client area without notifications.

The behavior of the list box like window inside the combo box common control in simple mode is unpredictable. We can reserve border space around it and can re-paint it. But somehow it often becomes painted not through the window procedure.