Hi,

When upgrading from toolkipro version 18.4 to 18.6, I noticed a problem when creating a ribbon bar button that is using an standard window command ID (like ID_APP_EXIT, ID_FILE_NEW...)

For instance when doing

pXTPRibbonGroup->Add(xtpControlButton, ID_APP_EXIT);

With 18.4, it was getting the text from my own resource file, where I defined the corresponding text.

With 18.6, it seems now to get the text from a new resource file "prompts.rc" added to ...\Source\Common\res\mfc\

Is there a way to prevent that to happen, maybe with a magic _XTP_xxx macro?

I would prefer to avoid loading explicitely the text from my resource file.

Maybe commenting out some includes as suggested here could work:

http://forum.codejock.com/forum_posts.asp?TID=23752&KW=prompts&title=application-doesnt-start-after-upgrading-to-186" rel="nofollow - Application doesn't start after upgrading to 18.6

This is quite annoying as for some languages (spanish, portuguese...), I get english text instead of localized text

Any help would be very welcome.

Fabien

Hi fleg,

I have had this sort of issue before with other resources. The issue was a failure to make our resource handle the active handle (AfxSetResource...). MFC has a chain of extension DLLs and when searching for a resource, it first looks in the active resource. If it doesn't find it there, it then walks the list of extension DLLs looking for the first one that has a string with the input resource ID.

We just had to make sure we swapped the afx module data with our module data (usually we only set the afx resource handle). Perhaps, that is the issue here.

Hi fleg,

Unfortunately it is not clear what exactly is going wrong. Can you please provide more detailed information. If it cannot be re-produced in any of our sample applications provided a sample application so that we could debug it.

Regards,

Artem Gontarenko

I found with CJ 19 that the utils\translation files - both the DLLs and MXL files, have lots of new entries for common MFC commands and string (IDs). Some of the files are fully translated, some are not (for example, Spanish is not). Also, at startup CJ loads the toolkitpro DLL you are using as the resource file and it does NOT contain all the new entries. So, if you only load one into CJ for a foreign language file, English still works and other translations depend on the language. How CJ got out the door like this ...

I "fixed" this for our app by not loading the translation DLL file but the XML file instead. I also edited each XML file and deleted all the new entries. They start with <string id ="57347" ...> and run thru <string id ="65223" ...> - I eliminated them all with extreme prejudice.

Now we are back to only using our translations. We do translations for all the MFC commands we might use (app exit being one, file new ...) and the CJ translations don't match our own. If CJ ever adds these strings to the toolkit pro DLLs, I will do the same with the English XML file.

I only had 18.5. I never pulled 18.6, which is good if that is when CJ added all these non-translated and translated strings.

Hello,

I'm glad to inform you that the issue has been addressed and fixed. The fix will be available in the next beta or final release.

Regards,

Artem Gontarenko