From: Francesco Montorsi Date: Thu, 3 Apr 2008 08:37:20 +0000 (+0000) Subject: removed FAQs: they are already available in the website; there's no reason to duplica... X-Git-Url: https://git.saurik.com/wxWidgets.git/commitdiff_plain/27de83cd5b05a06ce08af0203d5d8ffecce83de3 removed FAQs: they are already available in the website; there's no reason to duplicate them here git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@52992 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775 --- diff --git a/docs/html/faq.htm b/docs/html/faq.htm deleted file mode 100644 index 2c5af9213c..0000000000 --- a/docs/html/faq.htm +++ /dev/null @@ -1,50 +0,0 @@ - - - - -wxWidgets FAQ - - - - - - - - - - -
- -wxWidgets FAQ - -
- -

- -Welcome to the wxWidgets FAQ. Please select a category:

- -

- -

- -For further information, please see the -wxWidgets Web site, -wxWiki -and install.txt (per port), todo.txt (per port), and bugs.txt (all ports) files -in your wxWidgets installation. -

- - - - - - diff --git a/docs/html/faqgen.htm b/docs/html/faqgen.htm deleted file mode 100644 index 64144dcaac..0000000000 --- a/docs/html/faqgen.htm +++ /dev/null @@ -1,369 +0,0 @@ - - - - -wxWidgets FAQ: General - - - - - - - - - - -
- -wxWidgets FAQ: General - -
- -

- -See also top-level FAQ page. -

-

List of questions in this category

- -
- -

What is wxWidgets?

- -wxWidgets is a class library that allows you to compile graphical C++ programs on a range of -different platforms. wxWidgets defines a common API across platforms, but uses the native graphical user interface (GUI) on each platform, -so your program will take on the native 'look and feel' that users are familiar with.

- -Although GUI applications are mostly built programmatically, there are several dialog editors to help -build attractive dialogs and panels. Robert Roebling's wxDesigner -and Anthemion Software's DialogBlocks -are two commercial examples, but there are others: see the Useful Tools page.

- -You don't have to use C++ to use wxWidgets: there is a Python interface for wxWidgets, -and also a Perl interface. -

- -

Can I use wxWidgets for both proprietary (commercial) projects, and GPL'ed projects?

- -Yes. Please see the licence for details, but basically -you can distribute proprietary binaries without distributing any source code, and neither will wxWidgets -conflict with GPL code you may be using or developing with it. -

-The conditions for using wxWidgets are the same whether you are a personal, academic -or commercial developer. -

- -

Is there support?

- -No official support, but the mailing list is very helpful and some people say that -wxWidgets support is better than for much commercial software. The developers are -keen to fix bugs as soon as possible, though obviously there are no guarantees. -

- -

Who uses wxWidgets?

- -Many organisations - commercial, government, and academic - across the -world. It's impossible to estimate the true number of users, since -wxWidgets is obtained by many different means, and we cannot monitor -distribution. The mailing list contains around 300-400 entries which is -quite large for a list of this type.

- -See Users for a list of some users and their applications, and -also Feedback for comments.

-Our highest-profile user yet is industry veteran and Lotus Corp. founder Mitch Kapor -and his Open Source Applications Foundation. -

- -

What platforms are supported by wxWidgets?

- - -

- -

How does wxWidgets support platform-specific -features?

- -This is a hotly-debated topic amongst the developers. My own philosophy -is to make wxWidgets as platform-independent as possible, but allow in a -few classes (functions, window styles) that are platform-specific. -For example, Windows metafiles and Windows 95 taskbar icons have -their own classes on Windows, but nowhere else. Because these classes -are provided and are wxWidgets-compatible, it doesn't take much -coding effort for an application programmer to add support for -some functionality that the user on a particular platform might otherwise -miss. Also, some classes that started off as platform-specific, such -as the MDI classes, have been emulated on other platforms. I can imagine -that even wxTaskBarIcon may be implemented for Unix desktops one day. -

- -In other words, wxWidgets is not a 'lowest common denominator' approach, -but it will still be possible to write portable programs using the -core API. Forbidding some platform-specific classes would be a stupid -approach that would alienate many potential users, and encourage -the perception that toolkits such as wxWidgets are not up to the demands -of today's sophisticated applications.

- -Currently resources such as bitmaps and icons are handled in a platform-specific -way, but it is hoped to reduce this dependence in due course.

- -Another reason why wxWidgets is not a 'lowest common denominator' toolkit is that -some functionality missing on some platform has been provided using generic, -platform-independent code, such as the wxTreeCtrl and wxListCtrl classes.

- -

Does wxWidgets use STL? or the standard string class?

- -No. This is a much-discussed topic that has (many times) ended with the conclusion that it is in -wxWidgets' best interests to avoid use of templates. Not all compilers can handle -templates adequately so it would dramatically reduce the number of compilers -and platforms that could be supported. It would also be undesirable to make -wxWidgets dependent on another large library that may have to be downloaded and installed. -In addition, use of templates can lead to executable bloat, which is something -wxWidgets is strenuously trying to avoid.

- -The standard C++ string class is not used, again because it is not available to all compilers, -and it is not necessarily a very efficient implementation. Also, we retain more flexibility -by being able to modify our own string class. Some compatibility with the string class -has been built into wxString.

- -There is nothing to stop an application using templates or the string class for its own -purposes. With wxWidgets debugging options on, you may find you get errors when including -STL headers. You can work around it either by switching off memory checking, -or by adding this to a header before you include any STL files:

- -

-#ifdef new
-#undef new
-#endif
-
- -

- - -

Is there a rich edit/markup widget for wxWidgets?

- -These are the possibilities so far:

- -

- -

- -

How to use C++ exceptions with wxWidgets?

- -wxWidgets library itself is unfortunately not exception-safe (as its -initial version predates, by far, the addition of the exceptions to the C++ -language). However you can still use the exceptions in your own code and use -the other libraries using the exceptions for the error reporting together with -wxWidgets. - -

-There are a few issues to keep in mind, though: -

- -

- -

How is wxWidgets being developed?

- -We are using the CVS system to develop and maintain wxWidgets. This allows -us to make alterations and upload them instantly to the server, from -which others can update their source.

- -To build source from CVS, see the file BuildCVS.txt in the top-level wxWidgets distribution -directory.

- -

How is wxWidgets distributed?

- -By ftp, and via the wxWidgets CD-ROM. -

-If you are feeling adventurous, you may also check out the sources directly -from cvs. -

- - - -

What is wxBase?

