Toolkit Pro - CXTPPrimitiveDrawer::SVGLoad

CXTPPrimitiveDrawer::SVGLoad

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
URL: http://forum.codejock.com/forum_posts.asp?TID=24544
Printed Date: 31 January 2025 at 12:06am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: CXTPPrimitiveDrawer::SVGLoad

Posted By: rdhd
Subject: CXTPPrimitiveDrawer::SVGLoad
Date Posted: 30 January 2025 at 2:49pm

I'm still investigating but it appears CXTPPrimitiveDrawer::SVGLoad is calling XTPLoadUnicodeText without resetting the system error. The latter will, in some cases like for CP_ACP will get GetLastError and exit.

SVGLoad has this code:

    HMODULE hModule = XTPResourceManager()->GetResourceHandle();

    HRSRC hRsrc = ::FindResource(hModule, MAKEINTRESOURCE(nIDResource), _T("RT_SVG"));
    if (NULL == hRsrc)
    {
        hModule = AfxFindResourceHandle(MAKEINTRESOURCE(nIDResource), _T("RT_SVG"));
        if (hModule == NULL)
            return FALSE;

        hRsrc = ::FindResource(hModule, MAKEINTRESOURCE(nIDResource), _T("RT_SVG"));
    }

The problem is the first call to ::FindResource is triggering error 1813. Not an issue itself since the code then calls AfxFindResourceHandle and the toolkitpro res handle is returned. If I bypass the GetLastError() call and return using the debugger the SVG loads fine.

The result is that our docking panes don't display the close (X) icon. Probably other elements used in painting have gone missing but this is the one our cert team found.

I'm going to call SetLastError(0) when the first call fails and it drops into the NULL hRsrc case. I think that should fix the issue for us.

Replies:

Posted By: xsensordev
Date Posted: 30 January 2025 at 3:31pm

I believe I'm experiencing the same issue.

Through trial and error I found in my case that its because I was overriding the default resource manager with a language resource dll via:

Examples:

XTPResourceManager()->SetResourceHandle("ToolkitPro.ResourceJa.dll");
XTPResourceManager()->SetResourceHandle("ToolkitPro.ResourceEn.dll");

It appears that there are no SVG resources within the DLL. If I remove this call, the various SVGLoad elements (close X, checkbox checkmark,etc) appear.

This is problemmatic is I now do not have non-English support for CodeJock resources.

Given that this is due to a change in v24 from prior versions (I was using 22.1 previously), I'm hoping Codejock can offer a suggestion as to how to support the behavior previously offerred by use of the ToolkitPro.ResourceXX.dlls.

Posted By: xsensordev
Date Posted: 30 January 2025 at 3:47pm

I think for my case I found the solution. Instead of the old resource DLLs, there are XML files that appear to support translations of the toolkit elements. This works for me:

if (!XTPResourceManager()->SetResourceManager(
new CXTPResourceManagerXML(L"ToolkitPro2400\\Utils\\Translations\\SuitePro.ResourceJa.xml")))

return FALSE;

I used the MultiLangCommandBars sample as a guide.

Posted By: rdhd
Date Posted: 30 January 2025 at 5:38pm

We set our own resource handle so it is "first" in the lookup chain. We have code that will use an XML file from CodeJock depending on the language. There are just some things in the past where our localization team and CodeJock don't agree.

In any case I added a call to SetLastError(0) in XTPLoadUnicodeText to fix our issue. CodeJock is relying on the system error and should be clearing it out in the code that looks for the resource when a resource is found. There were multiple calls to XTPLoadUnicodeText from CodeJock code and they call to find the resource was the same. Look in the primary DLL and if that fails use AfxFindResourceHandle to find on in the AFX DLL chain/list. That's why I decided to do it in XTPLoadUnicodeText. It looks like CJ only calls that API iff the resource was actually found.