Commited Keybinder ver 0.4.4 1/7/2006 10:56 PM
Re: keybinder clobbers menuitems with bitmaps.
It's been a real education tracing through WX262 menu
code this past week. It appears to me that the menu bitmap code
is a paste and forget job. Very disappointing.
The XRC code "owner draws" the bitmap onto the menu, then
the menu code willy nilly turns off the "m_bOwnerDrawn" flag.
Bitmapped menuitems are not supported in WX menu code, only OwnerDrawn.
Reason: Looks like a Win98 thingie. But...
The next time the menuitem is updated, ownerdrawn attributes, bitmaps
etc are clobbered because, of course, the owner drawn code is never called.
If the modifying coder turns owner drawn back on, the width of the
menuitem is ignored, the accelerator is drawn "right aligned", thus
clobbering (drawing over) the menuitem text. Ugly!
Hack:
SetText without OwnerDrawn to guarantee the menuitem width,
then do it again with OwnerDrawn=true to redraw/reinstate the bitmap. Jeeezzh!!!
// set "un-ownerdrawn" text to preserve menu width
m_pItem->SetText(newtext);
//now redraw the menuitem if bitmapped
if (m_pItem->GetBitmap().GetWidth())
{ m_pItem->SetOwnerDrawn();
m_pItem->SetText(newtext);
}
//-m_pItem->GetMenu()->UpdateAccel(m_pItem); //<--does nothing previous SetTExt() didnt
The results are not pretty. The margin between the bitmap and the text is changed,
and the accelerator is vertically misaligned with its siblings because it's
drawn "right aligned" into the menuitem. Yuk!
So: I'm commiting the "fixed" keybinder, and will now find a way to draw
it as pretty as XRC does it. I think this is important, because we're all
gonna have to mangle a menu someday.
thanks
pecan
Well, there is a little problem with the modification you showed here:
wxMenuItem::SetOwnerDrawn() does not exist - at least not in wxGTK 2.6.1 and not in the official documentation of wxWidgets 2.6.2. Maybe it is a wxMSW-specific function (although I could not find something like this in the documentation) but then it should be wrapped with preprocessor macros to be only included on windows. Therefore it should be changed like this:
$ svn diff src/plugins/contrib/keybinder/menuutils.cpp
Index: src/plugins/contrib/keybinder/menuutils.cpp
===================================================================
--- src/plugins/contrib/keybinder/menuutils.cpp (revision 1676)
+++ src/plugins/contrib/keybinder/menuutils.cpp (working copy)
@@ -109,7 +109,10 @@
m_pItem->SetText(newtext);
//now redraw the menuitem if bitmapped
if (m_pItem->GetBitmap().GetWidth())
- { m_pItem->SetOwnerDrawn();
+ {
+#if defined( __WXMSW__ )
+ m_pItem->SetOwnerDrawn();
+#endif
m_pItem->SetText(newtext);
}
//-m_pItem->GetMenu()->UpdateAccel(m_pItem); //<--does nothing previous SetTExt() didnt
Actually we're almost done with a menu implementation that is formatted using standard HTML4.0, including powerful tags like <embed> and <frameset>. You can insert your AVI movies with the <embed> tag then, and you can customise your menus by pointing a frame to your homepage where you store the menu order. :)
What about <marquee>? :(
Should I post a feature request for it? :)
File Edit View Search Project Build Debug Tools Plugins Settings Help
Actually we're almost done with a menu implementation that is formatted using standard HTML4.0, including powerful tags like <embed> and <frameset>. You can insert your AVI movies with the <embed> tag then, and you can customise your menus by pointing a frame to your homepage where you store the menu order. :)
What about <marquee>? :(
Should I post a feature request for it? :)
File Edit View Search Project Build Debug Tools Plugins Settings Help
Lol, why the menu should move in that way?