- -wxBase is a subset of wxWidgets comprised by the non-GUI classes. It includes -wxWidgets container and primitive data type classes (including wxString, -wxDateTime and so on) and also useful wrappers for the operating system objects -such as files, processes, threads, sockets and so on. With very minor -exceptions wxBase may be used in exactly the same way as wxWidgets but it -doesn't require a GUI to run and so is ideal for creating console mode -utilities or server programs. It is also possible to create a program which can -be compiled either as a console application (using wxBase) or a GUI one (using -a full featured wxWidgets port). - -

What is wxUniversal?

- -The main difference between wxUniversal-based ports (such as wxX11, wxMGL) and other ports (such as wxMSW, wxGTK+, wxMac) -is that wxUniversal implements all controls (or widgets) in -wxWidgets itself thus allowing to have much more flexibility (for example, support for -themes even under MS Windows). It also means that it is now much easier to -port wxWidgets to a new platform as only the low-level classes must be ported -which make for a small part of the library. -

-You may find more about wxUniversal here. - -

What about Java?

- -The Java honeymoon period is over :-) and people are realising that it cannot -meet all their cross-platform development needs. We don't anticipate a major threat -from Java, and the level of interest in wxWidgets is as high as ever.

- -

What about .NET/Mono?

- -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# is Microsoft's alternative to Java, supporting 'managed code', -garbage collection and various other Java-like language features.

- -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.

- -

    -
  1. Not everyone wants or needs net services. -
  2. C++ will be used for a long time to come; compared with C++, C# is a recent development and its future is not certain. -
  3. 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# for use with the C# language). -
  4. C# is usually byte-compiled and therefore slower. Plus, .NET adds a layer of overhead to the client computer -that wxWidgets does not require. -
  5. Mono hasn't proven its long-term viability yet (it's a complex system of components); wxWidgets is ready now. -
  6. You may not wish to buy into Microsoft marketing spin and APIs. -
  7. Microsoft may at some point sue developers of non-Microsoft .NET implementations. After all, -platform-independence is not in Microsoft's interest. -
  8. .NET might never be implemented on some platforms, especially Mac and embedded variants of Linux. -
  9. wxPython and other language variants provide further reasons for wxWidgets to continue. -
  10. 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!) -
- -There is nothing to stop folk from developing a C# version of the wxWidgets API; -we already have bindings to Python, Perl, JavaScript, Lua, Basic, and Eiffel. -Update: a wx.NET project is now in progress. - -

- -

How can I help the project?

- -Please check out the Community pages, -in particular the suggested projects, and -mail the developers' mailing list with your own suggestions.

- -

How do I start a new port?

- -Please subscribe to the wx-dev developers' mailing list and -ask if anyone else is interested in helping with the port, or -has specific suggestions. Also please read the coding standards. - -

-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 -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.

- -Take a port that most closely matches your port, and strip out -the implementation so you have a skeleton port that compiles. Ask on wx-dev -first for the wxStubs port - however, any such predefined skeleton -port may be out of date, so make a judgement on whether to use it. -Perhaps it will still save you time to clean up wxStubs, and -others may benefit from this too.

- -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 -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.

- -Then you can start implementing the port, starting with -wxWindow, wxTopLevelWindow, wxFrame, wxDialog so you -can get the minimal sample running as soon as possible.

- -If GDI objects (wxPen, wxBrush, etc.) are not concepts in your -native GUI, you may wish to use very generic versions of -some of these - see the wxX11 port.

- -Consider using the wxUniversal widget set as a quick way -to implement wxWidgets on your platform. You only need -to define some basic classes such as device contexts, -wxWindow, wxTopLevelWindow, GDI objects etc. and -the actual widgets will be drawn for you. See wxX11, -wxMGL, and wxMSW/Univ for sample wxUniversal ports.

- -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 -for your port into configure (Unix-like systems and gcc under Windows), -and bakefile (for other makefiles on Windows).

- -Submit your port as patches via SourceForge; you might -wish to separate it into one patch that touches common headers -and source files, and another containing the port-specific code, to make -it much easier for us to review and apply the patches.

- -Good luck! - - - - - - diff --git a/docs/html/faqgtk.htm b/docs/html/faqgtk.htm deleted file mode 100644 index 7dc802657d..0000000000 --- a/docs/html/faqgtk.htm +++ /dev/null @@ -1,126 +0,0 @@ - - - - -wxWidgets for GTK FAQ - - - - - - - - - - -
- -wxWidgets for GTK FAQ - -
- -

- -See also top-level FAQ page -and Unix FAQ page. -

-

List of questions in this category

- - - -
- -

What is wxWidgets for GTK?

- -wxWidgets for GTK is a port of wxWidgets to the GTK+ toolkit, -which is freely available for most flavours of Unix with X. wxWidgets for GTK is -often abbreviated to wxGTK. wxGTK has a separate home page here. -

- -

Why doesn't reading floating point numbers work when using wxWidgets?

- -If your program reads the floating point numbers in the format 123.45 -from a file, it may suddenly start returning just 123 instead of the -correct value on some systems -- which is all the more mysterious as the same -code in a standalone program works just fine. - -

-The explanation is that GTK+ changes the current locale on program startup. If -the decimal point character in the current locale is not the period (for -example, it is comma in the French locale), all the standard C functions won't -recognize the numbers such as above as floating point ones any more. - -

-The solution is to either use your own function for reading the floating point -numbers (probably the best one) or to call setlocale(LC_NUMERIC, "C") -before reading from file and restore the old locale back afterwards if needed. - -

Does wxGTK have GNOME support?

- -Currently wxGTK does not have any features that would involve dependence on any desktop -environment's libraries, so it can work on GNOME, KDE and with other window managers -without installation hassles. Some GNOME and KDE integration features are file based, and -so may be added without dependence on libraries. Other features may be supported in the -future, probably as a separate library. -

- -

Warning about GTK+ libraries supplied with RedHat

- -It seems that some versions of RedHat include a badly patched version of GTK+ (not wxGTK) -which causes some trouble with wxWidgets' socket code. Common symptoms are that when -a client tries to establish a connection to an existing server which refuses the request, -the client will get notified twice, first getting a LOST event and then a CONNECT event. -This problem can be solved by updating GTK with an official distribution of the library. -

- -

What range of Intel Linux platforms will a given application binary be usable on?

- -Robert Roebling replies:

- -"The important thing is the libc version that your app -is linked against. The most recent version is 2.2.5 -and programs linked against it will not run with version -2.1.X so that you will fare best if you compile your app -on a 2.1.X system. It will then run on practically all -Linux distros (if you link you app statically against -the image libraries and std C++ lib)." -

- -

Can I statically link the GTK+ library?

- -No, this is not possible. It leads to crashes in GTK+. -

- -

Why does my simple program using -EVT_CHAR not work?

