update (c), remove NumLock/CapsLock Motif item

1 files changed, 9 insertions, 16 deletions

diff --git a/bundles/org.eclipse.swt/readme_swt.html b/bundles/org.eclipse.swt/readme_swt.html
index c07e95a9ee..334b77954f 100755
--- a/bundles/org.eclipse.swt/readme_swt.html
+++ b/bundles/org.eclipse.swt/readme_swt.html
@@ -16,7 +16,7 @@ Notes</b></td>
 

 <h3>

 Notices</h3>

-(c) Copyright IBM Corp. 2000, 2001. All Rights Reserved.

+(c) Copyright IBM Corp. 2000, 2001, 2002. All Rights Reserved.

 <h3>

 Table Of Contents</h3>

 &nbsp;1. Known Issues

@@ -31,14 +31,7 @@ is unable to allocate the default widget background color causing it to display
 The functionality,  however, is not affected.

 

 <h4>

-99.1.2 Motif Accelerators</h4>

-

-Keyboard accelerators on motif are sensitive to the state of all modifier keys such as the Caps Lock, 

-Num Lock and Scroll Lock keys.  For example, Ctrl 'S' is not the same as Ctrl 'S' with the Num Lock key on.  

-If keyboard accelerators appear to not be working, please check the state of all other modifier keys.

-

-<h4>

-99.1.3 XInitThreads and Linux</h4>

+99.1.2 XInitThreads and Linux</h4>

 

 SWT makes use of the XInitThreads system function to allow graphics routines to

 be invoked from non-user-interface threads. However, the implementation of XInitThreads

@@ -61,27 +54,27 @@ on Linux has several issues, which cause the following SWT problems:
 </dl>

 

 <h4>

-99.1.4 Disposing in a Focus Event</h4>

+99.1.3 Disposing in a Focus Event</h4>

 

 Applications should not dispose widgets in focus changing events.  Doing so  on Motif may cause Eclipse to terminate,

 since Motif accesses the disposed widget within their internal focus change event handler.

 Similar but less serious issues exist on Windows such that occasionally an SWT exception can be thrown.

 

 <h4>

-99.1.5 List and ComboBox on Windows NT</h4>

+99.1.4 List and ComboBox on Windows NT</h4>

 

 On Windows NT only, you should avoid creating items in a List or ComboBox with strings longer than 1000 characters.

 Doing so may result in a General Protection Fault.  This has been fixed in more recent versions of Windows.

 

 <h4>

-99.1.6 BiDi Support</h4>

+99.1.5 BiDi Support</h4>

 

 The StyledText widget now provides bidirectional language support for Hebrew and Arabic locales.

 Currently, this support is available only on win32, and has several known problems. It should be

 considered to be a preliminary implementation only.

 

 <h4>

-99.1.7 Cursor constructor arguments</h4>

+99.1.6 Cursor constructor arguments</h4>

 

 In the constructor <code>Cursor(Device device, ImageData source, ImageData mask, int hotspotX, int hotspotY)</code>,

 when both a source and mask argument are specified (i.e. mask is not null), the meaning of the two arguments is

@@ -90,7 +83,7 @@ mask image. This problem was discovered too late in the development cycle to be
 fix this in a future release, potentially by introducing a new more general constructor.

 

 <h4>

-99.1.8 Use of the "&" character in TabFolder</h4>

+99.1.7 Use of the "&" character in TabFolder</h4>

 

 The "&" character is not currently supported in TabFolder labels. Doing so on win32, will cause the

 character which follows the "&" to be underlined as if it was a mnemonic, even though mnemonics are

@@ -98,14 +91,14 @@ not available for TabFolders. On other platforms, the "&" character will be disp
 for portability reasons, it should be avoided.

 

 <h4>

-99.1.9  ToolBar on Windows</h4>

+99.1.8  ToolBar on Windows</h4>

 

 On Windows, you must create all tool bars with the FLAT style bit set. If you do not do this,

 the "hot" (rollover) images of <em>all</em> toolbars may display incorrectly.

 This will be fixed in a future release.

 

 <h4>

-99.1.10  Non ASCII strings on Linux</h4>

+99.1.9  Non ASCII strings on Linux</h4>

 

 On Linux RedHat 6.2 only, you will not be able to display text that contains non

 ASCII characters. This limitation is not present on Linux RedHat 7.1 or higher.