We have an issue with CodeJock resources. A number of strings have been added to all the XML and DLL resource files in recent releases. We have always excluded MFC and CodeJock IDs from our large set of command and string IDs. But now Codejock has added a lot of strings that clash with our IDs. One is 65062. When we load that control on the ribbon, CXTPControl will load "Icon" as the caption.

We cannot change our IDs as customers have been using our IDs for years to access and run commands by ID via automation. Now I have written a couple of resource manager classes to use CString::LoadString before calling to load a string that may be a CodeJock string for things like "Auto-hide" (docking pane) and "Close". Now I run the risk of getting an ID passed in for a CodeJock ID and having some MFC extension module load an incorrect string.

We know the MFC range of command IDs, but CodeJock seems to be adding IDs for commands or strings in an almost random way. We have avoided creating IDs that are in 9000 range such as are found in the CodeJock Resource.h file. But, what is the correct strategy? What range of IDs do we need to avoid and where can we find something like a #define that specifies what range of IDs are "reserved" for CodeJock?

Update - Well rats. Subclassing from CXTPResourceManager and calling CString::LoadString first doesn't work except for English because CodeJock loads the toolkitpro DLL with English resources into the MFC module chain. So for command clashes we get our strings (localized or not) since we always set the MFC resource handle anytime we need a resource to avoid MFC finding a "random" resource instead of ours. But, when CodeJock makes a call to get a resource of its own, calling CString::LoadString first doesn't work. Instead of first making the CodeJock resource module that active Afx resource module, Codejock has been relying on the CXTPResourceManager::LoadString API to just get its own handle via the GetResourceHandle method and then using it to try and load the string. I see the "Redo" and "Undo" methods that save/set/reset the AFX resource handle but when CJ is making calls to get one of its own resources, those are not being called or at least not being called consistently.

I found found a number of resource.h files that have #defines for ranges (but not for 65062 and all those new string IDs added).

So, my derived resource manager classes have to examine the input ID and see if it falls in the ranges defined in the ribbon/tabmanager/dockingpane/commandbars resource.h files.

But then I found the MDI tab workspace is still showing "Active Files" for French. I have found that in the resource DLL and XML file for French, CJ has left the entry untranslated. Guess I got lucky to find this as all the xml files but French are translated.

Should be Fichiers actifs

Our version is 19.3. Perhaps it is fixed in a later version. If not, please translate the string.

Hello,

Since CJ 19.1 or 19.2 versions we included microsoft language resources into CJ. Reason of this step problems with localizations in different users. For example: if customer loaded ToolkitPro.ResourceRu.dll library some button text and tooltip can be english language.

May be this is reason of your problem.
Try to remove microsoft *.rc files from codejock rc files.
"ToolkitPro\Source\Common\res\Resource_ru.rc"

// TODO: use l.rus depending on VC version
#if _MSC_VER <= 1500
    #include <afxctl.rc>
    #include <afxdb.rc>
    #include <afxolecl.rc>
    #include <afxolesv.rc>
    #include <afxprint.rc>
    #include <afxres.rc>
#else
    #include <l.rus/afxctl.rc>
    #include <l.rus/afxdb.rc>
    #include <l.rus/afxolecl.rc>
    #include <l.rus/afxolesv.rc>
    #include <l.rus/afxprint.rc>
    #include <l.rus/afxres.rc>
#endif

#ifdef _XTP_INCLUDE_MFC_STRINGS
#include "Common/res/mfc/l.rus/indicate.rc"
#include "Common/res/mfc/l.rus/prompts.rc"
#endif

Regards,

Artem Gontarenko

We are using the XML files. But, I do fall back on the DLLs if the XML files cannot be loaded. For the DLL case, I think the issue is that CJ doesn't play the AFX_MANAGE_STATE module state game. Nor does it get the active MFC resource handle, set its own, get the resource needed, and then reset the original one. I see the CJ resource manager has methods that appear to be written to do just that but they are not called when, for example, CJ needs to get the "Auto hide" string for a docking pane. Instead, CodeJock gets its own module handle when retrieving a resource and looks for the resource first in that module and then if not found, it calls CString::LoadString. That call relies on the MFC extension module paradigm to find a resource.

When we build our ribbon, we set our resource handle and create controls. When we call SetID on a control, the CJ code goes to the resource manager and asks for the string. So, when there is a clash of IDs, CJ gets the string from its resource file instead of ours.

I found a post I made a number of years ago on the CJ forums and what I did then was to remove all the entries in the CJ HTM files. This time, I wrote two subclasses of the CJ XML res manager and the DLL based res manager. At first I tried to call CString::LoadString first in the DLL based subclass and if the resource was not found, I called the base class. But, when running with a lang like Russian, CJ strings like "Auto hide" are found in the toolkit pro DLL as it is in the MFC extension module chain. And, it is English, not Russian. So, I added code that first checks the ID against "known" CJ resources defined in various resource.h files (command bars, docking panes, tab manager ...). If one of those IDs comes along, I go to the base class method to get the resource. Otherwise, I call the CString method.

We have always avoided IDs < 10000 as that is where we find most of the CJ resource IDs. It is these other IDs that got added that are causing issues. I didn't try to track down where, for example, 25062 came from (Icon in English) so it might be a MFC ID.

I think all the issues would have been more easily avoided for us if when CJ needs something like a tab manager resource or a docking pane resource like "Auto hide", it had just pushed the CJ localized resource module into the AFX res handle (AfxSetResourceHandle) and called CString::LoadString. I could avoid my big "if" statement in that case. When registering the extension module, CJ should also be registering the localized resource handle or not adding the Toolkit pro DLL as a resource as it is always English.

We happen to support any language on any OS by examining the system locale. We also let a user set an option for "English" even when the system is set to another language. We load our localized resource and do not mix both English and another language. Works well for us but we do have to use the AFX module macro or call AfxGetResourceHandle, AfxSetResourceHandle, get the resource and then AfxSetResourceHandle (to restore the original one). This also works well with add-ins written in Visual Studio c++ as we avoid loading our resources when an add-in want's one of its own. The add-in has to use the AFX manage state macro too, of course.

Hello,

Some time ago users have a got problem - for example they load CJ french language file, but some text of standart menu or standart messages stayed by english.

Regards,

Hi Artem,

I understand well the MFC issue. We have been working with MFC since the VC 6 days. We too support a lot of languages and we solved the MFC issue long ago for ourselves. I understand CJ trying to fix the issue globally. I'll continue to fix this issue too.