- -In wxGTK, the frames never get focus and so can never receive CHAR -nor KEY events so an EVT_CHAR handler for a frame will be -never called. To receive these events, you should create a wxPanel -inside the frame and register the key event handlers for the panel, not the -frame. - -

- -

How do I trace the cause of an X11 error such as BadMatch?

- -When a fatal X11 error occurs, the application quits with no stack trace. -To find out where the problem is, put a breakpoint on g_log (b g_log -in gdb). - -

- - - - - - diff --git a/docs/html/faqmac.htm b/docs/html/faqmac.htm deleted file mode 100644 index eb10289a07..0000000000 --- a/docs/html/faqmac.htm +++ /dev/null @@ -1,238 +0,0 @@ - - - - -wxWidgets for Mac FAQ - - - - - - - - - - -
- -wxWidgets for Mac FAQ - -
- -

- -See also top-level FAQ page. -

-

List of questions in this category

- -
- -

Where should I download wxMac from?

- -Please see the downloads page. -

-The author of this port is Stefan Csomor. -

- -

Which Mac platforms are supported?

- -wxWidgets can be used to develop and deliver applications on Mac OS X and Mac Classic (e.g. Mac OS 8.x/9.x) both as Carbon and non-Carbon applications. -However the Mac OS X port is the most actively developed one, and Mac Classic will not be supported -after 2.6. wxMac works best with Mac OS X 10.3 and above. -

- -

What compilers are supported?

- -Under Classic Mac OS, MetroWerks CodeWarrior Pro 6 (or above) is required to build wxMac. -

-Under Mac OS X, the Developer Tools are sufficient to build wxMac. CodeWarrior Pro 6 can also be used to build the Carbon targets. -

- -

What can I do if I get conflicts between different installed versions of wxWidgets?

- -Some versions of Mac OS X install an older version of wxMac than the one you may be using -for development. This can cause conflicts, such as link errors when building your -applications. A user reports:

- -

-I got it to work. I removed the original wxMac build-release folder -and recompiled wxMac following instructions in your book. I then ran -"sudo make install" which I didn't do the first time. I figured I -could now run wx-config --cxxflags from my home directory because -/usr/local/bin/wx-config was in my $PATH. However, OSX 10.4 installed -a version of wxWidgets. When I ran wx-config I was getting wx 2.5 -libs instead of the 2.6.1 libs I just compiled. When I ran -"/usr/local/bin/wx-config --cxxflags" and "/usr/local/bin/wx-config --libs" -and pasted that output into XCode preferences, everything worked fine. -
-

- -

How does CVS handle file types/creators under Mac OS 8.x/9.x?

- -Before checking out the wxWidgets code using a CVS client under Mac OS 8.x/9.x, be sure your computer is set up to treat xpm and xbm images correctly: - -

- -

How does CVS handle file types/creators under Mac OS X?

- -The Mac OS X CVS client does not handle file types and creators at all (just like every Unix command line CVS client). This is an issue only when the checked out files will also be used under Mac OS 8.x/9.x. -

-All files checked out under Mac OS X will be untyped and CodeWarrior will not recognize them correctly. To correct this, use the autotyper provided in the CVS sources: -

-

- - - -

What steps are required to build wxMac under Mac OS X?

- -You need to have the Apple Developer Tools installed. The Developer Tools CD is one of the 3 CDs that are delivered with Mac OS X but must be installed in addition to the default Mac OS X installation. -

-Building wxMac completely without configure is not supported. -

-Building wxWidgets directly in the CVS sandbox is not recommended. Instead, wxWidgets should be built in a directory configured relatively to the CVS sandbox. -For instance, to build wxMac with configure, start in the base wxWidgets directory and type: -

-

- -

What important settings are required in the CodeWarrior Project Preferences?

- -For some reasons the CodeWarrior project settings may get changed and this may lead to the inability to compile a certain target. In order to verify the settings click on the target tab, double click on the respective target and then select the following items on the tree-view on the left. Here are the important checks: - -
    - -
  1. under Target/Access Paths, make sure the first user include does not have a folder icon for recursive search. - -
  2. under Language Settings/C/C++ Language, make sure that the only checked items are: -
      -
    • Enable C++ Exceptions -
    • Enable RTTI -
    • Enable bool Support -
    • Enable wchar_t Support -
    • Relaxed Pointer Type Rules -
    • Use Unsigned Chars -
    - -
  3. under Language Settings/C/C++ Warnings, make sure that the only checked items are: -
      -
    • Illegal Pragmas -
    • Extended Error Checking -
    • Inconsistent Use of 'class' and 'struct' Keywords -
    • Hidden Virtual Functions but be aware that the framework itself has some of these beauty spots -
    - -
  4. under Linker/PPC Linker, make sure that the following items are checked: -
      -
    • Dead-strip Static Initialization Code in order to avoid including libraries that are not needed, especially as things like OpenGL get added to the projects and sources -
    - -
-

- -

What are the smart preprocessing errors with the Apple Developer Tools?

- -Smart preprocessing is activated with the -cpp-precomp option and allows much faster preprocessing of the source files by loading precompiled Carbon header files. This option speeds up the compilation of wxMac by a factor of 2 at least. -When compiling wxMac using the Apple Developer Tools, the following error is displayed for certain files: - - -This error is due to the smart precompiler which does not fully understand C++ syntax and reverts to basic preprocessing when a smart preprocessing error occurs. -This error can sometimes be corrected or avoided by modifying the source code. However, leaving these errors is not a problem since the preprocessor automatically switches to basic preprocessing if necessary. -

- -

How does wxMac support the standard Apple About menu item and Help menu?

- -Because wxWidgets does not have a specific API for the About menu item or the Help menu, the Mac OS port uses some static variables to help the engine make the right decisions: - -

- -

How do I add an icon to my application?

- -If you have Mac OS X, you have the icns editor somewhere in the -Utilities folder. Create an icon using this tool and DeRez it, so that you have a .r -file with a 'icns' resource with id (-16455). Include this .r file in -your project and in the CodeWarrior Settings add a check mark under Linker:Output -Flags/Finder Flags/Has Custom Icon. -

- -

How can I easily switch between different versions of wxWidgets in CodeWarrior?

- -Sometimes you want to test your application against different versions -of wxWidgets, for example a stable version of wxWidgets versus a development version. -The easiest way to do this is to create a symbolic path.

- -Under Edit-Preferences in General:Source Trees, type a name (for example WXWIN) -and choose a path for it. Now reselect your include and lib paths for a last -time, in the settings for each configuration, but make them relative to the symbolic name. -

- -From now on you can just change the path associated with the symbolic name. - -

