docs/html/faqmsw.htm

   1 <HTML>
   2
   3 <HEAD>
   4 <TITLE>wxWindows 2 for Windows FAQ</TITLE>
   5 </HEAD>
   6
   7 <BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
   8
   9 <font face="Arial, Lucida Sans, Helvetica">
  10
  11 <table width=100% border=0 cellpadding=3 cellspacing=0>
  12 <tr>
  13 <td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
  14 <font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
  15 <b>wxWindows 2 for Windows FAQ</b>
  16 </font>
  17 </td>
  18 </tr>
  19 </table>
  20
  21 <P>
  22
  23 See also <a href="faq.htm">top-level FAQ page</a>.
  24 <hr>
  25 <h3>List of questions in this category</h3>
  26 <ul>
  27 <li><a href="#platforms">Which Windows platforms are supported?</a></li>
  28 <li><a href="#wince">What about Windows CE?</a></li>
  29 <li><a href="#winxp">What do I need to do for Windows XP?</a></li>
  30 <li><a href="#compilers">What compilers are supported?</a></li>
  31 <li><a href="#bestcompiler">Which is the best compiler to use with wxWindows 2?</a></li>
  32 <li><a href="#unicode">Is Unicode supported?</a></li>
  33 <li><a href="#doublebyte">Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)?</a></li>
  34 <li><a href="#dll">Can you compile wxWindows 2 as a DLL?</a></li>
  35 <li><a href="#exesize">How can I reduce executable size?</a></li>
  36 <li><a href="#mfc">Is wxWindows compatible with MFC?</a></li>
  37 <li><a href="#setuph">Why do I get errors about setup.h not being found?</a></li>
  38 <li><a href="#asuffix">Why do I get errors about FooBarA when I only use FooBar in my program?</a></li>
  39 <li><a href="#newerrors">Why my code fails to compile with strange errors about new operator?</a></li>
  40 <li><a href="#mfcport">How do I port MFC applications to wxWindows?</a></li>
  41 <li><a href="#crash">Why do I sometimes get bizarre crash problems using VC++ 5/6?</a></li>
  42 <li><a href="#makefiles">How are the wxWindows makefiles edited under Windows?</a></li>
  43 <li><a href="#vcdebug">How do you use VC++&#39;s memory leak checking instead of that in wxWindows?</a></li>
  44 <li><a href="#shortcutproblem">Why are menu hotkeys or shortcuts not working in my application?</a></li>
  45 <li><a href="#regconfig">Why can I not write to the HKLM part of the registry with wxRegConfig?</a></li>
  46 <li><a href="#access">Is MS Active Accessibility supported?</a></li>
  47 <li><a href="#dspfmt">Why does Visual C++ complain about corrupted project files??</a></li>
  48 </ul>
  49 <hr>
  50
  51 <h3><a name="platforms">Which Windows platforms are supported?</a></h3>
  52
  53 wxWindows 2 can be used to develop and deliver applications on Windows 3.1, Win32s,
  54 Windows 95, Windows 98, Windows NT, Windows 2000, and Windows XP. A Windows CE
  55 version is being looked into (see below).<P>
  56
  57 wxWindows 2 is designed to make use of WIN32 features and controls. However, unlike Microsoft,
  58 we have not forgotten users of 16-bit Windows. Most features
  59 work under Windows 3.1, including wxTreeCtrl and wxListCtrl using the generic implementation.
  60 However, don&#39;t expect very Windows-95-specific classes to work, such as wxTaskBarIcon. The wxRegConfig
  61 class doesn&#39;t work either because the Windows 3.1 registry is very simplistic. Check out the 16-bit
  62 makefiles to see what other files have been left out.
  63 <P>
  64 16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5.
  65 <P>
  66
  67 wxWindows 2 for Windows will also compile on Unix with gcc using Wine from <a href="http://www.winehq.org" target=_top>WineHQ</a>.
  68 The resulting executables are Unix binaries that work with the Wine Windows API emulator.<P>
  69
  70 You can also compile wxWindows 2 for Windows on Unix with Cygwin or Mingw32, resulting
  71 in executables that will run on Windows. So in theory you could write your applications
  72 using wxGTK or wxMotif, then check/debug your wxWindows for Windows
  73 programs with Wine, and finally produce an ix86 Windows executable using Cygwin/Mingw32,
  74 without ever needing a copy of Microsoft Windows. See the Technical Note on the Web site detailing cross-compilation.<P>
  75
  76 <h3><a name="wince">What about Windows CE?</a></h3>
  77
  78 This port is largely complete. For further information, see the <a href="http://www.wxwindows.org/embedded.htm#wxwince">wxEmbedded</a> page.<P>
  79
  80 <h3><a name="winxp">What do I need to do for Windows XP?</a></h3>
  81
  82 In the same directory as you have your executable (e.g. foo.exe) you
  83 put a file called foo.exe.manifest in which you have something like
  84 the following:
  85
  86 <pre>
  87 &lt;?xml version="1.0" encoding="UTF-8" standalone="yes"?&gt;
  88 &lt;assembly
  89    xmlns="urn:schemas-microsoft-com:asm.v1"
  90    manifestVersion="1.0"&gt;
  91 &lt;assemblyIdentity
  92     processorArchitecture="x86"
  93     version="5.1.0.0"
  94     type="win32"
  95     name="foo.exe"/&gt;
  96     &lt;description&gt;Foo program&lt;/description&gt;
  97     &lt;dependency&gt;
  98     &lt;dependentAssembly&gt;
  99     &lt;assemblyIdentity
 100          type="win32"
 101          name="Microsoft.Windows.Common-Controls"
 102          version="6.0.0.0"
 103          publicKeyToken="6595b64144ccf1df"
 104          language="*"
 105          processorArchitecture="x86"/&gt;
 106     &lt;/dependentAssembly&gt;
 107     &lt;/dependency&gt;
 108 &lt;/assembly&gt;
 109 </pre>
 110
 111 If you want to add it to your application permanently,
 112 you can also include it in your .rc file using this
 113 line:<P>
 114
 115 <PRE>
 116   1 24 "winxp.manifest"
 117 </PRE>
 118
 119 In wxWindows 2.5, this will be in the wx/msw/wx.rc and
 120 so will happen automatically so long as you include wx.rc
 121 in your own .rc file.<P>
 122
 123 For an explanation of this syntax, please see
 124 <a href="http://delphi.about.com/library/bluc/text/uc111601a.htm" target=_new>this
 125 article</a>.
 126 <P>
 127
 128 <h3><a name="compilers">What compilers are supported?</a></h3>
 129
 130 Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but
 131 currently the following are known to work:<P>
 132
 133 <ul>
 134 <li>Visual C++ 1.5, 4.0, 5.0, 6.0, 7.0, 7.1
 135 <li>Borland C++ 4.5, 5.0, 5.5
 136 <li>Borland C++Builder 1.0, 3.0, X
 137 <li>Watcom C++ 10.6 (Win32), OpenWatcom 1.0
 138 <li>Cygwin (using configure)
 139 <li>Mingw32
 140 <li>MetroWerks CodeWarrior (many versions)
 141 <li>Digital Mars 8.34+
 142 </ul>
 143 <P>
 144
 145
 146 <h3><a name="bestcompiler">Which is the best compiler to use with wxWindows 2?</a></h3>
 147
 148 It&#39;s partly a matter of taste, but I (JACS) prefer Visual C++ since the debugger is very
 149 good, it&#39;s very stable, the documentation is extensive, and it generates small executables.
 150 Since project files are plain text, it&#39;s easy for me to generate appropriate project files
 151 for wxWindows samples.<P>
 152
 153 Borland C++ is fine - and very fast - but it&#39;s hard (impossible?) to use the debugger without using project files, and
 154 the debugger is nowhere near up to VC++&#39;s quality. The IDE isn&#39;t great.<P>
 155
 156 C++Builder&#39;s power isn&#39;t really used with wxWindows since it needs integration with its
 157 own class library (VCL). For wxWindows, I&#39;ve only used it with makefiles, in which case
 158 it&#39;s almost identical to BC++ 5.0 (the same makefiles can be used).<P>
 159
 160 You can&#39;t beat Cygwin&#39;s price (free), and you can debug adequately using gdb. However, it&#39;s
 161 quite slow to compile since it does not use precompiled headers.<P>
 162
 163 CodeWarrior is cross-platform - you can debug and generate Windows executables from a Mac, but not
 164 the other way around I think - but the IDE is, to my mind, a bit primitive.<P>
 165
 166 Watcom C++ is a little slow and the debugger is not really up to today&#39;s standards.<P>
 167
 168 Among the free compilers the best choice seem to be Borland C++ command line
 169 tools and mingw32 (port of gcc to Win32). Both of them are supported by
 170 wxWindows.
 171
 172 <h3><a name="unicode">Is Unicode supported?</a></h3>
 173
 174 Yes, Unicode is fully supported under Windows NT/2000 and there is limited
 175 support for it under Windows 9x using <a
 176 href="http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx">MSLU</a>.
 177 <p>
 178
 179 <h3><a name="doublebyte">Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)?</a></h3>
 180
 181 For Japanese under Win2000, it seems that wxWindows has no problems to work
 182 with double byte char sets (meaning DBCS, not Unicode). First you have to
 183 install Japanese support on your Win2K system and choose for ANSI translation
 184 <tt>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage=932</tt>
 185 (default is 1252 for Western). Then you can see all the Japanese letters in
 186 wxWindows applications.
 187 <p>
 188
 189 <h3><a name="dll">Can you compile wxWindows 2 as a DLL?</a></h3>
 190
 191 Yes (using the Visual C++ or Borland C++ makefile), but be aware that distributing DLLs is a thorny issue
 192 and you may be better off compiling statically-linked applications, unless you&#39;re
 193 delivering a suite of separate programs, or you&#39;re compiling a lot of wxWindows applications
 194 and have limited hard disk space.<P>
 195
 196 With a DLL approach, and with different versions and configurations of wxWindows
 197 needing to be catered for, the end user may end up with a host of large DLLs in his or her Windows system directory,
 198 negating the point of using DLLs. Of course, this is not a problem just associated with
 199 wxWindows!
 200 <P>
 201
 202 <h3><a name="exesize">How can I reduce executable size?</a></h3>
 203
 204 You can compile wxWindows as a DLL (see above, VC++/BC++ only at present). You should also
 205 compile your programs for release using non-debugging and space-optimisation options, but
 206 take with VC++ 5/6 space optimisation: it can sometimes cause problems.<P>
 207
 208 If you want to distribute really small executables, you can
 209 use <a href="http://www.un4seen.com/petite/" target=_top>Petite</a>
 210 by Ian Luck. This nifty utility compresses Windows executables by around 50%, so your 500KB executable
 211 will shrink to a mere 250KB. With this sort of size, there is reduced incentive to
 212 use DLLs. Another good compression tool (probably better than Petite) is <a href="http://upx.sourceforge.net/" target=_top>UPX</a>.
 213 <P>
 214
 215 Please do not be surprised if MinGW produces a statically-linked minimal executable of 1 MB. Firstly, gcc
 216 produces larger executables than some compilers. Secondly, this figure will
 217 include most of the overhead of wxWindows, so as your application becomes more
 218 complex, the overhead becomes proportionally less significant. And thirdly, trading executable compactness
 219 for the enormous increase in productivity you get with wxWindows is almost always well worth it.<P>
 220
 221 If you have a really large executable compiled with MinGW (for example 20MB) then
 222 you need to configure wxWindows to compile without debugging information: see
 223 docs/msw/install.txt for details. You may find that using configure instead
 224 of makefile.g95 is easier, particularly since you can maintain debug and
 225 release versions of the library simultaneously, in different directories.
 226 Also, run 'strip' after linking to remove all traces of debug info.
 227 <P>
 228
 229 <H3><a name="mfc">Is wxWindows compatible with MFC?</a></H3>
 230
 231 There is a sample which demonstrates MFC and wxWindows code co-existing in the same
 232 application. However, don&#39;t expect to be able to enable wxWindows windows with OLE-2
 233 functionality using MFC.<P>
 234
 235 <H3><a name="setuph">Why do I get errors about setup.h not being found?</a></H3>
 236
 237 When you build the wxWindows library, setup.h is copied
 238 from include/wx/msw/setup.h to e.g. lib/mswd/wx/setup.h (the path
 239 depends on the configuration you&#39;re building). So you need to add
 240 this include path if building using the static Debug library:<P>
 241
 242 lib/mswd<P>
 243
 244 or if building the static Release library, lib/msw.<P>
 245
 246 See also the <a href="http://wiki.wxwindows.org/wiki.pl?Table_Of_Contents">wxWiki Contents</a>
 247 for more information.<P>
 248
 249
 250 <H3><a name="asuffix">Why do I get errors about FooBarA when I only use FooBar in my program?</H3>
 251
 252 If you get errors like
 253 <p>
 254 <center>
 255 <tt>no matching function for call to &#39;wxDC::DrawTextA(const char[5], int,
 256 int)&#39;</tt>
 257 </center>
 258 <p>
 259 or similar ones for the other functions, i.e. the compiler error messages
 260 mention the function with the <tt>&#39;A&#39;</tt> suffix while you didn&#39;t
 261 use it in your code, the explanation is that you had included
 262 <tt>&#60;windows.h&#062;</tt> header which redefines many symbols to have such
 263 suffix (or <tt>&#39;W&#39;</tt> in the Unicode builds).
 264
 265 <p>
 266 The fix is to either not include <tt>&#60;windows.h&#62;</tt> at all or include
 267 <tt>"wx/msw/winundef.h"</tt> immediately after it.
 268
 269 <H3><a name="newerrors">Why my code fails to compile with strange errors about new operator?</a></H3>
 270
 271 The most common cause of this problem is the memory debugging settings in
 272 <tt>wx/msw/setup.h</tt>. You have several choices:
 273
 274 <ul>
 275     <li> Either disable overloading the global operator new completely by
 276          setting <tt>wxUSE_GLOBAL_MEMORY_OPERATORS</tt> and
 277          <tt>wxUSE_DEBUG_NEW_ALWAYS</tt> to 0 in this file
 278     <li> Or leave them on but do <tt>#undef new</tt> after including any
 279          wxWindows headers, like this the memory debugging will be still on
 280          for wxWindows sources but off for your own code
 281 </ul>
 282
 283 Notice that IMHO the first solution is preferable for VC++ users who can use
 284 the <a href="#vcdebug">VC++ CRT memory debugging features</a> instead.
 285
 286 <H3><a name="mfcport">How do I port MFC applications to wxWindows?</a></H3>
 287
 288 Set up your interface from scratch using wxWindows (especially <a href="http://www.robeling.de" target=_top>wxDesigner</a>
 289 or <a href="http://www.anthemion.co.uk/dialogblocks/" target=_new>DialogBlocks</a> --
 290 it&#39;ll save you a <i>lot</i> of time) and when you have a shell prepared, you can start
 291 &#39;pouring in&#39; code from the MFC app, with appropriate
 292 modifications. This is the approach I have used, and I found
 293 it very satisfactory. A two-step process then - reproduce the bare
 294 interface first, then wire it up afterwards. That way you deal
 295 with each area of complexity separately. Don&#39;t try to think MFC
 296 and wxWindows simultaneously from the beginning - it is easier to
 297 reproduce the initial UI by looking at the behaviour of the MFC
 298 app, not its code.
 299
 300 <H3><a name="crash">Why do I sometimes get bizarre crash problems using VC++ 5/6?</a></H3>
 301
 302 Some crash problems can be due to inconsistent compiler
 303 options (and of course this isn&#39;t limited to wxWindows).
 304 If strange/weird/impossible things start to happen please
 305 check (dumping IDE project file as makefile and doing text comparison
 306 if necessary) that the project settings, especially the list of defined
 307 symbols, struct packing, etc. are exactly the same for all items in
 308 the project. After this, delete everything (including PCH) and recompile.<P>
 309
 310 VC++ 5&#39;s optimization code seems to be broken and can
 311 cause problems: this can be seen when deleting an object Dialog
 312 Editor, in Release mode with optimizations on. If in doubt,
 313 switch off optimisations, although this will result in much
 314 larger executables. It seems possible that the library can be created with
 315 strong optimization, so long as the application is not strongly
 316 optimized. For example, in wxWindows project, set to &#39;Minimum
 317 Size&#39;. In Dialog Editor project, set to &#39;Customize: Favor Small
 318 Code&#39; (and no others). This will then work.<P>
 319
 320 <H3><a name="makefiles">How are the wxWindows makefiles edited under Windows?</a></H3>
 321
 322 As of wxWindows 2.1, there is a new system written by Vadim Zeitlin, that
 323 generates the makefiles from templates using tmake.<P>
 324
 325 Here are Vadim&#39;s notes:<P>
 326
 327 <blockquote>
 328 To use these new makefiles, you don&#39;t need anything (but see below).
 329 However, you should NOT modify them because these files will be
 330 rewritten when I regenerate them using tmake the next time. So, if
 331 you find a problem with any of these makefiles (say, makefile.b32)
 332 you&#39;ll need to modify the corresponding template (b32.t in this
 333 example) and regenerate the makefile using tmake.<P>
 334
 335 tmake can be found at
 336 <a href="http://www.troll.no/freebies/tmake.html" target=_new>www.troll.no/freebies/tmake.html</a>.
 337 It&#39;s a Perl5 program and so it needs Perl (doh). There is a binary for
 338 Windows (available from the same page), but I haven&#39;t used it, so
 339 I don&#39;t know if it works as flawlessly as "perl tmake" does (note
 340 for people knowing Perl: don&#39;t try to run tmake with -w, it won&#39;t
 341 do you any good). Using it extremely simple: to regenerate makefile.b32
 342 just go to distrib/msw/tmake and type<P>
 343
 344 <pre>tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32</pre><P>
 345
 346 The makefiles are untested - I don&#39;t have any of Borland, Watcom or
 347 Symantec and I don&#39;t have enough diskspace to recompile even with
 348 VC6 using makefiles. The new makefiles are as close as possible to the
 349 old ones, but not closer: in fact, there has been many strange things
 350 (should I say bugs?) in some of makefiles, some files were not compiled
 351 without any reason etc. Please test them and notify me about any problems.
 352 Better yet, modify the template files to generate the correct makefiles
 353 and check them in.<P>
 354
 355 The templates are described in tmake ref manual (1-2 pages of text)
 356 and are quite simple. They do contain some Perl code, but my Perl is
 357 primitive (very C like) so it should be possible for anybody to make
 358 trivial modifications to it (I hope that only trivial modifications
 359 will be needed). I&#39;ve tagged the ol makefiles as MAKEFILES_WITHOUT_TMAKE
 360 in the cvs, so you can always retrieve them and compare the new ones,
 361 this will make it easier to solve the problems you might have.<P>
 362
 363 Another important file is filelist.txt: it contains the list of all
 364 files to be compiled. Some of them are only compiled in 16/32 bit mode.
 365 Some other are only compiled with some compilers (others can&#39;t compile
 366 them) - all this info is contained in this file.<P>
 367
 368 So now adding a new file to wxWindows is as easy as modifying filelist.txt
 369 (and Makefile.ams for Unix ports) and regenerating the makefiles - no
 370 need to modify all files manually any more.<P>
 371
 372  Finally, there is also a file vc6.t which I use myself: this one
 373 generates a project file for VC++ 6.0 (I didn&#39;t create vc5.t because
 374 I don&#39;t need it and can&#39;t test it, but it should be trivial to create
 375 one from vc6.t - probably the only things to change would be the
 376 version number in the very beginning and the /Z option - VC5 doesn&#39;t
 377 support edit-and=continue). This is not an officially supported way
 378 of building wxWindows (that is, nobody guarantees that it will work),
 379 but it has been very useful to me and I hope it will be also for
 380 others. To generate wxWindows.dsp run<P>
 381
 382 <pre>tmake -t vc6 wxwin.pro -o ../../wxWindows.dsp</pre><P>
 383
 384 Then just include this project in any workspace or open it from VC IDE
 385 and it will create a new workspace for you.<P>
 386
 387 If all goes well, I&#39;m planning to create a template file for Makefile.ams
 388 under src/gtk and src/motif and also replace all makefiles in the samples
 389 subdirectories with the project files from which all the others will be
 390 generated. At least it will divide the number of files in samples
 391 directory by 10 (and the number of files to be maintained too).
 392 </blockquote>
 393
 394 <P>
 395
 396 <H3><a name="vcdebug">How do you use VC++&#39;s memory leak checking instead of that in wxWindows?</a></H3>
 397
 398 Vadim Zeitlin:
 399
 400 <pre>
 401 On the VC++ level, it&#39;s just the matter of calling _CrtSetDbgFlag() in the very
 402 beginning of the program. In wxWindows, this is done automatically when
 403 compiling with VC++ in debug mode unless wxUSE_GLOBAL_MEMORY_OPERATORS or
 404 __NO_VC_CRTDBG__ are defined - this check is done in wx/msw/msvcrt.h which
 405 is included from app.cpp which then calls wxCrtSetDbgFlag() without any
 406 ifdefs.
 407
 408 This works quite well: at the end of the program, all leaked blocks with their
 409 malloc count are shown. This number (malloc count) can be used to determine
 410 where exactly the object was allocated: for this it&#39;s enough to set the variable
 411 _crtBreakAlloc (look in VC98\crt\srs\dbgheap.c line 326) to this number and
 412 a breakpoint will be triggered when the block with this number is allocated.
 413
 414 For simple situations it works like a charm. For something more complicated
 415 like reading uninitialized memory a specialized tool is probably better...
 416
 417 Regards,
 418 VZ
 419 </pre>
 420
 421 <P>
 422
 423 <H3><a name="shortcutproblem">Why are menu hotkeys or shortcuts not working in my application?</a></H3>
 424
 425 This can happen if you have a child window intercepting EVT_CHAR events and swallowing
 426 all keyboard input. You should ensure that event.Skip() is called for all input that
 427 isn&#39;used by the event handler.<P>
 428
 429 It can also happen if you append the submenu to the parent
 430 menu {\it before} you have added your menu items. Do the append {\it after} adding
 431 your items, or accelerators may not be registered properly.<P>
 432
 433 <H3><a name="#regconfig">Why can I not write to the HKLM part of the registry with wxRegConfig?</a></H3>
 434
 435 Currently this is not possible because the wxConfig family of classes is
 436 supposed to deal with per-user application configuration data, and HKLM is
 437 only supposed to be writeable by a user with Administrator privileges. In theory,
 438 only installers should write to HKLM. This is still a point debated by the
 439 wxWindows developers. There are at least two ways to work around it if you really
 440 need to write to HKLM.<P>
 441
 442 First, you can use wxRegKey directly, for example:
 443
 444 <pre>
 445     wxRegKey regKey;
 446
 447     wxString idName(wxT("HKEY_LOCAL_MACHINE\\SOFTWARE\\My Company\\My Product\\Stuff\\"));
 448     idName += packid;
 449
 450     regKey.SetName(idName);
 451
 452     {
 453         wxLogNull dummy;
 454         if (!regKey.Create())
 455         {
 456             idName = wxT("HKEY_CURRENT_USER\\SOFTWARE\\My Company\\My Product\\Stuff\\");
 457             idName += packid;
 458             regKey.SetName(idName);
 459             if (!regKey.Create())
 460                 return FALSE;
 461         }
 462     }
 463
 464     if (!regKey.SetValue(wxT("THING"), (long) thing)) err += 1;
 465
 466     regKey.Close();
 467
 468 </pre>
 469
 470 Or, you can employ this trick suggested by Istvan Kovacs:
 471
 472 <pre>
 473 class myGlobalConfig : public wxConfig
 474 {
 475     myGlobalConfig() :
 476         wxConfig ("myApp", "myCompany", "", "", wxCONFIG_USE_GLOBAL_FILE)
 477 {};
 478     bool Write(const wxString& key, const wxString& value);
 479 }
 480
 481 bool myGlobalConfig::Write (const wxString& key, const wxString& value)
 482 {
 483     wxString path = wxString ("SOFTWARE\\myCompany\\myApp\\") + wxPathOnly(key);
 484     wxString new_path = path.Replace ("/", "\\", true);
 485     wxString new_key = wxFileNameFromPath (key);
 486     LocalKey().SetName (wxRegKey::HKLM, path);
 487     return wxConfig::Write (new_key, value);
 488 }
 489 </pre>
 490
 491 <H3><a name="#access">Is MS Active Accessibility supported?</a></H3>
 492
 493 This is being worked on. Please see <a href="http://www.wxwindows.org/access.htm">this page</a>
 494 for the current status.
 495
 496 <P>
 497
 498
 499 <h3><a name="#dspfmt">Why does Visual C++ complain about corrupted project files??</a></h3>
 500
 501 If you have downloaded the wxWindows sources from the cvs using a Unix cvs
 502 client or downloaded a daily snapshot in <tt>.tar.gz</tt> format, it is likely
 503 that the project files have Unix line endings (LF) instead of the DOS ones (CR
 504 LF). However all versions of Visual C++ up to and including 7.1 can only open
 505 the files with the DOS line endings, so you must transform the files to this
 506 format using any of the thousands ways to do it.
 507 <p>
 508 Of course, another possibility is to always use only the Windows cvs client
 509 and to avoid this problem completely.
 510 <p>
 511
 512 </font>
 513
 514 </BODY>
 515
 516 </HTML>