(Also, why does this menu always appear with the underscore characters visible?????)

 

Is there an easy way of replacing this and similar bitmaps (this one derives from tbar_hex.bmp) WITHOUT modifying the CodeJock source? I don't want to do that (even though it is easy to do) as that would mean having to remember to modify the resource files after every update.

 

I've tried just loading a bitmap with the same resource id into my own resource file, but that clearly isn't sufficient and does not do anything.

 

Try add modified bitmap to your resources and add

XTPResourceManager()->SetResourceHandle(AfxGetInstanceHandle());

 

With statically linked, afraid only replacing bitmap in our sources can help.

 

The trick is to point the resource compiler to a new directory where you place any edited resource files, replicating the CodeJock directory structure.

 

First, edit the properties for your project's resource file (.RC) and add a new directory to the include directory path--here you will place any edited bitmaps:

 

 

In this example I've added a subdirectory to my RES directory, which seems a suitable place for this.

 

Within this subdirectory, recreate any relevant directory stucture found in the CodeJock source directory--you only need to do this for any individual files that you wish to replace. For example, the bitmap used for the edit menu is found at Controls\res\tbar_hex.bmp. Therefore to replace just this file, I create a $(ProjectDir)RES\CodeJockReplace\Controls\res\tbar_hex.bmp file that uses the images I require. The magic of setting the include directory for the .RC file is that during compilation it will search for resource elements in that directory first and will only go to the default directories if nothing is found.

 

After putting an edited tbar_hex.bmp file there, the result in my application is as below:

 

 

Result! All edit controls within the application are now updated.

 

Repeat as required for any bitmap. The beauty is that there is no need to edit the CodeJock source, which means that nothing should break when new versions of the library are released.

 

But could you take a look to see why the edit control context menu ALWAYS shows the keyboard accelerators (the underlines on the menu text) even when the ALT key is not depressed. I looked through the code but could not find any reason that this should be happening.....

 

Yes, there is such thing :( Such context menu doesn't linked to any CXTPCommandBars so can't use its keyboardCuesShow option.

 

If you use CXTPEdit - you can create own class, copy OnContextMenu previous code, but instead XTFuncContextMenu call some pCommandBars->TrackPopupMenu.

 

 

I see that the CTTPEdit context menu is created with a NULL CXTPCommandBars* within XTFuncContextMenu() [Controls\XTFunctions.cpp].

 

If you rewrite this as below then the edit control context menu not only works properly, it allows the status bar text to be shown correctly when the menu is displayed (and you even get tool tips if enabled).

 

CXTPMDIFrameWnd* pMainWnd = DYNAMIC_DOWNCAST(CXTPMDIFrameWnd, AfxGetMainWnd()); CXTPFrameWnd* pFrameWnd = DYNAMIC_DOWNCAST(CXTPFrameWnd, AfxGetMainWnd()); CXTPCommandBars* pCommandBars = NULL; if (pMainWnd) {     pCommandBars = pMainWnd->GetCommandBars(); } else if (pFrameWnd) {     pCommandBars = pFrameWnd->GetCommandBars(); }   CXTPPopupBar* pPopupBar = CXTPPopupBar::CreatePopupBar(pCommandBars);

 

XTFunctions.cpp also needs to

#include <CommandBars\XTPFrameWnd.h>

for this to compile