
Common FAQ: Questions common to all platforms
See also top-level FAQ page.
List of questions in this category
All windows and controls in wxWidgets programs are created using
new
but you shouldn't use
delete to free them. This doesn't result
in memory leaks because wxWidgets takes care of this: all objects derived from
wxWindow will be deleted automatically by the library when the corresponding
real, on screen, window is destroyed. Thus, the top level window objects are
deleted when you call
Close() or
Destroy() and all the child
windows are deleted just before the parent window is. More details about the
top level windows can be found in the ``Window deletion overview'' in
the manual.
wxWidgets also automatically deletes some other kind of the objects, notably
the sizer or constraint associated with the window -- this happens just before
the window itself is deleted. The sizers, in turn, delete their child sizers
automatically as well so in a typical situation you don't have to worry
about freeing the sizers you create. Note, however, that if you
Remove() a sizer from the window, it isn't automatically deleted
any more and you are responsable for doing this.
Please look at the
event wxWidgets sample source code, it shows how to
do this among other things. Note that the way custom events are defined has
changed in wxWidgets 2.3.1 as compared to the previous releases.
Using any GUI functions from the thread other than the main one (the one
running the application event loop) is not supported, in particular creating
windows from a worker thread will never work. If you need to do anything from
the worker thread the simplest way to do it is to post a custom event to the
main thread asking it to do whatever is necessary.
Starting from wxWidgets 2.8 you can call wxWindow::MoveBeforeInTabOrder() and
MoveAfterInTabOrder() to change the position of a child window in the TAB
chain. Notice that by default the TAB order is the same as the order of
creation.
First of all,
_T() is exactly the same as
wxT() (it exists
only because it should be more familiar to Windows programmers) which reduces
the problem of choosing among the macros to use somewhat.
Here is some pseudo-code for choosing the macro to use between the remaining
possibilities, that is whether to use wxT(), use _() or not
use any of them:
if ( string should be translated )
use _("string")
else if ( string should be in Unicode in Unicode build )
use wxT("string")
else
just use "string" normally
Note that if you don't care about Unicode at all, you don't have to use
wxT() at all. On the contrary, if you do, note that _()
takes care of it internally so if you use it your code will compile in both
the ANSI and Unicode builds.
Please see the description of these macros in the manual for more details.
Pressing
Esc will close the dialog if and only if it has a button
with
wxID_CANCEL id.
These message boxes are probably due to calls to
wxLogError() or
other log functions from wxWidgets code. To completely suppress them you
may use wxLogNull class, please see the manual for details. Do note, however,
that a better solution is to avoid the error in the first place as suppressing
these error message might hide other, important, ones.
This topic is covered in the technical note
Writing installers.
The following code:
wxString str;
str.Printf(wxT("My string is %s"), wxString("whatever"));
does
not work. Unfortunately, it may seem to work fine under
Windows because of a compiler quirk there but passing a wxString object to a
function taking a variable number of arguments such as
Printf() is
undefined behaviour in C++. Accordingly, it will simply crash under most
platforms but may even "work" on some of them.
You must use c_str() to make the above code work, i.e. write this
instead:
wxString str;
str.Printf(wxT("My string is %s"), wxString("whatever").c_str());
Note that g++ should give you an error when passing an object to a vararg
function like this -- another reason to compile your code with g++ even if you
normally use another compiler.
If you use the wxXRC_USE_LOCALE flag (which is on by default), strings
from XRC files are translated using wxLocale. wxLocale assumes the strings
are in ASCII - if the are not, wxXmlResource leaves them in UTF-8 encoding in
ANSI build of wxWidgets. Either don't use
wxXRC_USE_LOCALE or use
translate="0" attribute in XRC files. More details can be found
here or
here.