wxGlade is able to change the own code inside existing source files to reflect changed designs.

This feature has some limitations. They are detailed discusses in the section called “Shared Control”.

It's common coding practice to separate and encapsulate individual responsibilities. Using a derived class to extend the code e.g. with GUI logic would follow this practice.

Use the C++ names for all wx identifiers like classes, colours or events of the wx framework. Please don't enter identifiers already formatted in a language specific form. wxGlade is able to transform the entered original identifiers in language-specific terms. You can use your own style for your object certainly.

It's generally recommended to use Unicode encoding for all non-ASCII character sets.

Enable internationalisation support. There are no disadvantages if internationalization is active but not used.

It's hard to add i18n and Unicode afterwards from project point of view.

The wxWidgets are written in C++ and follow the C++ naming convention. This naming convention may differ from the language specific and / or project specific naming convention.

For consistency's sake, it's recommended to use the wxWidgets style.

Usage of language specific codes e.g. for “Extra code for this widget” or in generic input fields complicated changing the output language later e.g. to re-use GUI elements in another project too.

It's not recommended to use nested classed and functions in combination with disabled feature “Overwrite existing sources”. Use derived classes to implement your functionality. See the section called “Best Practice” also.

The Lisp code generated by wxGlade may or may not working with a current Lisp dialect. Help to improve the Lisp support is really welcome.

Unsupported features in Lisp:

The XRC code writer doesn't supports all bitmap path tags described in the section called “Specifying the Path of Bitmaps”.

Just the “art:” statement is supported. The remaining bitmap tags will irgnored.

If “Overwrite existing sources” is set, wxGlade will re-generated all source files and drop potential manual changes. You've to include the generated source files and use derived classes for implementing changes.

The files written by wxGlade are consistent always. Also if e.g. classes or attributes are renamed. Rewriting the whole files is less error-prone in comparison with the section called “Shared Control”. That is the advantages of this method.

This method is the recommended one.

Manual changes in the source files won't be overwritten if “Overwrite existing sources” isn't set. You can safely edit the source code of the generated class. This is because wxGlade marks the untouchable code with the special comments “begin wxGlade” and “end wxGlade”. So you can edit all you need outside these two tags. When you make changes in your forms, a new code generation will not modify the user code. wxGlade is applying most of the changes but not all.

The source code modifications by wxGlade may incomplete after:

Additionally there are some internal flaws like the inconsistent design of the begin and end markers, just compare the event handler code generated for Perl and Python. Improving the handling internally would break the backward compatibility.

“Output path” specifies the name of the output file for “Single file” projects or the output directory for multi-file projects (“Separate file for each class”).

wxGlade can create additional code to start an instance of projects “Top window”.

There are two types of application start code:

The application start code generation is controlled by three properties:

Those properties are explained in the section called “Application Properties”. Different combinations of those attributes generated different application start code. The table below shows the type of application start code resulting from different combinations of the three properties. The “Enable gettext support” property just triggers i18n-enabled source code.

The application start code of a multi-file project will be recreated every time the code generation is running.

In opposition the application start code of single-file projects will not updated if the name of the “Top window” has changed and “Overwrite existing sources” is not set.

package MyApp;

use base qw(Wx::App);
use strict;

sub OnInit {
    my( $self ) = shift;

    Wx::InitAllImageHandlers();

    my $frame_1 = MyFrame->new();

    $self->SetTopWindow($frame_1);
    $frame_1->Show(1);

    return 1;
}
# end of class MyApp

package main;
unless(caller){
    my $local = Wx::Locale->new("English", "en", "en"); # replace with ??
    $local->AddCatalog("app"); # replace with the appropriate catalog name

    my $app = MyApp->new();
    $app->MainLoop();
}

package main;

unless(caller){
    my $local = Wx::Locale->new("English", "en", "en"); # replace with ??
    $local->AddCatalog("PlOgg1_app"); # replace with the appropriate catalog name

    local *Wx::App::OnInit = sub{1};
    my $PlOgg1_app = Wx::App->new();
    Wx::InitAllImageHandlers();

    my $Mp3_To_Ogg = PlOgg1_MyDialog->new();

    $PlOgg1_app->SetTopWindow($Mp3_To_Ogg);
    $Mp3_To_Ogg->Show(1);
    $PlOgg1_app->MainLoop();
}

You can compile your wxGlade project after the generation of the C++ source and header files. The following examples demonstrate compiling on Linux command line using g++.

# g++ FontColour.cpp $(wx-config --libs) $(wx-config --cxxflags) -o FontColour

# ll FontColour*
-rwxr-xr-x 1 carsten carsten 72493 Jun 15 09:22 FontColour
-rwxr-xr-x 1 carsten carsten  1785 Mai 11 19:24 FontColour.cpp
-rwxr-xr-x 1 carsten carsten  1089 Jun 11 07:09 FontColour.h

# g++  CPPOgg2_main.cpp $(wx-config --libs) $(wx-config --cxxflags) \
  -o CPPOgg2_main CPPOgg2_MyDialog.cpp CPPOgg2_MyFrame.cpp

# ll CPPOgg2*
-rwxr-xr-x 1 carsten carsten 108354 Jun 15 09:33 CPPOgg2_main
-rwxr-xr-x 1 carsten carsten    844 Mai 11 19:25 CPPOgg2_main.cpp
-rw-r--r-- 1 carsten carsten   5287 Mai 18 19:06 CPPOgg2_MyDialog.cpp
-rw-r--r-- 1 carsten carsten   1829 Jun 11 07:11 CPPOgg2_MyDialog.h
-rw-r--r-- 1 carsten carsten   1785 Mai 11 19:25 CPPOgg2_MyFrame.cpp
-rw-r--r-- 1 carsten carsten   1290 Jun 11 07:10 CPPOgg2_MyFrame.h