Hello,

Thanks for reporting the issue. Please check your private messages for a potential solution and confirm if it works. Once confirmed, the changes will be integrated to the next update.

Regards,

   Alexander

I see this once in a while. I am starting up a debug session and open one of our files. The app hangs. take a look at this code:

_XTP_EXT_CLASS CXTPSkinManager* AFX_CDECL XTPSkinManager()
{
    XTP_SKINFRAMEWORK_GLOBALLOCK_SHARED_SCOPE();

    if (CXTPSkinManager::s_pInstance == NULL)
    {
        CXTPSkinManager::s_pInstance = &XTPSkinManagerSingleton::Instance();
    }

    return CXTPSkinManager::s_pInstance;
}

Note this line:

    XTP_SKINFRAMEWORK_GLOBALLOCK_SHARED_SCOPE();

On the main thread the stack is:

     ToolkitPro2410vc170x64UD.dll!CXTPSimpleCriticalSection::Enter() Line 100    C++
     ToolkitPro2410vc170x64UD.dll!CXTPSimpleCriticalSection::CLock::CLock(CXTPSimpleCriticalSection & cs) Line 169    C++
     ToolkitPro2410vc170x64UD.dll!CXTPRWCriticalSection::LockShared(int bPopMode) Line 327    C++
     ToolkitPro2410vc170x64UD.dll!CXTPRWCriticalSection::LockShared() Line 227    C++
     ToolkitPro2410vc170x64UD.dll!CXTPRWCriticalSection::CSharedLock::CSharedLock(CXTPRWCriticalSection & cs) Line 311    C++
>    ToolkitPro2410vc170x64UD.dll!XTPSkinManager() Line 914    C++

In the Enter() function I am stuck in this loop:

            while (0 != m_nLock)
            {
                Sleep(dwTimeout);
                if (dwTimeout < XTP_SYNC_MAX_EXPONENTIAL_TIMEOUT)
                {
                    dwTimeout <<= 1;
                }
            }

Examining the plethora of ToolkitPro worker threads I find this one:

Notice that thread is also calling:

XTP_EXT_CLASS CXTPSkinManager* AFX_CDECL XTPSkinManager()
{
    XTP_SKINFRAMEWORK_GLOBALLOCK_SHARED_SCOPE();

    if (CXTPSkinManager::s_pInstance == NULL)
    {
        CXTPSkinManager::s_pInstance = &XTPSkinManagerSingleton::Instance();
    }

    return CXTPSkinManager::s_pInstance;
}

Setting breakpoints I see the main thread is in the loop. Meanwhile the second thread never returns from the RtlpWaitOnCriticalObject.

Since we have entered idle processing and we are a COM app, the OS is freeing unused libraries. That goes thru _AfxCrtDumpClient which is what the main thread is hooking into when memory leak detection is running and the call to get the mscoree.dll is made:

