+Nowadays the limitations of DOS 8+3 filenames doesn't apply anymore. Most
+modern operating systems allow at least 255 characters in the filename; the
+exact maximum length, as well as the characters allowed in the filenames, are
+OS-specific so you should try to avoid extremely long (> 255 chars) filenames
+and/or filenames with non-ANSI characters.
+
+Another thing you need to keep in mind is that all Windows operating systems
+are case-insensitive, while Unix operating systems (Linux, Mac, etc) are
+case-sensitive.
+
+Also, for text files, different OSes use different End Of Lines (EOL). Windows
+uses CR+LF convention, Linux uses LF only, Mac CR only.
+
+The wxTextFile, wxTextInputStream, wxTextOutputStream classes help to abstract
+from these differences. Of course, there are also 3rd party utilities such as
+@c dos2unix and @c unix2dos which do the EOL conversions.
+
+See also the @ref group_funcmacro_file section of the reference manual for the
+description of miscellaneous file handling functions.
+
+
+
+@section page_multiplatform_reducingerr Reducing Programming Errors
+
+@subsection page_multiplatform_reducingerr_useassert Use ASSERT
+
+It is good practice to use ASSERT statements liberally, that check for
+conditions that should or should not hold, and print out appropriate error
+messages.
+
+These can be compiled out of a non-debugging version of wxWidgets and your
+application. Using ASSERT is an example of `defensive programming': it can
+alert you to problems later on.
+
+See wxASSERT() for more info.
+
+@subsection page_multiplatform_reducingerr_usewxstring Use wxString in Preference to Character Arrays
+
+Using wxString can be much safer and more convenient than using @c wxChar*.
+
+You can reduce the possibility of memory leaks substantially, and it is much
+more convenient to use the overloaded operators than functions such as
+@c strcmp. wxString won't add a significant overhead to your program; the
+overhead is compensated for by easier manipulation (which means less code).
+
+The same goes for other data types: use classes wherever possible.
+
+
+
+@section page_multiplatform_gui GUI Design
+
+@li <b>Use Sizers:</b> Don't use absolute panel item positioning if you can
+ avoid it. Every platform's native controls have very different sizes.
+ Consider using the @ref overview_sizer instead.
+@li <b>Use wxWidgets Resource Files:</b> Use @c XRC (wxWidgets resource files)
+ where possible, because they can be easily changed independently of source
+ code. See the @ref overview_xrc for more info.
+
+
+
+@section page_multiplatform_debug Debugging
+
+@subsection page_multiplatform_debug_positivethinking Positive Thinking
+
+It is common to blow up the problem in one's imagination, so that it seems to
+threaten weeks, months or even years of work. The problem you face may seem
+insurmountable: but almost never is. Once you have been programming for some
+time, you will be able to remember similar incidents that threw you into the
+depths of despair. But remember, you always solved the problem, somehow!
+
+Perseverance is often the key, even though a seemingly trivial problem can take
+an apparently inordinate amount of time to solve. In the end, you will probably
+wonder why you worried so much. That's not to say it isn't painful at the time.
+Try not to worry -- there are many more important things in life.
+
+@subsection page_multiplatform_debug_simplifyproblem Simplify the Problem
+
+Reduce the code exhibiting the problem to the smallest program possible that
+exhibits the problem. If it is not possible to reduce a large and complex
+program to a very small program, then try to ensure your code doesn't hide the
+problem (you may have attempted to minimize the problem in some way: but now
+you want to expose it).
+
+With luck, you can add a small amount of code that causes the program to go
+from functioning to non-functioning state. This should give a clue to the
+problem. In some cases though, such as memory leaks or wrong deallocation, this
+can still give totally spurious results!
+
+@subsection page_multiplatform_debug_usedebugger Use a Debugger
+
+This sounds like facetious advice, but it is surprising how often people don't
+use a debugger. Often it is an overhead to install or learn how to use a
+debugger, but it really is essential for anything but the most trivial
+programs.
+
+@subsection page_multiplatform_debug_uselogging Use Logging Functions
+
+There is a variety of logging functions that you can use in your program: see
+@ref group_funcmacro_log.
+
+Using tracing statements may be more convenient than using the debugger in some
+circumstances (such as when your debugger doesn't support a lot of debugging
+code, or you wish to print a bunch of variables).
+
+@subsection page_multiplatform_debug_usedebuggingfacilities Use the wxWidgets Debugging Facilities
+
+You can use wxDebugContext to check for memory leaks and corrupt memory: in
+fact in debugging mode, wxWidgets will automatically check for memory leaks at
+the end of the program if wxWidgets is suitably configured. Depending on the
+operating system and compiler, more or less specific information about the
+problem will be logged.
+
+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.
+
+See the @ref overview_debugging for further information.
projects / wxWidgets.git / blobdiff