docs/html/faqmsw.htm

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