- - - - - - - diff --git a/docs/html/faqmot.htm b/docs/html/faqmot.htm deleted file mode 100644 index 661e0f019b..0000000000 --- a/docs/html/faqmot.htm +++ /dev/null @@ -1,84 +0,0 @@ - - - - -wxWidgets for Motif FAQ - - - - - - - - - - -
- -wxWidgets for Motif FAQ - -
- -

- -See also top-level FAQ page -and Unix FAQ page. -

-

List of questions in this category

- -
- -

What version of Motif do I need?

- -You will need version 1.2 or above. Version 2 should also be fine. Some people -have had a positive experience with Lesstif, -a free Motif clone. (Note from Julian Smart - I use the Linux version of MetroLink Motif 1.2.4). - -

- -

What features are missing or partially implemented?

- -The following classes are not yet implemented: wxSpinButton, wxCheckListBox, wxJoyStick, -wxGLCanvas.

- -The following classes are not likely to be implemented because there is no sensible -equivalent on Motif: wxMiniFrame, wxTaskBar.

- -These features are not yet implemented:

- -

- -

- -

Why are windows are not refreshed properly until I resize them?

- -Very occasionally you can experience this glitch, probably because sometimes the -window tries to resize and repaint itself before the final size is known. The workaround -is to add code like this after window creation and initialization:

- -

-#ifdef __WXMOTIF__
-  wxNoOptimize noOptimize;
-  window->SetSize(-1, -1, w, h);
-#endif
-
-

- - - - - - - diff --git a/docs/html/faqmsw.htm b/docs/html/faqmsw.htm deleted file mode 100644 index 5a117ed58c..0000000000 --- a/docs/html/faqmsw.htm +++ /dev/null @@ -1,576 +0,0 @@ - - - - -wxWidgets for Windows FAQ - - - - - - - - - - -
- -wxWidgets for Windows FAQ - -
- -

- -See also top-level FAQ page. -

-

List of questions in this category

- -
- -

Which Windows platforms are supported?

- -wxWidgets can be used to develop and deliver applications on Windows 95, Windows 98, Windows NT, -Windows 2000, Windows XP, and Windows Vista. A Windows CE -port is also available (see below).

- -16-bit compilation is only supported for wxWidgets 2.4 and previous versions, -using Visual C++ 1.5 and Borland BC++ 4 to 5. -

- -wxWidgets for Windows will also compile on Unix with gcc using Wine from WineHQ. -The resulting executables are Unix binaries that work with the Wine Windows API emulator.

- -You can also compile wxWidgets for Windows on Unix with Cygwin or Mingw32, resulting -in executables that will run on Windows. So in theory you could write your applications -using wxGTK or wxMotif, then check/debug your wxWidgets for Windows -programs with Wine, and finally produce an ix86 Windows executable using Cygwin/Mingw32, -without ever needing a copy of Microsoft Windows. See the Technical Note on the Web site detailing cross-compilation.

- -

What about Windows CE?

- -This port supports Pocket PC 2002/2003 and MS Smartphone 2002/2003, using -Embedded Visual C++ 3 or 4. For further information, see the wxMSW section in -the wxWidgets Reference Manual, and also the wxEmbedded page.

- -

What do I need to do for Windows XP?

- -From wxWidgets 2.5, the XP manifest is included in wx/msw/wx.rc and -so your application will be themed automatically so long as you include wx.rc -in your own .rc file.

- -For versions of wxWidgets below 2.5, you need to provide the manifest -explicitly, as follows.

- -In the same directory as you have your executable (e.g. foo.exe) you -put a file called foo.exe.manifest in which you have something like -the following: - -

-<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
-<assembly
-   xmlns="urn:schemas-microsoft-com:asm.v1"
-   manifestVersion="1.0">
-<assemblyIdentity
-    processorArchitecture="x86"
-    version="5.1.0.0"
-    type="win32"
-    name="foo.exe"/>
-    <description>Foo program</description>
-    <dependency>
-    <dependentAssembly>
-    <assemblyIdentity
-         type="win32"
-         name="Microsoft.Windows.Common-Controls"
-         version="6.0.0.0"
-         publicKeyToken="6595b64144ccf1df"
-         language="*"
-         processorArchitecture="x86"/>
-    </dependentAssembly>
-    </dependency>
-</assembly>
-
- -If you want to add it to your application permanently, -you can also include it in your .rc file using this -line:

- -

-  1 24 "winxp.manifest"
-
- -For an explanation of this syntax, please see -this -article. -

- -

What compilers are supported?

- -Please see the wxWidgets for Windows install.txt file for up-to-date information, but -currently the following are known to work:

- -

-

- - -

Which is the best compiler to use with wxWidgets?

- -It's partly a matter of taste, but some people prefer Visual C++ since the debugger is very -good, it's very stable, the documentation is extensive, and it generates small executables. -Since project files are plain text, it's easy for me to generate appropriate project files -for wxWidgets samples.

- -Borland C++ is fine - and very fast - but it's hard (impossible?) to use the debugger without using project files, and -the debugger is nowhere near up to VC++'s quality. The IDE isn't great.

- -C++Builder's power isn't really used with wxWidgets since it needs integration with its -own class library (VCL). For wxWidgets, I've only used it with makefiles, in which case -it's almost identical to BC++ 5.0 (the same makefiles can be used).

- -You can't beat Cygwin's price (free), and you can debug adequately using gdb. However, it's -quite slow to compile since it does not use precompiled headers.

- -CodeWarrior is cross-platform - you can debug and generate Windows executables from a Mac, but not -the other way around I think - but the IDE is, to my mind, a bit primitive.

- -Watcom C++ is a little slow and the debugger is not really up to today's standards.

- -Among the free compilers the best choice seem to be Borland C++ command line -tools and mingw32 (port of gcc to Win32). Both of them are supported by -wxWidgets. However BC++ has trouble compiling large executables statically, -so you need to dynamically link the wxWidgets libraries.

- -

Is Unicode supported?

- -Yes, Unicode is fully supported under Windows NT/2000 and there is limited -support for it under Windows 9x using MSLU. -

- -

Does wxWidgets support double byte fonts (Chinese/Japanese/Korean etc.)?

- -For Japanese under Win2000, it seems that wxWidgets has no problems working -with double byte char sets (meaning DBCS, not Unicode). First you have to -install Japanese support on your Win2K system and choose for ANSI translation -HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage=932 -(default is 1252 for Western). Then you can see all the Japanese letters in -wxWidgets applications. -

- -

Can you compile wxWidgets as a DLL?

- -Yes (using the Visual C++ or Borland C++ makefile), but be aware that distributing DLLs is a thorny issue -and you may be better off compiling statically-linked applications, unless you're -delivering a suite of separate programs, or you're compiling a lot of wxWidgets applications -and have limited hard disk space.

