wx.ComboBox: Gtk and win32 platform inconsistences

wxPython Users
1

unicode build, 2.8.1.1

First:
The combobox fills the whole place in the dialog, while in Ms Win
  it is not.

Second:
Main problem for my app:
  The EvtText should be called only once as on windows.
  but on gtk, it is fired, when settext is called, and that leads
  of source to an recursive error

import wx

class ComboBoxDlg(wx.Dialog):

    """ComboBoxEntryDialog."""
    def __init__(self, parent, title='ComboBoxDlg', choices=[]):
        """Create the ComboBoxEntryDialog."""
        wx.Dialog.__init__(self, parent, -1, title=title,
                           style=wx.DEFAULT_DIALOG_STYLE|wx.MAXIMIZE_BOX|wx.THICK_FRAME|wx.RESIZE_BORDER)

        self.cb = wx.ComboBox(self, choices=choices, pos =((50,50)), size = ((100, 100)))
        
        self.cb.Bind(wx.EVT_TEXT, self.EvtText)
        
    def EvtText (self, event):
        print "evt Text"
        self.cb.SetValue(self.cb.GetValue() + " Hallo")

import wx
app = wx.App(0)
dlg = ComboBoxDlg(None, choices=['a', 'b', 'c'])
dlg.ShowModal()
dlg.Destroy()
app.MainLoop()

How can I discover, that the event is fired by SetValue() and then ignore it?
For a workaround for the time being.

in the form of
def EvtText (self, event):
  if event_is_fired_by_SetValue)
    return

···

--
Franz Steinhaeusler

2

Franz Steinhäusler wrote:

unicode build, 2.8.1.1

First:
The combobox fills the whole place in the dialog, while in Ms Win
  it is not.

wx.Dialog on wxMSW does not get an initial EVT_SIZE when it is first
shown like it does on wxGTK. If you resize the dialog you'll see the
choice move to (0,0) and resize to fill the width. It doesn't change
height because the native widget limits its own height.

Thanks, shouldn't that be equal in a cross platform programming environment?

Otherwise, there have to be in a wx.Dialog.
if platform is win: send size event or so

How can I discover, that the event is fired by SetValue() and then ignore it?
For a workaround for the time being.

    def EvtText (self, event):
        if self.skipNextEvtText:
            return
        self.skipNextEvtText = True
        print "evt Text"
        self.cb.SetValue(self.cb.GetValue() + " Hallo")
        self.skipNextEvtText = False

Ah, I should have know it, so easy! :slight_smile: Thanks!

···

On Mon, 23 Apr 2007 13:06:21 -0700, Robin Dunn <robin@alldunn.com> wrote:

--

Franz Steinhaeusler

3

Franz Steinhaeusler wrote:

···

On Mon, 23 Apr 2007 13:06:21 -0700, Robin Dunn <robin@alldunn.com> wrote:

Franz Steinhäusler wrote:

unicode build, 2.8.1.1

First:
The combobox fills the whole place in the dialog, while in Ms Win
  it is not.

wx.Dialog on wxMSW does not get an initial EVT_SIZE when it is first shown like it does on wxGTK. If you resize the dialog you'll see the choice move to (0,0) and resize to fill the width. It doesn't change height because the native widget limits its own height.

Thanks, shouldn't that be equal in a cross platform programming environment?

In a perfect world, yes. But when using native widgets sometimes there are things that just work differently. We can minimize the impact of those differences, but we can't eliminate all of them.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

4

Franz Steinhaeusler wrote:

Franz Steinhäusler wrote:

unicode build, 2.8.1.1

First:
The combobox fills the whole place in the dialog, while in Ms Win
  it is not.

wx.Dialog on wxMSW does not get an initial EVT_SIZE when it is first
shown like it does on wxGTK. If you resize the dialog you'll see the
choice move to (0,0) and resize to fill the width. It doesn't change
height because the native widget limits its own height.

Thanks, shouldn't that be equal in a cross platform programming environment?

In a perfect world, yes.

Oh yes. :wink:

But when using native widgets sometimes there
are things that just work differently. We can minimize the impact of
those differences, but we can't eliminate all of them.

So this stays at it is. Is this also the same on wxWidgets.
When I understand it right, this is "native" behaviour and should stay
unchanged? Or isn't it possible to change that?
Or will this be unchanged, because it is "ok" so.

···

On Tue, 24 Apr 2007 10:46:00 -0700, Robin Dunn <robin@alldunn.com> wrote:

On Mon, 23 Apr 2007 13:06:21 -0700, Robin Dunn <robin@alldunn.com> wrote:

--
Franz Steinhaeusler

5

Franz Steinhäusler wrote:

Franz Steinhaeusler wrote:

Franz Steinhäusler wrote:

unicode build, 2.8.1.1

First:
The combobox fills the whole place in the dialog, while in Ms Win
  it is not.

wx.Dialog on wxMSW does not get an initial EVT_SIZE when it is first shown like it does on wxGTK. If you resize the dialog you'll see the choice move to (0,0) and resize to fill the width. It doesn't change height because the native widget limits its own height.

Thanks, shouldn't that be equal in a cross platform programming environment?

