]> git.saurik.com Git - wxWidgets.git/blobdiff - docs/html/faqgen.htm
Fixes to allow compilation with no wchar_t (djgpp probably has a real wchar_t
[wxWidgets.git] / docs / html / faqgen.htm
index 25fc5d82b46d951cc29f9ef504b20ba50d8d464e..90f2c41d1a8da65b06b31e4774e430fe460900b6 100644 (file)
@@ -1,4 +1,3 @@
-
 <HTML>
 
 <HEAD>
 <HTML>
 
 <HEAD>
@@ -54,7 +53,7 @@ so your program will take on the native &#39;look and feel&#39; that users are f
 
 Although GUI applications are mostly built programmatically, there are several dialog editors to help
 build attractive dialogs and panels. Robert Roebling&#39;s <a href="http://www.roebling.com">wxDesigner</a>
 
 Although GUI applications are mostly built programmatically, there are several dialog editors to help
 build attractive dialogs and panels. Robert Roebling&#39;s <a href="http://www.roebling.com">wxDesigner</a>
-and Anthemion Software's <a href="http://www.anthemion.co.uk/dialogblocks/" target=_new>DialogBlocks</a>
+and Anthemion Software&#39;s <a href="http://www.anthemion.co.uk/dialogblocks/" target=_new>DialogBlocks</a>
 are two commercial examples, but there are others: see the <a href="lnk_tool.htm">Useful Tools</a> page.<P>
 
 You don&#39;t have to use C++ to use wxWidgets: there is a <a href="http://wxpython.org">Python interface</a> for wxWidgets 2,
 are two commercial examples, but there are others: see the <a href="lnk_tool.htm">Useful Tools</a> page.<P>
 
 You don&#39;t have to use C++ to use wxWidgets: there is a <a href="http://wxpython.org">Python interface</a> for wxWidgets 2,
@@ -277,29 +276,29 @@ from Java, and the level of interest in wxWidgets is as high as ever.<P>
 Microsoft is spending a lot on promoting the .NET initiative, which
 is a set of languages, APIs and web service components for Windows.
 Ximian has started an open source version of .NET, mostly for Linux.
 Microsoft is spending a lot on promoting the .NET initiative, which
 is a set of languages, APIs and web service components for Windows.
 Ximian has started an open source version of .NET, mostly for Linux.
-C&#35; is Microsoft's alternative to Java, supporting 'managed code',
+C&#35; is Microsoft&#39;s alternative to Java, supporting &#39;managed code&#39;,
 garbage collection and various other Java-like language features.<P>
 
 Although this may be attractive to some developers, there
 is a variety of reasons why the .NET/Mono combination is unlikely
 to make wxWidgets redundant. Please note that the following comments
 garbage collection and various other Java-like language features.<P>
 
 Although this may be attractive to some developers, there
 is a variety of reasons why the .NET/Mono combination is unlikely
 to make wxWidgets redundant. Please note that the following comments
-are Julian Smart's opinions.<P>
+are Julian Smart&#39;s opinions.<P>
 
 <ol>
 <li>Not everyone wants or needs net services.
 <li>C++ will be used for a long time to come; compared with C++, C&#35; is a recent development and its future is not certain.
 <li>Mono Forms may only target Winelib (at least to begin with), so the end result is not as native as
 
 <ol>
 <li>Not everyone wants or needs net services.
 <li>C++ will be used for a long time to come; compared with C++, C&#35; is a recent development and its future is not certain.
 <li>Mono Forms may only target Winelib (at least to begin with), so the end result is not as native as
-wxWidgets (I'm aware there is GTK&#35; for use with the C&#35; language).
+wxWidgets (I&#39;m aware there is GTK&#35; for use with the C&#35; language).
 <li>C&#35; is usually byte-compiled and therefore slower. Plus, .NET adds a layer of overhead to the client computer
 that wxWidgets does not require.
 <li>C&#35; is usually byte-compiled and therefore slower. Plus, .NET adds a layer of overhead to the client computer
 that wxWidgets does not require.
-<li>Mono hasn't proven its long-term viability yet (it's a complex system of components); wxWidgets is ready now.
+<li>Mono hasn&#39;t proven its long-term viability yet (it&#39;s a complex system of components); wxWidgets is ready now.
 <li>You may not wish to buy into Microsoft marketing spin and APIs.
 <li>Microsoft may at some point sue developers of non-Microsoft .NET implementations. After all,
 <li>You may not wish to buy into Microsoft marketing spin and APIs.
 <li>Microsoft may at some point sue developers of non-Microsoft .NET implementations. After all,
-platform-independence is not in Microsoft's interest.
+platform-independence is not in Microsoft&#39;s interest.
 <li>.NET might never be implemented on some platforms, especially Mac and embedded variants of Linux.
 <li>wxPython and other language variants provide further reasons for wxWidgets to continue.
 <li>.NET might never be implemented on some platforms, especially Mac and embedded variants of Linux.
 <li>wxPython and other language variants provide further reasons for wxWidgets to continue.
-<li>The same issue exists for Qt: if Qt sales remain strong, it's a good indication that
-the market for a C++-based approach is still there. (Either that, or everyone's turning to wxWidgets!)
+<li>The same issue exists for Qt: if Qt sales remain strong, it&#39;s a good indication that
+the market for a C++-based approach is still there. (Either that, or everyone&#39;s turning to wxWidgets!)
 </ol>
 
 There is nothing to stop folk from developing a C&#35; version of the wxWidgets API;
 </ol>
 
 There is nothing to stop folk from developing a C&#35; version of the wxWidgets API;
@@ -322,7 +321,7 @@ has specific suggestions. Also please read the <a href="standard.htm">coding sta
 
 <P>
 Each port consists of a platform-specific part (e.g. src/msw, include/wx/msw),
 
 <P>
 Each port consists of a platform-specific part (e.g. src/msw, include/wx/msw),
-a generic set of widgets and dialogs for when the port doesn't support
+a generic set of widgets and dialogs for when the port doesn&#39;t support
 them natively (src/generic, include/wx/generic) and the common code
 that all ports use (src/common, include/wx). By browsing the source
 you should get a good idea of the general pattern.<P>
 them natively (src/generic, include/wx/generic) and the common code
 that all ports use (src/common, include/wx). By browsing the source
 you should get a good idea of the general pattern.<P>
@@ -335,7 +334,7 @@ Perhaps it will still save you time to clean up wxStubs, and
 others may benefit from this too.<P>
 
 You will need to define a symbol for the new port, e.g. __WXXBOX__.
 others may benefit from this too.<P>
 
 You will need to define a symbol for the new port, e.g. __WXXBOX__.
-Look at files such as wx/defs.h, wx/wxchar.h for areas where you'll
+Look at files such as wx/defs.h, wx/wxchar.h for areas where you&#39;ll
 need to add to existing conditionals to set up wide character
 support and other issues. If the GUI runs on a Unix variant,
 define the __UNIX__ variable in your makefile.<P>
 need to add to existing conditionals to set up wide character
 support and other issues. If the GUI runs on a Unix variant,
 define the __UNIX__ variable in your makefile.<P>
@@ -357,7 +356,7 @@ wxMGL, and wxMSW/Univ for sample wxUniversal ports.<P>
 
 To begin with, you can use whatever makefiles or project
 files work for you. Look at existing makefiles to see what
 
 To begin with, you can use whatever makefiles or project
 files work for you. Look at existing makefiles to see what
-generic/common/Unix files need to be included. Later, you'll want to integrate support
+generic/common/Unix files need to be included. Later, you&#39;ll want to integrate support
 for your port into configure (Unix-like systems and gcc under Windows),
 and bakefile (for other makefiles on Windows).<P>
 
 for your port into configure (Unix-like systems and gcc under Windows),
 and bakefile (for other makefiles on Windows).<P>