// Name: devtips.h
// Purpose: Cross-platform development page of the Doxygen manual
// Author: wxWidgets team
-// RCS-ID: $Id$
-// Licence: wxWindows license
+// Licence: wxWindows licence
/////////////////////////////////////////////////////////////////////////////
/**
@page page_multiplatform General Cross-Platform Development Tips
-This chapter describes some tips related to cross-platform development.
-
-@li @ref page_multiplatform_includefiles
-@li @ref page_multiplatform_libraries
-@li @ref page_multiplatform_configuration
-@li @ref page_multiplatform_makefiles
-@li @ref page_multiplatform_winresources
-@li @ref page_multiplatform_allocatingobjects
-@li @ref page_multiplatform_architecturedependency
-@li @ref page_multiplatform_conditionalcompilation
-@li @ref page_multiplatform_cpp
-@li @ref page_multiplatform_filehandling
-@li @ref page_multiplatform_reducingerr
-@li @ref page_multiplatform_gui
-@li @ref page_multiplatform_debug
+@tableofcontents
+This chapter describes some tips related to cross-platform development.
-<hr>
@section page_multiplatform_includefiles Include Files
@c "docs/xxx/install.txt" in your distribution, where @c "xxx" is the platform
of interest, such as @c msw, @c gtk, @c x11, @c mac.
-All wxWidgets makefiles are generated using
-@link http://www.bakefile.org Bakefile @endlink. wxWidgets also provides (in
-the @c "build/bakefiles/wxpresets" folder) the wxWidgets bakefile presets.
-These files allow you to create bakefiles for your own wxWidgets-based
-applications very easily.
+All wxWidgets makefiles are generated using Bakefile <http://www.bakefile.org/>.
+wxWidgets also provides (in the @c "build/bakefiles/wxpresets" folder) the
+wxWidgets bakefile presets. These files allow you to create bakefiles for your
+own wxWidgets-based applications very easily.
(when all messages have been processed) to actually delete the window, to avoid
problems associated with the GUI sending events to deleted windows.
-Don't create a window on the stack, because this will interfere with delayed
-deletion.
+In general wxWindow-derived objects should always be allocated on the heap
+as wxWidgets will destroy them itself. The only, but important, exception to
+this rule are the modal dialogs, i.e. wxDialog objects which are shown using
+wxDialog::ShowModal() method. They may be allocated on the stack and, indeed,
+usually are local variables to ensure that they are destroyed on scope exit as
+wxWidgets does not destroy them unlike with all the other windows. So while it
+is still possible to allocate modal dialogs on the heap, you should still
+destroy or delete them explicitly in this case instead of relying on wxWidgets
+doing it.
If you decide to allocate a C++ array of objects (such as wxBitmap) that may be
cleaned up by wxWidgets, make sure you delete the array explicitly before
wxWidgets does not use C++ run-time type information since wxWidgets provides
its own run-time type information system, implemented using macros.
-@subsection page_multiplatform_cpp_null Type of NULL
-
-Some compilers (e.g. the native IRIX cc) define @NULL to be 0L so that no
-conversion to pointers is allowed. Because of that, all these occurrences of
-@NULL in the GTK+ port use an explicit conversion such as
-
-@code
-wxWindow *my_window = (wxWindow*) NULL;
-@endcode
-
-It is recommended to adhere to this in all code using wxWidgets as this make
-the code (a bit) more portable.
-
@subsection page_multiplatform_cpp_precompiledheaders Precompiled Headers
Some compilers, such as Borland C++ and Microsoft C++, support precompiled
operating system and compiler, more or less specific information about the
problem will be logged.
-You should also use @ref group_funcmacro_debugging as part of a "defensive
+You should also use @ref group_funcmacro_debug as part of a "defensive
programming" strategy, scattering wxASSERT()s liberally to test for problems in
your code as early as possible. Forward thinking will save a surprising amount
of time in the long run.
projects / wxWidgets.git / blobdiff