Codejock Forums Homepage
Forum Home Forum Home > Codejock Products > Visual C++ MFC > Command Bars
  New Posts New Posts RSS Feed - [SOLVED]Button text replaced by toolkitpro text
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

[SOLVED]Button text replaced by toolkitpro text

 Post Reply Post Reply
Author
Message
fleg View Drop Down
Groupie
Groupie


Joined: 11 July 2012
Status: Offline
Points: 24
Post Options Post Options   Thanks (0) Thanks(0)   Quote fleg Quote  Post ReplyReply Direct Link To This Post Topic: [SOLVED]Button text replaced by toolkitpro text
    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:

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
Back to Top
rdhd View Drop Down
Senior Member
Senior Member
Avatar

Joined: 13 August 2007
Location: United States
Status: Offline
Points: 678
Post Options Post Options   Thanks (0) Thanks(0)   Quote rdhd Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
astoyan View Drop Down
Admin Group
Admin Group
Avatar

Joined: 24 August 2013
Status: Offline
Points: 205
Post Options Post Options   Thanks (0) Thanks(0)   Quote astoyan Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
fleg View Drop Down
Groupie
Groupie


Joined: 11 July 2012
Status: Offline
Points: 24
Post Options Post Options   Thanks (0) Thanks(0)   Quote fleg Quote  Post ReplyReply Direct Link To This Post Posted: 26 March 2020 at 3:36pm
Still happening with 19.1.0
Back to Top
agontarenko View Drop Down
Admin Group
Admin Group


Joined: 25 March 2016
Status: Offline
Points: 140
Post Options Post Options   Thanks (0) Thanks(0)   Quote agontarenko Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
rdhd View Drop Down
Senior Member
Senior Member
Avatar

Joined: 13 August 2007
Location: United States
Status: Offline
Points: 678
Post Options Post Options   Thanks (0) Thanks(0)   Quote rdhd Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
agontarenko View Drop Down
Admin Group
Admin Group


Joined: 25 March 2016
Status: Offline
Points: 140
Post Options Post Options   Thanks (0) Thanks(0)   Quote agontarenko Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down



This page was generated in 0.076 seconds.