CodeJock changed Codejock.ttf so that it is now incompatible with the font used in 20.1 and earlier. So, now I have an issue. It turns out that there are other applications besides the one I work on that use CodeJock. If a user installs one of them that uses a version of CodeJock that has the font that is incompatible with ours, one of the applications displays the UI incorrectly. For example, see the image below where the expand/flyout element becomes a "1". User's can reverse the order of the installation of such apps to break one or the other.

How is this being handled by other applications being built using CodeJock?

My solution was to rename the font files (to reflect that they are different versions) and then embed them into my application resources.

I load the font from resources during InitInstance (using AddFontMemResourceEx).

Hi Markr,

Forgive me for I do not font. So, I'm a bit confused. I don't have this font in the system font folder on my dev box. I have found CXTPPrimitiveDrawer::InitMemFont by following the trail of "codejock.ttf" searches. That led me to XTP_IDC_FONT_CODEJOCK, which is a RT_FONT resource.

If I skip loading it, I find the display issues since the font isn't available. So, it appears that CJ already has the font in a resource file. I can do what you said and rename the string that XTP_IDC_FONT_CODEJOCK references and rename the file on disk. Then build the CJ DLLs (debug and release).

Is that what you did?

But I don't understand how the system font folder comes into play! Can you clue me in on that?

We do nothing special with the Codejock.ttf font. We don't install that Codejock.ttf font on your system ourselves and therefore older versions of our application using older versions of XTP work side by side.

If I manually install an older version of Codejock.ttf on my system, or something else does, everything using different versions of XTP has this symbol drawing issue. I guess the fix is to just not have the Codejock.ttf font installed on my system.

I'm guessing CreateFont prefers Codejock.ttf from the system (if it is installed) over the mem font XTP adds from its internal font resource. The latter should probably be preferred since it would match the current version of XTP. Looks like someone else had the same issue here:

https://stackoverflow.com/questions/55978791/how-to-prefer-font-that-is-loaded-by-addfontmemresourceex-than-system" rel="nofollow - https://stackoverflow.com/questions/55978791/how-to-prefer-font-that-is-loaded-by-addfontmemresourceex-than-system

But that seems like a roundabout way to fix it.

Hope that helps... :(

Hi dbrookes,

That explains why the font loaded can be an incompatible one. I have no choice here as I cannot control what other applications install. I can double click the .ttf file in the CJ source and it opens in some editor. But, I cannot change the font face name using it. Changing the name of the .ttf file won't make a difference but changing the font face name should.

I have not found a way to do that with Visual Studio nor have I found an exe in the CJ Utils folder that will let me edit the font face name.

Also, since I'm a developer, I don't even have the codejock.ttf file in my system font folder. I see no reason to even install it there with our app since it is an embedded resource. I saw in the MSDN (Learn) for AddFontMemResourceEx that said it is private to the process though CreateFont is used after that to actually create and get the font handle. I'm hoping that if it isn't in the system font folder, two apps can reside on the same box with no issue even if they are using the two incompatible fonts.