What is the preferred method for creating a wxWidget application: using a GUI tool or procedurally in code?

Question

I use wxWidgets to create test tools at work. I have always created the GUI by creating the widgets in code. I haven't tried any of the tools available that help to do this. How do other users of wxWidgets typically create their interface? If you use a tool, which tool do you use? If you use a tool, what advantages and disadvantages do you think there are for using that tool?

Answer 1

I've used wxFormBuilder for two reasons:

1. It's cross-platform and I needed something that would work on Linux.
2. I'm new to wxWidgets and I didn't want to spend lots of time futzing about with building the GUI.

I think it works quite well, and being familiar with similar GUI building tools (Borland C++ Builder, Jigloo for Java, Delphi) I found it easy to use.

If you stick with the paradigm of using wxFormBuilder to generate base classes, and then you make a class that inherits to layer your application specific logic on top, absolutely not hand-editing the C++ code wxFormBuilder generates, then it works well and you can easily update and modify your GUIs in wxFormBuilder again (and again...).

Advantages:

• Can generate your base GUIs quite quickly, in a visual manner, without having to constantly look up the documentation.
• Don't have to do as many code/compile/run cycles just to make sure your GUI is looking like what you expected.
• The base class/derived class paradigm can make a reasonably clean separation of your GUI and business logic code.

Potential Disadvantages

• Disclaimer: I've only used wxWidgets to create very simple, straight-forward GUIs, so haven't really pushed the tool to any limits.
• Potentially the base class/derived class paradigm could sometimes get in your way if you are doing something too sophisticated with your GUI (OTOH that could indicate that you may need to re-think your approach.)
• I had a situation where I needed a menu item when compiled for one operating system, but not when compiled for another. There is no logic in wxFormBuilder to support this. I ended up taking the short-cut of always creating the menu item and then having my derived class make it invisible if it was the wrong OS (not ideal.)

That's about it, I think.

Answer 2

What I find is that I often build the first cut at a GUI using a tool, and when it seems to be converging on the "final" form, I start to recode/refactor by hand.

Some of this depends on the tools, though, too. I'm not a big wxWidget fan.

Answer 3

You know, it depends. E.g. if I need some standard behaviour, I usually use DialogBlocks for GUI because it is the fastest way. If I need custom behaviour (e.g. my current project is cross-platform media manager whose GUI supports skins) then I do all GUI-relates things in code. As for custom controls:

• If a control does some project-specific thing, then I create it in DialogBlocks using the same project file (with other forms and dialogs used in this project)
• If my control should be reusable (general-purpose control) then I create a separate project for it and create a keleton in DialogBlocks - add empty event handlers and class variables if possible, then write logic manually in Visual Studio.

That's it :)

Answer 4

You might want to look into using XRC/XRS files.

Though I must admit I haven't bothered to do so myself. Just generating static GUI code using wxFormBuilder (which has XRC support, btw) has been enough for all my (small-scale) GUI designs.