- -With a DLL approach, and with different versions and configurations of wxWidgets -needing to be catered for, the end user may end up with a host of large DLLs in his or her Windows system directory, -negating the point of using DLLs. Of course, this is not a problem just associated with -wxWidgets! -

- -

How can I reduce executable size?

- -You can compile wxWidgets as a DLL (see above, VC++/BC++ only at present). You should also -compile your programs for release using non-debugging and space-optimisation options, but -take with VC++ 5/6 space optimisation: it can sometimes cause problems.

- -If you want to distribute really small executables, you can -use Petite -by Ian Luck. This nifty utility compresses Windows executables by around 50%, so your 500KB executable -will shrink to a mere 250KB. With this sort of size, there is reduced incentive to -use DLLs. Another good compression tool (probably better than Petite) is UPX. -

- -Please do not be surprised if MinGW produces a statically-linked minimal executable of 1 MB. Firstly, gcc -produces larger executables than some compilers. Secondly, this figure will -include most of the overhead of wxWidgets, so as your application becomes more -complex, the overhead becomes proportionally less significant. And thirdly, trading executable compactness -for the enormous increase in productivity you get with wxWidgets is almost always well worth it.

- -If you have a really large executable compiled with MinGW (for example 20MB) then -you need to configure wxWidgets to compile without debugging information: see -docs/msw/install.txt for details. You may find that using configure instead -of makefile.g95 is easier, particularly since you can maintain debug and -release versions of the library simultaneously, in different directories. -Also, run 'strip' after linking to remove all traces of debug info. -

- -

Is wxWidgets compatible with MFC?

- -There is a sample which demonstrates MFC and wxWidgets code co-existing in the same -application. However, don't expect to be able to enable wxWidgets windows with OLE-2 -functionality using MFC.

- -

Why do I get errors about setup.h not being found?

- -When you build the wxWidgets library, setup.h is copied -from include/wx/msw/setup.h to e.g. lib/vc_msw/mswd/wx/setup.h (the path -depends on the configuration you're building). So you need to add -this include path if building using the static Debug library:

- -lib/vc_lib/mswd

- -or if building the static Release library, lib/vc_lib/msw.

- -See also the wxWiki Contents -for more information.

- - -

Why do I get errors about FooBarA when I only use FooBar in my program?

- -If you get errors like -

-

-no matching function for call to 'wxDC::DrawTextA(const char[5], int, -int)' -
-

-or similar ones for the other functions, i.e. the compiler error messages -mention the function with the 'A' suffix while you didn't -use it in your code, the explanation is that you had included -<windows.h> header which redefines many symbols to have such -suffix (or 'W' in the Unicode builds). - -

-The fix is to either not include <windows.h> at all or include -"wx/msw/winundef.h" immediately after it. - -

Why my code fails to compile with strange errors about new operator?

- -The most common cause of this problem is the memory debugging settings in -wx/msw/setup.h. You have several choices: - - - -Notice that IMHO the first solution is preferable for VC++ users who can use -the VC++ CRT memory debugging features instead. - -

How do I port MFC applications to wxWidgets?

- -Set up your interface from scratch using wxWidgets (especially wxDesigner -or DialogBlocks -- -it'll save you a lot of time) and when you have a shell prepared, you can start -'pouring in' code from the MFC app, with appropriate -modifications. This is the approach I have used, and I found -it very satisfactory. A two-step process then - reproduce the bare -interface first, then wire it up afterwards. That way you deal -with each area of complexity separately. Don't try to think MFC -and wxWidgets simultaneously from the beginning - it is easier to -reproduce the initial UI by looking at the behaviour of the MFC -app, not its code. - -

Why do I sometimes get bizarre crash problems using VC++ 5/6?

- -Some crash problems can be due to inconsistent compiler -options (and of course this isn't limited to wxWidgets). -If strange/weird/impossible things start to happen please -check (dumping IDE project file as makefile and doing text comparison -if necessary) that the project settings, especially the list of defined -symbols, struct packing, etc. are exactly the same for all items in -the project. After this, delete everything (including PCH) and recompile.

- -VC++ 5's optimization code seems to be broken and can -cause problems: this can be seen when deleting an object Dialog -Editor, in Release mode with optimizations on. If in doubt, -switch off optimisations, although this will result in much -larger executables. It seems possible that the library can be created with -strong optimization, so long as the application is not strongly -optimized. For example, in wxWidgets project, set to 'Minimum -Size'. In Dialog Editor project, set to 'Customize: Favor Small -Code' (and no others). This will then work.

- -

How are the wxWidgets makefiles edited under Windows?

- -wxWidgets 2.5.x and above uses Bakefile to generate makefiles, which -is described in technical note 16 under docs/tech in your distribution.

- -For 2.4.x, there is a system written by Vadim Zeitlin that -generates the makefiles from templates using tmake.

- -Here are Vadim's notes on tmake:

- -

-To use these new makefiles, you don't need anything (but see below). -However, you should NOT modify them because these files will be -rewritten when I regenerate them using tmake the next time. So, if -you find a problem with any of these makefiles (say, makefile.b32) -you'll need to modify the corresponding template (b32.t in this -example) and regenerate the makefile using tmake.

- -tmake can be found at -www.troll.no/freebies/tmake.html. -It's a Perl5 program and so it needs Perl (doh). There is a binary for -Windows (available from the same page), but I haven't used it, so -I don't know if it works as flawlessly as "perl tmake" does (note -for people knowing Perl: don't try to run tmake with -w, it won't -do you any good). Using it extremely simple: to regenerate makefile.b32 -just go to distrib/msw/tmake and type

- -

tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32

- -The makefiles are untested - I don't have any of Borland, Watcom or -Symantec and I don't have enough diskspace to recompile even with -VC6 using makefiles. The new makefiles are as close as possible to the -old ones, but not closer: in fact, there has been many strange things -(should I say bugs?) in some of makefiles, some files were not compiled -without any reason etc. Please test them and notify me about any problems. -Better yet, modify the template files to generate the correct makefiles -and check them in.

- -The templates are described in tmake ref manual (1-2 pages of text) -and are quite simple. They do contain some Perl code, but my Perl is -primitive (very C like) so it should be possible for anybody to make -trivial modifications to it (I hope that only trivial modifications -will be needed). I've tagged the ol makefiles as MAKEFILES_WITHOUT_TMAKE -in the cvs, so you can always retrieve them and compare the new ones, -this will make it easier to solve the problems you might have.

- -Another important file is filelist.txt: it contains the list of all -files to be compiled. Some of them are only compiled in 16/32 bit mode. -Some other are only compiled with some compilers (others can't compile -them) - all this info is contained in this file.

- -So now adding a new file to wxWidgets is as easy as modifying filelist.txt -(and Makefile.ams for Unix ports) and regenerating the makefiles - no -need to modify all files manually any more.

- - Finally, there is also a file vc6.t which I use myself: this one -generates a project file for VC++ 6.0 (I didn't create vc5.t because -I don't need it and can't test it, but it should be trivial to create -one from vc6.t - probably the only things to change would be the -version number in the very beginning and the /Z option - VC5 doesn't -support edit-and=continue). This is not an officially supported way -of building wxWidgets (that is, nobody guarantees that it will work), -but it has been very useful to me and I hope it will be also for -others. To generate wxWidgets.dsp run

- -

tmake -t vc6 wxwin.pro -o ../../wxWidgets.dsp

- -Then just include this project in any workspace or open it from VC IDE -and it will create a new workspace for you.

- -If all goes well, I'm planning to create a template file for Makefile.ams -under src/gtk and src/motif and also replace all makefiles in the samples -subdirectories with the project files from which all the others will be -generated. At least it will divide the number of files in samples -directory by 10 (and the number of files to be maintained too). -

- -

- -

How do you use VC++'s memory leak checking instead of that in wxWidgets?

- -Vadim Zeitlin: - -
-On the VC++ level, it's just the matter of calling _CrtSetDbgFlag() in the very
-beginning of the program. In wxWidgets, this is done automatically when
-compiling with VC++ in debug mode unless wxUSE_GLOBAL_MEMORY_OPERATORS or
-__NO_VC_CRTDBG__ are defined - this check is done in wx/msw/msvcrt.h which
-is included from app.cpp which then calls wxCrtSetDbgFlag() without any
-ifdefs.
-
-This works quite well: at the end of the program, all leaked blocks with their
-malloc count are shown. This number (malloc count) can be used to determine
-where exactly the object was allocated: for this it's enough to set the variable
-_crtBreakAlloc (look in VC98\crt\srs\dbgheap.c line 326) to this number and
-a breakpoint will be triggered when the block with this number is allocated.
-
-For simple situations it works like a charm. For something more complicated
-like reading uninitialized memory a specialized tool is probably better...
-
-Regards,
-VZ
-
- -

- -

Why are menu hotkeys or shortcuts not working in my application?

- -This can happen if you have a child window intercepting EVT_CHAR events and swallowing -all keyboard input. You should ensure that event.Skip() is called for all input that -isn'used by the event handler.

- -It can also happen if you append the submenu to the parent -menu {\it before} you have added your menu items. Do the append {\it after} adding -your items, or accelerators may not be registered properly.

- -

Why can I not write to the HKLM part of the registry with wxRegConfig?

- -Currently this is not possible because the wxConfig family of classes is -supposed to deal with per-user application configuration data, and HKLM is -only supposed to be writeable by a user with Administrator privileges. In theory, -only installers should write to HKLM. This is still a point debated by the -wxWidgets developers. There are at least two ways to work around it if you really -need to write to HKLM.

- -First, you can use wxRegKey directly, for example: - -

-    wxRegKey regKey;
-
-    wxString idName(wxT("HKEY_LOCAL_MACHINE\\SOFTWARE\\My Company\\My Product\\Stuff\\"));
-    idName += packid;
-
-    regKey.SetName(idName);
-
-    {
-        wxLogNull dummy; 
-        if (!regKey.Create())
-        {
-            idName = wxT("HKEY_CURRENT_USER\\SOFTWARE\\My Company\\My Product\\Stuff\\");
-            idName += packid;
-            regKey.SetName(idName);
-            if (!regKey.Create())
-                return FALSE;
-        }
-    }
-
-    if (!regKey.SetValue(wxT("THING"), (long) thing)) err += 1;
-
-    regKey.Close();
-
-
- -Or, you can employ this trick suggested by Istvan Kovacs: - -
-class myGlobalConfig : public wxConfig
-{
-    myGlobalConfig() :
-        wxConfig ("myApp", "myCompany", "", "", wxCONFIG_USE_GLOBAL_FILE)
-{};
-    bool Write(const wxString& key, const wxString& value);
-}
-
-bool myGlobalConfig::Write (const wxString& key, const wxString& value)
-{
-    wxString path = wxString ("SOFTWARE\\myCompany\\myApp\\") + wxPathOnly(key);
-    wxString new_path = path.Replace ("/", "\\", true);
-    wxString new_key = wxFileNameFromPath (key);
-    LocalKey().SetName (wxRegKey::HKLM, path);
-    return wxConfig::Write (new_key, value);
-}
-
- -

Is MS Active Accessibility supported?

- -This is being worked on. Please see this page -for the current status. - -

- - -

Why does Visual C++ complain about corrupted project files?

- -If you have downloaded the wxWidgets sources from the cvs using a Unix cvs -client or downloaded a daily snapshot in .tar.gz format, it is likely -that the project files have Unix line endings (LF) instead of the DOS ones (CR -LF). However all versions of Visual C++ up to and including 7.1 can only open -the files with the DOS line endings, so you must transform the files to this -format using any of the thousands ways to do it. -

-Of course, another possibility is to always use only the Windows cvs client -and to avoid this problem completely. -

- -

Visual C++ gives errors about multiply defined symbols, what can I do?

- -If you get errors like this - -
-MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _xxxxxx already defined in LIBCD.lib(yyyyy.obj)
-
- -when linking your project, this means that you used different versions of CRT -(C Run-Time) library for wxWindows (or possibly another library) and the main -project. Visual C++ provides static or dynamic and multithread safe or not -versions of CRT for each of debug and release builds, for a total of 8 -libraries. You can choose among them by going to the "Code generation" -page/subitem of the "C++" tab/item in the project proprieties dialog in VC6/7. -

-To avoid problems, you must use the same one for all -components of your project. wxWindows uses multithread safe DLL version of the -CRT which is a good choice but may be problematic when distributing your -applications if you don't include the CRT DLL in your installation -- in this -case you may decide to switch to using a static CRT version. If you build with -wxUSE_THREADS == 0 you may also use the non MT-safe version as it is -slightly smaller and faster. -

-But the most important thing is to use the same CRT setting for -all components of your project. - -

Why do I get compilation errors when using wxWidgets with DirectShow?

- -If you get errors when including Microsoft DirectShow or DirectDraw headers, -the following message from Peter Whaite could help: -
-> This causes compilation errors within DirectShow: -> -> wxutil.h(125) : error C2065: 'EXECUTE_ASSERT' : undeclared identifier -> amfilter.h(1099) : error C2065: 'ASSERT' : undeclared identifier - -The reason for this is that __WXDEBUG__ is also used by the DXSDK (9.0 -in my case) to '#pragma once' the contents of -DXSDK/Samples/C++/DirectShow/BaseClasses/wxdebug.h. So if __WXDEBUG__ -is defined, then wxdebug.h doesn't get included, and the assert macros -don't get defined. You have to #undef __WXDEBUG__ before including the -directshow baseclass's <streams.h>. -
- - -

How do I handle Windows messages in my wxWidgets program?

- -To handle a Windows message you need to override a virtual -MSWWindowProc() method in a wxWindow-derived class. You should then -test if nMsg parameter is the message you need to process and perform -the necessary action if it is or call the base class method otherwise. - - - - - - - diff --git a/docs/html/faqx11.htm b/docs/html/faqx11.htm deleted file mode 100644 index 5a7b005a54..0000000000 --- a/docs/html/faqx11.htm +++ /dev/null @@ -1,51 +0,0 @@ - - - - -wxWidgets for X11 FAQ - - - - - - - - - - -
- -wxWidgets for X11 FAQ - -
- -

- -See also top-level FAQ page -and Unix FAQ page. -

-

List of questions in this category

- -
- -

What do I need to compile wxX11?

- -For desktop compilation, you only need X11 (not Xt, GTK+ or any other widget set). -For embedded use, Tiny-X should work fine too. -There is incomplete support for Microwindows (the Nano-X API). - -

- -

What features are missing or partially implemented?

- -The following classes and features are not yet implemented: wxSpinCtrl, wxSocket, wxToggleButton, clipboard classes, -drag and drop classes, tooltips.

- - - - - - diff --git a/docs/html/images/bluetitlegradient.gif b/docs/html/images/bluetitlegradient.gif deleted file mode 100644 index 71793845d8..0000000000 Binary files a/docs/html/images/bluetitlegradient.gif and /dev/null differ diff --git a/docs/html/images/no.gif b/docs/html/images/no.gif deleted file mode 100644 index 65fc311b1d..0000000000 Binary files a/docs/html/images/no.gif and /dev/null differ diff --git a/docs/html/images/somewhat.gif b/docs/html/images/somewhat.gif deleted file mode 100644 index 11dd29b018..0000000000 Binary files a/docs/html/images/somewhat.gif and /dev/null differ diff --git a/docs/html/images/yes.gif b/docs/html/images/yes.gif deleted file mode 100644 index 759fc9e8e9..0000000000 Binary files a/docs/html/images/yes.gif and /dev/null differ diff --git a/docs/html/index.htm b/docs/html/index.htm deleted file mode 100644 index f88347d2fc..0000000000 --- a/docs/html/index.htm +++ /dev/null @@ -1,374 +0,0 @@ - - - -wxWidgets Documentation - - - - - - - - - - - -Welcome to wxWidgets, the première cross-platform GUI C++ framework.

- -This is an index of -the plain text, HTML, Windows Help and Acrobat documentation: availability depends on what you've -downloaded from the wxWidgets Web site.

- -

- -[Install] -[Manuals] -[Technical Notes] -[Samples] -[Demos] - -
- -

- - - - - -
- -Installation and release notes - -
- -

- -Unless you installed a binary version of wxWidgets using RPMs, -you will probably have to compile the wxWidgets library first. -Please read the platform-specific readme.txt and install.txt -for how to do this. - -

- -

- -Further platform-specific notes: - - - -

- - - - - -
- -wxWidgets manuals - -
- -

- -To use manuals in wxHTML Help form (extension htb), you can use the HelpView -application, either compiling it from utils/helpview in the distribution, -or downloading a binary, for example from here.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-HTML - -WinHelp - -MS HTML Help - -wxHTML Help - -PDF -
-wxWidgets Reference - -wxWidgets Reference - -wxWidgets Reference - -wxWidgets Reference - -wxWidgets Reference -
-Tex2RTF - -Tex2RTF - -Tex2RTF - -Tex2RTF - -Tex2RTF -
- -

- - - - - -
- -Technical notes - -
- -

- -

- -

- - - - - -
- -Samples - -
- -

- -Each of the following samples demonstrates one or more aspect of wxWidgets.

- -

- - -

- - - - - -
- -Demos - -
- -

- -The following are fully-fledged applications.

- -

- - - - - - - diff --git a/docs/html/logo.gif b/docs/html/logo.gif deleted file mode 100644 index 7563bc44ae..0000000000 Binary files a/docs/html/logo.gif and /dev/null differ diff --git a/docs/html/news.htm b/docs/html/news.htm deleted file mode 100644 index 13e2114a77..0000000000 --- a/docs/html/news.htm +++ /dev/null @@ -1,389 +0,0 @@ - - - -News - - - - - - - - - - -
- -News - -
- -

July 28th, 2000

- -

- -

July 9th, 2000

- -

- -

June 4th, 2000

- -

- -

March 28th, 2000

- -

- -

March 21st, 2000

- -

- -

January 14th, 2000

- -

- - -

November 9th, 1999

- -wxWindows 2.1.11 is now available for Windows, Motif and GTK. -The final 2.2 public release will have further bug fixes, but 2.1.11 is pretty stable - a big improvement -on 2.0.1 and better than previous snapshots. Here are a few of the features that make it well worth the upgrade:

- -

- -

August 6th, 1999

- -Today, a snapshot release of the MSW and the GTK ports has been -made. The two snapshots are synchronized and have been tested -for several weeks and should thus be considered to be quite stable. - -Among the many new features that have appeared since version 2.0 -was release are: - -

- - - -

July 31st, 1999

- -We are glad to announce the start of the work on the new wxWindows port - wxBeOS -which will implement wxWindows 2 API for BeOS. -Thanks to Be for donating licenses to wxWindows project to make it possible. -

-If you're interested in helping with this new port, please write to wxWindows -developers mailing list! - -

May 27th, 1999

- -

- -

March 1st, 1999

- -wxWindows 2 launch day!

- -

- -

November 26th 1998

- -

- -

September 13th 1998

- -

- -

August 23rd 1998

- -

- -

April 28th 1998

- -

- -

March 22nd 1998

- -

- -

January 5th 1998

- -

- -

August 13th 1997

- -

- -

July 24th 1997

- -

- -

July 22nd 1997

- -

- -

July 16th 1997

- -

- -

July 7th 1997

- -

- -

May 18th 1997

- -

- -

- -

May 8th 1997

- -

- -

- -

April 20th 1997

- -

- -

-

March 13th 1997

- -

- -

- -

February 25th 1997

- -

- -

- -

January 29th 1997

- -

- -

- - - - - - diff --git a/docs/html/platform.htm b/docs/html/platform.htm deleted file mode 100644 index 993ee1f6ee..0000000000 --- a/docs/html/platform.htm +++ /dev/null @@ -1,209 +0,0 @@ - - - - Platforms supported by wxWindows 2.4 - - - - - - - - - - - -
- -Supported Platforms - -
- -

- -You will find below the list of all supported platforms for different ports of -wxWindows 2.x (wxMSW/wxGTK/wxMotif ports only). The cross icon in the third -column doesn't always mean that the platform is not supported, but may just -wxWindows hasn't been tested on it recently (the table is being updated for -wxWindows 2.5.1 currently). -

-See also: - -

- -

-If you have tested wxWindows on a platform not mentioned here, please tell us about your experience on our mailing list! -We would especially like to have information about compiling wxGTK on other Unix variants, such as IRIX, DG-UX, -other flavours of BSD, ... Please note that you will generally need GNU make -(also known as gmake) to compile wxWindows, native make programs -often don't work. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
wxWindows 2 Platforms
Platform Compiler Status Tested by Remarks
Win32
(Win 9x/NT/2K)		Visual C++ 4.2/5.x/6.0OkVZ, JSProject files are provided for all versions except 4.2
Borland C++ 5.0Ok
Also works with free command line Borland C++ 5.5
Mingw32OkGRG, VZCross compilation from Linux works as well
- Version 2.95.2 recommended, otherwise some (included) patches must be applied
- Memory debugging code doesn't seem to work well
CygwinOkStephane Junique
Andrea Venturoli		tested under NT 4, cross-compiling for mingw also works
Watcom C++ 10AlmostJSTested with 10.6: works, but wxImage seems to be broken
no support for JPEG, TIFF or OpenGL
Watcom C++ 11OkMarkus NeiferTested with 11.0b under win95
Open Watcom 1.0OkChris ElliottTested with 1.0 under W2K(?)
Digital Mars (was Symantec C++)OkChris ElliottTested with 8.34beta
Win64
(Windows XP/2003)		Visual C++ 7.1No Some minor corrections not done yet but will be in time for 2.6.0...
Win16
(Windows 3.1)		Visual C++ 1.52Ok
Some features are missing (OLE related classes, threads, ...)
- Borland C++ can't cope with ODBC, resources and new wxGrid class.
- Last working version is wxWindows 2.2.7, - support for Win16 has been abandoned in 2.4.x. - and all traces of Win16 code were removed - after cvs BEFORE_WIN16_REMOVAL tag
Borland C++ 4.0/5.0OkJS
Linux x86wxGTK with gcc 2.7.2Unknown
Might work, but nobody uses it any more
wxGTK with gcc 2.95--3.3OkVZ, RR
wxMotifOk
with LessTif 0.87
wxMotifOk
with OpenMotif

 All BSD systems tests are for wxGTK using gcc.
FreeBSDall versions between 3.2 and 5.1 x86OkVZ
NetBSD1.6, AlphaOkVZ
OpenBSD3.1, AlphaOkVZSome problems with shared libraries, ok with static ones
SolariswxMotif with Sun CC 4.2OkVZThread support must be disabled on system with not MT-safe X11
wxMotif with gccOk

wxGTK with Sun CC 4.2Ok 
wxGTK with gccOk

wxGTK with Sun CC 5.0 and 6.1 (Solaris 7 and 8)OkJiri MracekYou have to edit line 2079 in glib.h to fix GTK+ error
wxGTK 2.5.1 with Sun CC 6.2 (Solaris 6 and 8)OkCarl GodkinUsing GNU make
AIXwxGTK 2.2.9 with gcc 3.0.4OkIan BrownShared library building doesn't work, use --disable-shared
wxGTK 2.3.3 with xlC (AIX 4.3.2)OkIrvin ProbstBoth static and shared wxGTK libraries work, but only with static GTK+ and GLib
wxMotif with xlC 3.1.4.0 (AIX 4.2)OkBernhard EckSome problems with OpenGL and native X server
wxX11 2.4.2 with xlC 6 (AIX 5.1)OkSwengtooIn 2.4.2 you need to remove parentheses from the configure line containing AIX_CXX_LD; you should also use GNU make
HP-UX
HP-UX 10.20 wxGTK with HP CC A.10.22
or HP aCC B3910B A.01.18		OkStaf Verhaegenyou need to add -Aa -D_HPUX_SOURCE to CFLAGS
HP-UX 10.20 wxGTK with gccOkJulian Albo Garcia
HP-UX 11i v1 PA-RISC, wxMotif 2.5.4, tried aCC A.03.57 and g++ 3.4.2OkIan, MikeFor a 32-bit PA-RISC build, if you want to use SHLIB_PATH to make it easier to use - wxWidgets without installing it, then add LDFLAGS=-Wl,+s
- If you want to compile the test suite then aCC A.03.57 requires CXX='aCC -AA'
- aCC can also be used as the C compiler instead of cc by adding CC='aCC -Ae' -
HP-UX 11i v2 IA64, wxMotif 2.5.4, aCC A.06.00OkMike
IRIX
- Note that all entries use MIPSPro 7.3 compiler on IRIX 6.5 with -mips3 -n32 flags if not mentioned otherwise. - Also note that you need to set LD_LIBRARYN32_PATH under IRIX to run wxWindows programs. -
wxGTK 2.2OkIanYou may need to use --disable-catch_segvs if you get compiler error in utilsunx.cpp
wxGTK 2.5OkCarl Godkin
wxMotifOkDavid MarshallOn IRIX 6.5.6 (Indigo2, 64bit), with SGI Motif 1.2
OkIan
SCO UnixWarewxGTK with gccOkWilliam SuetholzUnixWare 2.1.3 with UnixWare 7 compatibility PTF
DEC OSF/1wxGTK with gccOkFabrice DidierjeanOSF1 4.0 on Dec Alpha
- you may need to run configure with --host=alpha-dec-osf switch
OS/2
No
Starting with wxWidgets-2.9.0, wxWidgets supports Unicode builds only. Unfortunately, Unicode support is currently insufficient in all C libraries on OS/2, so only wxWidgets-2.8.x can be used.
OpenVMSwxGTK with Compaq-C++ V6.2 (OpenVMS Alpha 7.3)OkJouk Jansen
Linux S/390wxGTK with gcc 2.95.2OkVZ2.3.1+ only
Mac OS
wxMac CFM (OS 8.6+)OkSCwith Metrowerks CodeWarrior 8.3
wxMac Mach-O (OS X)OkSCCodeWarrior or Apple DevTools (gcc)
wxCocoa (OS X)SomewhatDEApple DevTools (gcc)
- -
- -

-Contact Vadim Zeitlin with -any comments/suggestions. - - - - - - -