void __cdecl _AfxCrtDumpClient(void * pvData, size_t nBytes)
{
    if(_CrtReportBlockType(pvData) != _AFX_CLIENT_BLOCK)
        return;
    char sz[256];
    CObject* pObject = (CObject*)pvData;
    bool fCLRPresent=(::GetModuleHandleW(L"mscoree.dll")!=NULL);

All other ToolkitPro threads look standard and are all "small stacks" waiting on an object.

When this happens all I can do is restart.

Hi;

In my case I have a CXTPResizeDialog based window (contained in an AFX extension DLL). 
Inside the dialog ressource I have a CXTPTabControl and a large toolbar (CXTPToolbar) on top.
The tab control with three pages includes another three dialogs that are dynamically created and added to the three tab pages inOnInitDIalog of the parent dialog.

That's all. With this scenario the disabled items within the child dialogs of the tab controls cannot be read - as shown in my initial screenshot.

 

I have not been able to delve into this yet as I don't have a touchscreen. We have customers that are reporting that when we apply a skin touchscreen gestures no longer work. So, for example, pinch zoom and other functionality we support via WM_GESTURE/NOTIFY, WM_POINTERDOWN/UP/UPDATE and WM_TOUCH are all failing.

I previously posted about failures due to the DDEMLEvent window class not being filtered out and that I fixed that issue by adding my own filter. I am guessing that touchscreens support involves a window that is between "normal" windows that handles and forwards messages to the application.

Has anyone else noticed issues with skinning and gestures on touchscreens?

I also suspect the Microsoft Inking system would have issues too and will be looking into that since I think Inking and touchscreen support probably use the same underlying Windows technology.

Hello,

I've tested checkbox control with Office 2010 black theme in RibbonSample (v24.2). 
I add this code for test and any problem has not found. All works as expected.
m_chkPreview.SetCheck(TRUE);
m_chkPreview.EnableWindow(FALSE);
See please screenshot.

May be you have another case. How I can reproduce this bug with our sample?

Regards,

Artem Gontarenko

I saw somewhere a comment to report any class that causes an issue in the skinning framework. Well today we found one. The window class name is "DDEMLEvent" and we are running a DEBUG build where an assert is being thrown in IsImplementedInSystemWindowModule. That assert locks up our app due to calls in threads to WaitForSingleObject.

We assert and then lockup because the skinning system cannot find a window proc for this  class.

I asked my copilot why CJ could not find it. It examined the code in XTPSkinManager.cpp wheere SetHook tries to call AttachHook which eventually ends up in IsImplementedInSystemWindowModule where lpProc is nullptr. Then it said this:

1.    Ownership and Lifecycle:
The DDEMLEvent window is created and managed by the operating system, specifically for DDEML's internal event handling. Its window procedure is private to the system DLLs (such as user32.dll), and not exposed for external use or modification.

2.    No Public API:
Microsoft does not provide any documented API to retrieve, replace, or subclass the window procedure for DDEMLEvent. The class is not registered by application code, and its window proc is not accessible via standard Win32 APIs.

3.    Isolation for Stability:
By keeping the window procedure internal, Windows ensures that DDEML's event handling remains stable and secure. Allowing external frameworks to hook or replace the window proc could introduce instability or security risks.

4.    Framework Design:
Codejock and similar frameworks are designed to skin, subclass, or hook windows that are created by the application or by standard controls (e.g., buttons, edit controls, etc.). They rely on being able to access and replace the window procedure, which is not possible for system-managed classes like DDEMLEvent.

Summary:
Codejock cannot use or subclass the window proc for the DDEMLEvent class because it is a system-internal window class with a private window procedure, not exposed or intended for use by application frameworks. This is by design in Windows to protect internal event handling mechanisms.

I added the class name to the filtering system to avoid the lockup. This seems like a case where CJ just wants to avoid touching that class.

I found that scrolling the view resulted in OnHookDrawThemeBackground to bypass the skinning code because the DC has no hWnd associated with it and IsDCSkinned(hDC) returned FALSE. I have to apply the xtpSkinApplyDCs skin option before invoking the dialog. Unfortunately for me, that causes all windows to repaint when I apply it and also when I remove it. Apparently I never set that option when we start up because when I first worked with skins, it wasn't available. And we decided back then to not use CJ skinning as we were just experimenting with them.

Basically our app originally set the same options CJ does in the skin manager ctor and I used that to change the options to observe the skinning effects.

I also see a xtpSkinApplyCommandBarsFrame option is now available. But we skin the frame and CJ indicates the two are incompatible.

Here is an image of the dialog when first launched and then right after I scroll the mouse wheel.

When we apply our skin and display a CDialog that has a CCheckListBox in it we initially see the skin applied to all the items in the list box. But scroll the mouse wheel and the items draw incorrectly. The items draw using the system theme. Checking and unchecking items result in them redrawing using the skin. I thought CJ skinning was categorized as Visual C++ MFC meaning it works well with MFC. CCheckListBox is a MFC class but it does do custom drawing. In the image I am going to (try) and paste here one can see our theme background and the theme text color. But the "View 1" checked box is drawn using the system theme. "Front" is not checked and is using the system theme. "Back" is checked and uses the skin (yes the check box is quite pixelized as we wait and hope for SVG support for check/radio button). The other white boxes are system themed. "Dimetric" is unchecked and using our skin. I got this image by launching the dialog and then checking elements. Then I scrolled. After that I unchecked and checked "Back" and then unchecked "Dimetric".

How do I address this issue?