CXTPPrimitiveDrawer::SVGLoad

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   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.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 894	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Topic: CXTPPrimitiveDrawer::SVGLoad Posted: 12 hours 58 minutes ago 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.

xsensordev Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 19 August 2021 Location: Canada Status: Offline Points: 27	Post Options Post Reply Quote xsensordev Report Post Thanks(0) Quote Reply Posted: 12 hours 16 minutes ago 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.

xsensordev Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 19 August 2021 Location: Canada Status: Offline Points: 27	Post Options Post Reply Quote xsensordev Report Post Thanks(0) Quote Reply Posted: 11 hours 60 minutes ago 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.

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 894	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 10 hours 9 minutes ago 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.