In a perfect world, yes.

Oh yes. :wink:

But when using native widgets sometimes there are things that just work differently. We can minimize the impact of those differences, but we can't eliminate all of them.

So this stays at it is. Is this also the same on wxWidgets.
When I understand it right, this is "native" behaviour and should stay
unchanged? Or isn't it possible to change that?
Or will this be unchanged, because it is "ok" so.

The fact that wxGTK sends an event when SetValue is called may be able to be changed, so enter a bug report about it.

But wx.ComboBox not expanding vertically beyond its normal size probably won't be changed. The general philosophy in wx is that correctly written code will behave the same (as much as possible) on each platform, but no attempt is made to make incorrectly written code to misbehave in the same way on each platform. Causing something like a combobox to expand vertically beyond the height needed to display a single line of text would probably be considered an incorrect thing to do.

···

On Tue, 24 Apr 2007 10:46:00 -0700, Robin Dunn <robin@alldunn.com> wrote:

On Mon, 23 Apr 2007 13:06:21 -0700, Robin Dunn <robin@alldunn.com> wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

6

But when using native widgets sometimes there
are things that just work differently. We can minimize the impact of
those differences, but we can't eliminate all of them.

So this stays at it is. Is this also the same on wxWidgets.
When I understand it right, this is "native" behaviour and should stay
unchanged? Or isn't it possible to change that?
Or will this be unchanged, because it is "ok" so.

The fact that wxGTK sends an event when SetValue is called may be able
to be changed, so enter a bug report about it.

Ok.

But wx.ComboBox not expanding vertically beyond its normal size probably
won't be changed. The general philosophy in wx is that correctly
written code will behave the same (as much as possible) on each
platform, but no attempt is made to make incorrectly written code to
misbehave in the same way on each platform.

Do I have to understand, that to not use sizers or layout, the code is written
not "correctly"?

Causing something like a
combobox to expand vertically beyond the height needed to display a
single line of text would probably be considered an incorrect thing to do.

So correct would be: the wx.ComboBox would expand horizontally with
the height able to display one line(?)

···

On Wed, 25 Apr 2007 14:16:41 -0700, Robin Dunn <robin@alldunn.com> wrote:

--

Franz Steinhaeusler

7

But wx.ComboBox not expanding vertically beyond its normal size probably
won't be changed. The general philosophy in wx is that correctly
written code will behave the same (as much as possible) on each
platform, but no attempt is made to make incorrectly written code to
misbehave in the same way on each platform.
    
Do I have to understand, that to not use sizers or layout, the code is written
not "correctly"?

From the wxPython Style Guide
(http://wiki.wxpython.org/index.cgi/wxPython_Style_Guide):

If you use Sizers rather than absolute positioning, you get code that:

   * Works better across platforms: different platforms have different
     size widgets.
   * Easily adapts to different languages: different languages have
     different length labels, etc.
   * Works better even on one platform is the user uses a different
     default font, different theme.
   * Is more maintainable: If you need to change, remove or add a
     widget, the rest of your dialog or panel can re-arrange itself.

Basically, if anyone is using any sort of different configuration from
you, your app is quite possibly unusable. Plus, once you get the hang of
sizers they are much faster than figuring out the positions of
everything yourself.

Thanks for your information. But initially there was the question, that on windows
you have to resize the dialog to get the layout. After init, it is not done.
So I suspect, in that case, using of sizers would not help, because you still have to
resize the dialog or send a size event(?).
Yes, I already prefered using sizers, but what I meant, is that special case.

Causing something like a
combobox to expand vertically beyond the height needed to display a
single line of text would probably be considered an incorrect thing to do.
    
So correct would be: the wx.ComboBox would expand horizontally with
the height able to display one line(?)

I think so but part of the point is that some "inconsistencies" are
right. Gtk and win32 are different and obviously behave differently in
some cases. Users of one do not expect the same behavior as users of the
other, they expect native behavior; what they are used to. So don't
forget that some things are supposed to behave differently, but as the
programmer we don't even have to worry about it as wx handles it all for us.

Hopefully this information was at least remotely useful/relevant :slight_smile:
- Mike Rooney

Yes thanks, if somebody maybe noticed it or is interested to that,
I started (more a draft, than a professional looking :))
wiki page for that.
Everybody is welcome to extend it.

I find it interesting and I thought some time ago also creating
a page of "common failures" or "common pitfalls".
This, I could suppose, could be very interesting, when some users
writes there experiences, long looking bugs and failures and their solution
and there "I see" experience (don't know the english word, in german it
is called "Aha Erlebnis" or so into it.

···

On Thu, 26 Apr 2007 09:52:26 -0400, Mike Rooney <mxr@qvii.com> wrote:

--

Franz Steinhaeusler

8

Franz Steinhaeusler wrote:

···

On Wed, 25 Apr 2007 14:16:41 -0700, Robin Dunn <robin@alldunn.com> wrote:

Causing something like a combobox to expand vertically beyond the height needed to display a single line of text would probably be considered an incorrect thing to do.

So correct would be: the wx.ComboBox would expand horizontally with
the height able to display one line(?)

Yes.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!