wx.ADJUST_MINSIZE problems

I'm trying to get started using the 2.5.2.1 preview release. I use wxDesigner with an application that contains many dialogs and hundreds of sizers in wxDesigner generated code. Everything is messed up in different ways, as expected from the wx.ADJUST_MINSIZE change. I'm trying to figure out a straightforward way of getting things to behave the old way, but am having trouble.

I tried adding wx.FIXED_MINSIZE to all the sizers.. for example, calls like: item29 = wx.BoxSizer( wx.HORIZONTAL ) and item32 = wx.StaticBoxSizer( item33, wx.VERTICAL )
became item29 = wx.BoxSizer( wx.HORIZONTAL | wx.FIXED_MINSIZE ) and item32 = wx.StaticBoxSizer( item33, wx.VERTICAL | wx.FIXED_MINSIZE )

All this did was mess everything up in new and interesting ways.. some dialogs had huge controls extending off the display area, where they had been tiny text controls before.

Am I using this new flag incorrectly?

Austin Luminais wrote:

I'm trying to get started using the 2.5.2.1 preview release. I use wxDesigner with an application that contains many dialogs and hundreds of sizers in wxDesigner generated code. Everything is messed up in different ways, as expected from the wx.ADJUST_MINSIZE change. I'm trying to figure out a straightforward way of getting things to behave the old way, but am having trouble.

I tried adding wx.FIXED_MINSIZE to all the sizers.. for example, calls like: item29 = wx.BoxSizer( wx.HORIZONTAL ) and item32 = wx.StaticBoxSizer( item33, wx.VERTICAL )
became item29 = wx.BoxSizer( wx.HORIZONTAL | wx.FIXED_MINSIZE ) and item32 = wx.StaticBoxSizer( item33, wx.VERTICAL | wx.FIXED_MINSIZE )

All this did was mess everything up in new and interesting ways.. some dialogs had huge controls extending off the display area, where they had been tiny text controls before.

Am I using this new flag incorrectly?

Yes. It should be used when adding items to a sizer. For example:

  txt = wx.TextCtrl(parent, -1, "small")
  txt.SetSize((30, -1))
  sizer.Add(txt, 0, wx.FIXED_MINSIZE | wx.ALL, 5)

But since setting the size as part of the constructor will also set the
minsize of the textctrl, this should also work:

  txt = wx.TextCtrl(parent, -1, "small", size=(30,-1))
  sizer.Add(txt, 0, wx.ALL, 5)

···

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

Thanks, Robin, for the last reply, I have now added wx.FIXED_MINSIZE in the right places and my application is almost working with the preview release.

One problem I am still having is that some of my sizers are showing up with a black border where they were the default gray of the rest of the dialog background before.
This is happening on some, but not all dialogs, and I haven't figured out the cause yet, but I'm pretty sure it relates to the border of the main sizer of the dialog.

For example, I have (wxDesigner generated):

    item0 = wx.BoxSizer( wx.VERTICAL )
    item2 = wx.Notebook( parent, ID_NOTEBOOK, wx.DefaultPosition, [200,160], wx.NB_BOTTOM )
    item1 = wx.NotebookSizer( item2 )

    item0.Add( item1, 1, wx.GROW|wx.FIXED_MINSIZE|wx.ALIGN_CENTER_VERTICAL|wx.ALL, 5 )

item0 is the main sizer of the dialog.
Now if I remove wx.ALL from that last line, the black border disappears, because no border is drawn at all, if I understand the documentation correctly.

I'm just trying to figure out why these borders are being displayed black.

Austin Luminais wrote:

Thanks, Robin, for the last reply, I have now added wx.FIXED_MINSIZE in the right places and my application is almost working with the preview release.

One problem I am still having is that some of my sizers are showing up with a black border where they were the default gray of the rest of the dialog background before.
This is happening on some, but not all dialogs, and I haven't figured out the cause yet, but I'm pretty sure it relates to the border of the main sizer of the dialog.

For example, I have (wxDesigner generated):

   item0 = wx.BoxSizer( wx.VERTICAL )
   item2 = wx.Notebook( parent, ID_NOTEBOOK, wx.DefaultPosition, [200,160], wx.NB_BOTTOM )
   item1 = wx.NotebookSizer( item2 )

   item0.Add( item1, 1, wx.GROW|wx.FIXED_MINSIZE|wx.ALIGN_CENTER_VERTICAL|wx.ALL, 5 )

item0 is the main sizer of the dialog.
Now if I remove wx.ALL from that last line, the black border disappears, because no border is drawn at all, if I understand the documentation correctly.

I'm just trying to figure out why these borders are being displayed black.

Sizers don't actually draw anything for the borders (they are not windows and don't own any windows,) they just leave empty space for the borders. So what you are seeing is the window underneath the notebook. What is the class type of parent?

There were some changes to how the default colour and font attributes for windows are determined. In the past there was a single set of system attributes that were used for all class types. These days with themes on GTK, OSX and now XP, that model just doesn't fit any more. You can have different "system" fonts or bg colours for different kinds of windows/controls even if they had the same ones historically, and you can sometimes have different attributes even for the same kind of windows when used in different contexts. So the new default attribute model tries to accomodate that. It's probably still not perfect, but it has room to grow into something that will be.

···

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

Robin Dunn wrote:

Sizers don't actually draw anything for the borders (they are not windows and don't own any windows,) they just leave empty space for the borders. So what you are seeing is the window underneath the notebook. What is the class type of parent?

I see. The parent is a wx.MDIChildFrame, and I noticed that it is only MDIChildFrames that I'm having the problem with. Setting the window background explicitly with SetBackgroundColour fixes it.

I was wondering if the fact that the background on MDIChildFrames on Windows are defaulting to black should be considered a bug. I can work around it by setting the background color manually, but considering the already somewhat annoying fact that MDIChildFrames can't be created hidden, it now means that whenever you create an MDIChildFrame, you see a black window flash on the screen. It's pretty ugly.

Austin Luminais wrote:

I was wondering if the fact that the background on MDIChildFrames on Windows are defaulting to black should be considered a bug. I can work around it by setting the background color manually, but considering the already somewhat annoying fact that MDIChildFrames can't be created hidden, it now means that whenever you create an MDIChildFrame, you see a black window flash on the screen. It's pretty ugly.

I think it's been fixed.

···

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