I'm using PlateButton to have drop down menu in wx.StatusBar. It would be nice though if PlateButton.__DrawDropArrow() drew that arrow not next to label, but on the right side of button. Could the computing position of arrow be made overridable in subclass? Or could some switch be added to PlateButton.__init__() that would enable user to choose if he wishes current behaviour or the arrow to the right?
Currently it's all being done in private method so I have to either alter wx/lib/platebtn.py code or replace whole method in runtime, which is not the elegant.
On Wed, Sep 28, 2011 at 8:55 AM, Adam Bielański <ab@rdprojekt.pl> wrote:
Hi,
I'm using PlateButton to have drop down menu in wx.StatusBar. It would be
nice though if PlateButton.__DrawDropArrow() drew that arrow not next to
label, but on the right side of button. Could the computing position of
arrow be made overridable in subclass? Or could some switch be added to
PlateButton.__init__() that would enable user to choose if he wishes current
behaviour or the arrow to the right?
It should be getting drawn to the right side of the button. What
platform and version of wxPython are you using?
There was some issues on Linux due to differences between the graphics
context and default device context measuring of text sizes that was
fixed a while back (unless I forgot to merge it to wx.lib as well).
I'm using PlateButton to have drop down menu in wx.StatusBar. It would be
nice though if PlateButton.__DrawDropArrow() drew that arrow not next to
label, but on the right side of button. Could the computing position of
arrow be made overridable in subclass? Or could some switch be added to
PlateButton.__init__() that would enable user to choose if he wishes current
behaviour or the arrow to the right?
It should be getting drawn to the right side of the button. What
platform and version of wxPython are you using?
There was some issues on Linux due to differences between the graphics
context and default device context measuring of text sizes that was
fixed a while back (unless I forgot to merge it to wx.lib as well).
cody
Hi, thanks for prompt answer.
Maybe an arrow should be drawn to the right side of the button. But the code says different __DrawDropArrow() is called with an 'xpos' parameter, which is the left boundary of drawn arrow. Value of this parameter is `txt_x + tw + 6`, which translates to: text (label) offset from left plus text width plus 6. Source: wx/lib/platebtn.py, function __DrawButton, lines 307 and 323.
So the code says that arrow is positioned relatively to the right boundary of button label, not to the right boundary of the button.
And to answer your question: I'm using wxPython 2.9.2, Python 2.6, Windows 7.
In the attachment you can find both __DrawButton and __DrawDropArrow functions cut from wx/lib/platebtn.py in wxPython version I'm using.
Maybe an arrow should be drawn to the right side of the button. But the code
says different __DrawDropArrow() is called with an 'xpos' parameter,
which is the left boundary of drawn arrow. Value of this parameter is `txt_x
+ tw + 6`, which translates to: text (label) offset from left plus text
width plus 6. Source: wx/lib/platebtn.py, function __DrawButton, lines 307
and 323.
So the code says that arrow is positioned relatively to the right boundary
of button label, not to the right boundary of the button.
Yes, but the size of the button and its boundaries are also relative
to the label. The Button is only supposed to be as big as the label
plus a small padding around it, then plus a small amount of additional
horizontal space when a dropdown menu is present.
The problem is a bug
(http://groups.google.com/group/wxPython-dev/browse_thread/thread/cc12d0b0c5106a91)
where the text size is being measured larger than it is being drawn.
This issue is present in wxpython 2.9 but not 2.8. So the buttons size
is set using the initial measurement and then when the text is
remeasured for the actual drawing it is returning a different size.
Yes, initially it may have been better to place the arrow relative to
the edge of the rect instead of relying on the positioning of the
other contents but when the label is drawn as expected the arrow will
be where it is supposed to.
I will apply an appropriate fix for the next release.
Thanks,
Cody
···
On Thu, Sep 29, 2011 at 2:03 AM, Adam Bielański <ab@rdprojekt.pl> wrote: