I was trying to perform a bit of 'wizardry' to customize the 'tip' that appears in the status bar when you hover over a menu at runtime. Now, normally, this message is loaded at runtime, as needed, by a call to CFrameWnd::GetMessageString. So, off I went and did my customization in my derived frame window's GetMessageString class. But I use XTP's command bars and the integrated CXTPMenuBar class, and the "standard" solution didn't work.
After spelunking through the code, I found that the description is manually loaded once without calling GetMessageString and then cached inside each CXTPControl entry†. While I think I understand why XTP does things this way, I am of the
opinion that the design is flawed here: things don't really work as
expected, since the frame window's GetMessageString is never called and devs will be left scratching his head as to why that is, and how to solve it.
After spelunking through the XTP code I have come up with at three ways‡ to get around this issue; the most sensible solution in my opinion ends up requiring a message handler for WM_XTP_CONTROLSELECTED in the frame window and setting the description for the CXTPControl directly, as necessary, using CXTPControl::SetDescription. Of course, it's only sensible if one delves through the XTP source code to decide how to best achieve this.
Unless I'm missing something in my analysis, I think this ends up being way too much work to achieve something that's very simple, and "just works" when using MFC. If XTP can "just work" using MFC mechanisms, then I am of the opinion that it should -- it pays to leverage existing MFC code because developers are familiar with it. In this case, this means that XTP's menu bar should emulate MFC by having XTP call the frame window's GetMessageString every time the string needs to be displayed in the status bar, unless a custom description has explicitly been set.
Nik B.
† CXTPControl provides a SetDescription/GetDescription function pair to allow the developer to manipulate the description.
‡ The other two are a bit too involved (and one is actually quite tricky) so I won't go into details, but basically, they involve deriving your own classes from XTP's base objects and using virtual functions to reimplement the necessary functionality. Nothing like the simplicity of GetMessageString...
|