Print Page | Close Window

[SOLVED]Button text replaced by toolkitpro text

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Command Bars
Forum Description: Topics Related to Codejock Command Bars
URL: http://forum.codejock.com/forum_posts.asp?TID=23783
Printed Date: 11 August 2020 at 8:04pm


Topic: [SOLVED]Button text replaced by toolkitpro text
Posted By: fleg
Subject: [SOLVED]Button text replaced by toolkitpro text
Date Posted: 12 December 2018 at 4:25am
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



Replies:
Posted By: rdhd
Date Posted: 15 June 2019 at 11:29am
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.


Posted By: astoyan
Date Posted: 16 June 2019 at 10:46am
This should be completely fixed in 19.0 beta 1 that is currently available for active subscribers. If possible please re-test it with the latest beta and confirm if it's fixed for you.


Posted By: fleg
Date Posted: 26 March 2020 at 3:36pm
Still happening with 19.1.0


Posted By: agontarenko
Date Posted: 20 April 2020 at 6:26am
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


Posted By: rdhd
Date Posted: 20 April 2020 at 3:10pm
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.


Posted By: agontarenko
Date Posted: 30 April 2020 at 4:50am
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



Print Page | Close Window