Windows does not fit contents


I tried to create a simple window, with wxGlade as a help.
Unfortunately, the window is too small and does not fit its contents.

This is a screenshot from wxGlade to demonstrate my structure.
As you can see, the fields are cropped at the right side and the buttom at the bottom is not fully visible.

How can I make the window large enough to automatically fit my fields?

Kind regards

Just set the size of the frame.
If you don’t set it, it will be set to fit the minimum required size. This could be increased by e.g. adding borders.

It helps if code and / or .wxg files are attached.

Thanks for the reply!

I am unfortunately not allowed to upload files, since I am a new user.
Here is a pastebin with the contents of the wxg file instead:

But shouldn’t the minimum size be at least large enough to contain all elements?

OK, the 400x300 is the default size for a frame.
As noted yesterday in the other thread, for this constellation, no sizer.Fit() code is generated. I will check whether I can add this.

Temporarily you may add this to the frame:

This will add the Fit code:

But, most of the time, frames are not used with Fit(), only dialogs are fitted to the minimum size.
For frames, it’s common to set a size that is larger and make the sizers and elements grow to fill the available space.

Actually, from looking at your contents, this probably should be a dialog, not a frame.

Thanks for the detailed answer :slight_smile:

Why should I use a dialog in this case? I thought, the dialog class is for confirm dialogs or similar use cases.

Is it a common practice to set the size of a frame manually? Or the intended way to work with wx widgets?

I also noticed that you inserted a sizer before the gridsizer. Whats up with that?

Sorry for so many questions, but the wiki and the documentation are very hard to get started with in my opinion.

A dialog is for temporary use.

Your frame does not seem to be the “main” window. The main frame will certainly display e.g. a list of swimmers and an “Add swimmer” button or menu item which will then show the “Add swimmer” dialog.

A frame is intended to be resized as much as the user wants. The bigger, the more data it can display.

For the sizer in the dialog etc. have a look at the wxGlade manual, section “Dialogs”. When you add a dialog to wxGlade it will generate the most important structures already.

General about sizers: always use the simplest available. Throwing everything at a GridBagSize does not generate a good structure / design and code. The ‘button_1’ should not be part of the grid sizer.

Oh I see.
In this case, the frame was actually intended to not display anything else, so no other main window, since I just wanted to enter one swimmers after the other. (And because I wanted to take small steps :slight_smile: )

(How did you manage to make the text boxes in the first two rows span multiple slots with a gridSizer? Isn’t this just possible with a gridbagsizer?)
Nevermind, I guess this is a gridBagSizer based on the screenshot you posted.

wxGlade is an awesome tool by the way :slight_smile:

Yes, the text boxes were fine in your example, but the action button should not be placed in the gridbag sizer.

It might actually even look better and/or easier to edit if you had taken just a two-column flexgrid sizer with a growable second column. The “Zeit” row would then contain a horizontal box sizer with three boxes. The “Zeit” and “Jahrgang” controls need not grow, so there’s no advantage in placing everything in a many-column grid to align and then span grid cells where the inputs need to grow.
Always use the simplest sizers that do the job. Hierarchies of (simple) sizers are fine and are actually easier to handle once your GUI gets more complex and you want to tune your layout using Proportions and EXPAND.
Especially re-designs are much easier with a reasonable hierarchy than with everything in a grid.

Once you add more fields to your database, it makes sense to group inputs into static box sizers. One box sizer for “Personal data”, one for “Performance” etc.

Glad you like it :slight_smile:

I did as you suggested and using multiple simple sizers is way more convenient and simple.

Unfortunaltely there seems to be an issue with the generated code from wxGlade.

I tried opening the model with this simple call:

dial = addSwimmerDialog()

but it raises this error:

wx.Dialog.__init__(self, *args, **kwds)
TypeError: Dialog(): arguments did not match any overloaded call:
  overload 1: 'style' is not a valid keyword argument
  overload 2: 'style' is not a valid keyword argument

The corresponding line is this one:

kwds["style"] = kwds.get("style", 0) | wx.DEFAULT_DIALOG_STYLE
wx.Dialog.__init__(self, *args, **kwds)

Is this caused by wxGlade or did I set a wrong option anywhere?



with addSwimmerDialog(self) as dlg:
    if dlg.ShowModal() == wx.ID_OK:
        print("User has hit OK")

works fine.
Seems like I violated some patterns when calling dialogs :slight_smile:

Another question, can I set a keyboard shortcut for a toolbar item?
I did not find anything about shortcuts in the documentation.

If you have a menu, you can assign keys to the menu items. Also, buttons may use Alt-Key combinations like “&Add” for Alt+A.

Otherwise I think you need to thandle the keys yourself.
Not sure whether AcceleratorTable can be used with anything other than menu IDs.

Inside wxGlade I’m using EVT_CHAR_HOOK, but I think for ‘normal’ programs that might be overkill.

Well, actually EVT_CHAR_HOOK might be your best option as these events are propagating. I.e. you can bind the handler for the dialog or frame. EVT_CHAR is only delivered to the active widget.

These links are very helpful, thanks.

Can I set a shortcut in wxGlade? At least this help text suggest that it is possible.

This might be a left-over from the menu editor. The toolbar and menu editors share much code.
Just try it out.

It looks like you’ve already moved on to using a wx.Dialog, but for the record I’d like to add that a good way to use Fit with a frame is to also give the frame a sizer with just the top-level panel (panel_1) in it, and then call the frame’s Fit not the sizer’s Fit. Something like this:

frame_sizer = wx.BoxSizer()
frame_sizer.Add(panel_1, 1, wxEXPAND)

Thanks, I will try those solutions! :slight_smile:

@DietmarSchwertberger one more question about wxglade, if you don’t mind.
What is the intended way to maintain code to be able to add elements later? As far as I see, the “generate output” function overwrites the file and all changes I made to it.

Well, there are several options.
You can check “Keep user code”. This way, code outside of the begin/end wxglade markers will be kept. That’s not very robust when you rename elements, though.
For small programs and glue code that’s fine.

For larger projects, derive from the wxGlade generated code and implement your functionality there.

See the documentation “Create and Use Source Code”:

With revision 1.0 there is also an optional “Instance class” property. This allows that the application imports your derived code. I need to add this to the documentation.

So, you did not work through the documentation :wink:
You may also look at the supplied examples matplotlib vs. matplotlib2. The matplotlib2 example is much cleaner and easier to maintain in the long run.

P.S.: The “Instance Class” property is very flexible. It allows to use user specific widgets.
E.g. if you have a TextCtrl in your wxGlade project, you can enter “mycontrols.UpperCaseTextCtrl” to use a compatible class with your specific behaviour.
I’m using this a lot for measurement and control programs where I allow to enter values including units (e.g. “1mA” instead of “0.001A”).