----------------------------------------------------------------

                        HintsAndTips.txt

        Late-breaking news, workarounds, and useful tips

----------------------------------------------------------------

-----------------
TABLE OF CONTENTS
-----------------
SECTION 1. New Functionality and Fixes
A. New Functionality
B. List of Fixes

SECTION 2. Helpful Tips and Workarounds
A. General
B. Install
C. JDK
D. Upgrading JBuilder 1.0 Applications to JBuilder 2.0
E. Using Swing and JBCL Components
F. Using a newer version of Swing (JFC)
G. Deploying Applets and Applications
H. Known Problems
H1. Visual Design Tools and JavaBeans
H2. The jbInit Method
H3. Wizards
H4. KL Group components
H5. Debugger
H6. CodeInsight
H7. IDE
H8. JBCL

SECTION 3: International Issues
A. Install
B. Compiler
C. Visual Design Tools
D. Keyboard Support

--------------------------------------
SECTION 1. New Functionality and Fixes
--------------------------------------

A. New Functionality
--------------------

UI Designer
-----------
* The GridBagConstraints property editor now works with multiple selection and
allows you to change and apply constraints on different components without
closing the property editor.  While in design mode working on a container that
uses GridBagLayout, right-click on one of the components and select Constraints.
This will bring up the Gridbag Constraints property editor that allows you to
make changes to the selected component(s).  Click Apply, and then select another
component to modify.

* The UI designer has a new property editor for properties that take ImageIcons.
This editor populates a list of components of type ImageIcon that are
in scope for the item being designed.  It will also pick up .GIF and .JPG files
that have been added as nodes in the project.

* Improved handling of the Swing (JFC) components in the UI Designer.

Miscellaneous
-------------
* The AppAccelerator (JIT) is now redistributable.  This information supercedes
the online documentation.

To Deploy the AppAccelerator
1. Be sure to include the javacomp.dll from \jbuilder2\redist with any files
   being deployed with your application
2. Before running your application set your path to include the location of
   javacomp.dll.
3. Set the AppAccelerator environment variable to be the JIT compiler used.
   This looks like: "set java_compiler=javacomp" (no quotes).
4. Run as you would any other deployed application.

* The compiler has improved support for inner classes (for example, using inner
classes to initialize the fields of an interface).

* JDK Switching now correctly handles the new locations for classes and tools in
JDK 1.2, Beta 4.

B. List of Fixes
----------------
For a list of fixes in JBuilder 2.01, please look at Fixlist.txt in your
\JBuilder2 directory

---------------------------------------
SECTION 2. Helpful Tips and Workarounds
---------------------------------------
A. General
----------
For the latest information on JBuilder, please see the JBuilder
section on Inprise Online at http://www.inprise.com

The online Help is the most complete and updated version of the
product documentation. To display the online Help, choose Help | Help Topics.

B. Install
----------
* Some tools that come with the JDK do not work when installed to long filename
directories that contain spaces.  Because JBuilder includes and uses tools from
the JDK, it is not recommended that you install to a directory that contains
spaces, such as "Program Files".

* In accordance with Windows conventions, JBuilder automatically updates your
registry to add a file association for .java and .jpr files.  This means
JBuilder launches automatically when you double-click one of these files in your
Explorer.

* If you want to use your own editor to browse .java or .jpr files from the
Explorer, you need to add an Edit command to your right-click menu in the
Explorer.  To do so, follow these steps:

1. Open your Explorer.
2. Choose the View | Options menu item.
3. Select the File Types tab.
4. Scroll down and select the "Java File" file type.
5. Click the Edit button.
6. Click the New button.
7. For the Action, specify Edit.
8. To specify the application to run, click the Browse button and select your
   favorite editor.
9. Click OK three times.

Selecting the new command from the file's right-click menu invokes your editor.
Double-clicking the file still launches JBuilder.

C. JDK
------
* This release of Borland JBuilder is based on Version 1.1.6_Borland
of Sun's Java Development Kit. This version of the Java Development Kit
contains JDK 1.1.6 functionality and AWT features, plus some
Inprise-found bug fixes needed for JBuilder to run correctly at development
time.  The target applications should be able to run on JDK 1.1.6 or later in
all cases.  Also, if you restrict yourself to the features of earlier versions,
our classes should run without problems on earlier versions of the JDK,
such as 1.02.

* Do not replace the JDK installed with JBuilder with any other release.  You
can compile and run against any JDK release using the JDK switching feature
introduced in JBuilder 2.0.

D. Upgrading JBuilder 1.0 applications to JBuilder 2.0
------------------------------------------------------
Package changes
---------------
1. COM.objectspace.JGL is now com.objectspace.JGL in the new JGL version 3.1
   library.
2. Code casting existing JBCL 1.0 components may need to be re-cast when using
   JBCL 2.0 components due to the class hierarchy switch extending JComponent
   instead of Panel.
3. JDBC-specific classes in borland.JBCL.dataset have been moved to a new
   package, borland.sql.dataset. Separating general dataset functionality
   from a specific provider/resolver implementation will simplify future
   support of multi-tier designs and other provider/resolver
   implementations. The classes moved include Database, QueryDataSet,
   ConnectionDescriptor, QueryDescriptor, and QueryResolver. JBuilder
   projects that use these classes will have to be edited and recompiled.

These are the changes you must make:
- When components in the classes listed are named with explicit package
  references, you will see an error like "Cannot access class
  borland.JBCL.dataset.ConnectionDescriptor...". To resolve this
  error, change the package name.
- When the package name is implicit, the error will be something like
  "Class Database not found...". To resolve this, add an import
  statement for borland.sql.dataset.*;.

Project changes
---------------
1. COM.objectspace.JGL is now com.objectspace.JGL in the new JGL version 3.1
   library.
2. Code that casts existing JBCL 1.0 components may need to be re-cast when
   using JBCL 2.0 components because of the class hierarchy switch that extends
   JComponent instead of Panel.
3. JDBC-specific classes in borland.JBCL.dataset have been moved to a new
   package, borland.sql.dataset.  (Separating general dataset functionality
   from a specific provider/resolver implementation will simplify future
   support of multi-tier designs and other provider/resolver
   implementations.) The classes moved include Database, QueryDataSet,
   ConnectionDescriptor, QueryDescriptor, and QueryResolver.

JBuilder projects that use these classes will have to be edited and recompiled.
These are the changes you must make:

- When components in the classes listed are named with explicit package
  references, you will see an error like "Cannot access class
  borland.JBCL.dataset.ConnectionDescriptor...". To resolve this
  error, change the package name.
- When the package name is implicit, the error will be something like
  "Class Database not found...". To resolve this, add an import
  statement:
    import borland.sql.dataset.*;.

Project changes
---------------
* JBuilder 2.0 will read in projects created by JBuilder 1.0x and convert them
to the JBuilder 2.0 JPR format. When you open an old project file, JBuilder 2.0
will make a backup copy of it to a file with the form: oldname-v1.0.~jp

* References to libraries found in the old project that have new counterparts
will be automatically mapped to the newer version (JBCL to JBCL2, JGL1 to JGL
3.1, and so on).  If there is a library found that does not have a newer
counterpart in JBuilder (for example, some 3rd party library), JBuilder 2 will
preserve the reference if the library still exists and will build dependency
files for it.

* Many changes have happened between JBCL1 and JBCL2 (JBCL2 is based on the
Swing (JFC) Architecture and uses a new version of JGL that is not backwards
compatible with the earlier versions). If you do not want to upgrade your
projects to use JBCL2, it is recommended that you use JBuilder 1.0x to maintain
your older JBCL1 projects.

Two topics in the Help System which will help you understand the project changes
in JBuilder 2.0: The "Setting project properties" topic in the "Creating
and managing projects" chapter of Getting Started with JBuilder and the
"Problems compiling imported projects" topic in the "Compiling Java programs"
chapter of Building Applications with JBuilder.

JBInit method
-------------
* The jbInit method is now declared to be "private" rather than "public".  Code
that extends a class containing a jbInit method encounters a compile error if
components are added to the child class.  To fix this problem, edit the
superclass to make its jbInit method private.

JBCL changes
------------
* ListControl and TreeControl are a subclass of the java.awt.Container.  The
methods remove(int) and removeAll() are in java.awt.Container. These methods
tell the component to remove the specified subcomponent, or all of them. In
JBuilder 1.0 these methods were overridden to remove the data items. JBuilder
2.0 does not override these methods.

* GridView, ListView and TreeView no longer have any inherited implementation
for the following methods:

   int getScrollbarDisplayPolicy()
   int getHScrollbarHeight()
   int getVScrollbarWidth()
   java.awt.Adjustable getVAdjustable()
   java.awt.Adjustable getHAdjustable()

See methods available in JScrollPane for workarounds

E. Using Swing and JBCL Components
----------------------------------
Heavyweight vs. Lightweight
* The Swing (JFC) Architecture introduces the concept of heavyweight and
lightweight components.  A heavyweight component uses a native peer to paint,
but a lightweight component handles painting itself and has no external
dependency.  JavaSoft has also changed how events, such as mouse events, are
handled with lightweight components, and there are some differences in
Z-ordering as well.

* A good reference on this topic is: "Mixing heavy and light components" by Amy
Fowler on the JavaSoft web page.  See:

   http://www.javasoft.com/products/jfc/swingdoc-current/mixing.html.

* As a general rule of thumb, it is a good idea to avoid mixing heavyweight and
lightweight components in the UI.

* Because JBCL2 uses the architecture from JFC in many places, you may encounter
some of the heavyweight vs. lightweight issues. Whereever possible, lightweight
components are used but there are some cases where there was no appropriate JFC
component to use or there was missing functionality or support in the current
JFC.  In those cases the components are still heavyweight. The following is a
list of JBCL2 controls split between heavyweight and lightweight.

Heavyweight:
     CheckboxControl, CheckboxPanel, ChoiceControl, LabelControl,
     LocatorControl, TextAreaControl, TextFieldControl, PopupPickListItemEditor

Lightweight:
     ButtonControl, FieldControl, TextControl, ListControl, GridControl,
     ImageControl, TransparentImageControl, ButtonBar, ShapeControl, StatusBar,
     TreeControl, BevelPanel, GroupBox, SplitPanel, TabsetView, TabsetPanel

* Due to limitations in International support in the JFC, the stock editors
bound to these controls are still heavyweight.  If you experience heavyweight
vs. lightweight problems using these editors in your Applications or Applets,
you can use the MV nature of JBCL to plug in a different lightweight editor of
your own design.

* If you call setters, (such as setBackground() or setText()), in a Swing or
Swing based component and don't see the change at runtime, you may have to add a
repaint() call. In many cases, Swing does not call repaint() automaticly when a
property is set.  This usually occurs with user-entered code, and should not
show up in the UI Designer.  In your code, add a call to repaint() after adding
a setter. If you are setting multiple properties, set them all and do one
repaint() instead of a repaint() for each.

* If you are using Swing (JFC) in an applet, your applet must extend from
JApplet. This also requires that the old add() calls be replaced with
getContentPane().add(), and so on.  You must also implement a static
initializer to set the Look and Feel for the Applet.  Without this, you see
many odd side effects such as buttons that don't depress.  For an example of
a base JApplet, select File | New... | Applet.  Be sure to select the JDK
classes option.  Using this base file in the Designer will also allow you to
see the new code style for JFC containers like JApplet.

* Certain Swing components, such as JButton, expose two properties to represent
their textual label: 'text' and 'label'.  JBuilder automatically uses the
'text' property when such a component is added to the UI Designer. However,
using the 'label' property, which is also available in the Inspector results
in code that generates a compiler warning, since the setLabel() method has been
deprecated.  Avoid using the 'label' property in these particular components.

F. Using a newer version of Swing (JFC)
---------------------------------------
* To replace Swing 1.0.1, included with JBuilder 2, with a newer version of
Swing do the following:

  1. Exit JBuilder if it is running.
  2. Rename \jbuilder2\lib\swingall.jar to swingold.jar.
  3. Copy the new swingall.jar into the \jbuilder2\lib directory.
  4. Copy src.zip from Swing 1.0.x to \jbuilder2\src\swing-1.0.x-src.zip.
  5. In JBuilder, go to the Tools | Default Project Properties dialog.
  6. In the dialog, click on the "Libraries..." button, and define a new library
     named "Swing 1.0.x" with a classpath that points to the new swingall.jar
     in the \jbuilder2\lib\ directory.

Notes:

JBuilder depends on Swing, so be aware that making this change can have
side-effects in JBuilder.

* The swingall.jar that you have renamed to swingold.jar is larger than the
swingall.jar included with the new Swing because we have created .dependency
files for each of the included packages.  The unmodified swingall.jar can be
found in the \redist directory.  When you finish defining the library, these
.dependency files will be generated into the \jbuilder2\dependency directory.

* If you are using other than the 'Default Windows' color scheme on your
computer, the IDE may look odd.  This problem is purely cosmetic.

* Swing 1.0.2 introduced a problem that disables using a JBCL FieldControl or
ImageControl with the Metal look and feel.  Do not use these components in
combination with the Metal look and feel.

* Make sure existing projects that refer to the Swing 1.0.1 library now
point to the new Swing library that you created.  If you try to compile a
project that was using Swing 1.0.1, the compiler will not be able to find the
correct .dependency files and will rebuild them in your outpath.  This will
result in warnings from the compiler.  Be sure to delete any
com\sun\java\swing\*.dependency files in your outpath.

G. Deploying Applets and Applications
-------------------------------------
* JBuilder 2.0 adds the ability to specify a particular JDK to use with a
project.  Choosing a particular JDK switchs the version of AppletViewer used by
that project to the one that comes with the selected JDK.  JDK 1.02 applets
won't run correctly from within the IDE due to a problem with the version of
AppletViewer that comes with JDK 1.02.  JBuilder (and subsequent versions of
AppletViewer) uses the CLASSPATH to allow for Applet launching to be more
flexible.  You can still use JDK switching to compile and ensure that you are
not using any 1.1 specific methods in your 1.02 code.

* When deploying your application or applet, images used by JBCL are not added
to the archive.  Keep those resources in a package of their own.  The Deployment
Wizard only deploys "solid" instances of classes found in the code and misses
resources like images and other items that are loaded
dynamically.  Keep those resources in a package of their own.  For example, the
images used by JBCL are in the package  borland.jbcl.control.image. Add that
package to your project via File | Open/Create and it will appear in the list
of files in the Deployment Wizard. Selecting a package in the list of files to
deploy will place all files in that package into the archive.

* If images used by your classes don't get added to the archive, place them in
their own package as described previous tip or add them directly to the project.
If you add them to your project, add a project folder to store the images and
minimize clutter in the Navigation Pane.

* If your images don't show up at runtime, it may be because the images are not
in the proper location relative to the class file that uses them. This often
happens when you are storing the images with the source code.  Instead, place
the images in your project.  When you build the project, JBuilder will copy them
to the appropriate location in your OutPath.

* Many Look and Feel classes are loaded dynamically and the Deployment Wizard
cannot find them as it builds the archive.  If at runtime, you find there
are missing Look and Feel classes, possible solutions include:

   1. If the problem is only limited to look and feel classes, add the
      appropriate look and feel package to your project and the Deployment
      Wizard will add all classes from that package to your archive.
      Note:  If the Deployment Wizard gives an error indicating that it cannot
      find the .class file specified, it is because some of the source files
      in the L&F package do not have corresponding class files.  Find the source
      file in the package that you inserted and compile it.  If you come across
      a L&F class that cannot be compiled, it is likely to be one of the L&F
      classes that extend a non-existent class elsewhere in the plaf package.
      You have to exit JBuilder and remove the erroneous source file from the
      plaf package in the swingall.jar file to get around this.

   2. Locate the missing classes in swingall.jar and add them to your archive
      using WinZip or some other archive management tool.

   3. Deploy swingall.jar with your applet or application.

   4. (Applets only) Use the Java Plug-in from Javasoft.  This browser
      plug-in includes swingall.jar and provides JDK 1.1 functionality
      regardless of which browser you are using.  It also provides a higher
      level of JDK support then is currently available in the stock browsers.

* If your dsjclient gets the Fatal error "Unable to establish long term
connection with server" after selecting an application, check that Available
Servers is set to the hostname (or IP address) of the server machine.

H. Known Problems
-----------------
H1. Visual Design Tools and JavaBeans
-------------------------------------
* If you see one of your components as a red box with its class name at
the top, JBuilder has not been able to create an instance of that component for
the designer.  This is called a "Red Bean".  Some reasons you might see a Red
Bean are:

   1) That class has no default (parameterless) constructor
   2) That class threw exceptions on every constructor JBuilder tried
   3) That class is the 'this' object and it extends an abstract class

Items (1) and (2) can be fixed only by supplying a proper default constructor
or subclassing that class in order to provide a default constructor. Item (3)
is more complex. Whenever JBuilder needs to instantiate an object to be the
"this" object, it encounters a paradox.  It cannot instantiate the object
you are designing.  To circumvent this problem, JBuilder always attempts to
instantiate the superclass of the "this" object.  If the superclass is
abstract, it cannot be instantiated.  Here is the solution

In the file lib\jbuilder.properties, you will find a line that looks like:

jbuilder.concreteProxy.com.sun.java.swing.JComponent=borland.jbcl.control.JComponentProxy

This line says that whenever you are forced to instantiate
com.sun.java.swing.JComponent (which is abstract), you will find an acceptable
concrete proxy class for it in borland.jbcl.control.JComponentProxy.

You may add your own proxy objects using this pattern.  The proxy class does not
need to do anything other than the following:
   1) Extend the abstract class in question
   2) Be concrete (not be declared abstract itself).

Examine the source for borland.jbcl.control.JComponentProxy to see a working
example.

* If you delete a subcomponent in a DataModule, the extra "getter" method which
was generated to expose this subcomponent will not be deleted.  You will have
to delete this method manually.  (12876)

* Selecting "Activate Designer" from the "Menu" folder in the Structure pane
doesn't always display your menu. The workaround is to activate the designer
from a menu node. (13352)

* Sometimes "undo" in the designer will undo more than the last operation. If
this happens, use re-do to restore the extra undone operations.  (13349)

* If you are using a JTabbedPane in designing one component, then go to design a
second component and return to the first, the tabs of the TabbedPane will
display multiple times. The workaround is to dirty the source code and go back
into the UI Designer, forcing a re-paint.

* JdbNavToolBar may be shown in the wrong position in design mode.  However, it
will be in the correct position when the application is run.  (11464)

* JdbToggleButton, JdbCheckBox, and JdbRadioButton don't display "true" values
when on the first row after initially opening the dataSet. Navigating in the
dataSet fixes this.  (13072)

H2. The jbInit Method
---------------------
* The contents of the jbInit method are arranged as follows:

* Initial subcomponent property settings are in order by subcomponent and
then by property. (Properties are ordered as defined by the BeanInfo class,
or as the getter methods are found through reflection). Event listener
addXxxListener calls are also placed with the subcomponent, ordered as if
they were property settings.

* Additional method calls for wiring subcomponent relationships are created
by the designers. These include container.add(component, constraints)
calls as well as menu and data module assembly. Generally, these are ordered by
subcomponent, and then by child Z-order.

If you rearrange any of these methods by hand, the changes will probably be
undone the next time a designer manipulates something nearby.

Additional hand-coded method calls or other statements can be placed
anywhere within the jbInit method, but it is recommended that they be
placed at the end.

* The Designer only works on classes that are declared public.  It looks for
variables of class scope and method calls found in the jbInit().  If the
jbInit() method signature is altered, the Designer will not recognize it.

H3. Wizards
----------
* Be sure that you have built all your .class files before running
the Deployment Wizard. If you see the "Can't find .class files"
message from the Wizard, you have probably forgotten to compile
your project first.

* Be sure to add any .properties, .txt, and .schema files you
wish to deploy to your project so that they can be seen by the Deployment
Wizard. Note that you may first need to use Tools|Treat As Text in order to
add those files to your project.

H4. KL Group Components
----------------------
* The customizer for KL Groups chart does not fire PropertyChangeEvents.  This
means that when the customizer is used in the designer there is nothing that
JBuilder can listen for to allow the changes made in the Customizer to persist.
You cannot use their customizer to persist changes in code.  (11956)

H5. Debugger
------------
* Setting breakpoints in inner classes may give the warning "Some breakpoints
found on lines which do not contain debug information."  The work around is to
set the breakpoint before the inner class.  (10811)

* If you have two classes with the same names but in different packages, a
breakpoint may not stop in the class you desired. The workaround is to reference
the classes by their fully qualified names.  (12581)

* The debugger may treat some handled exceptions as if they were unhandled and
log these in the execution log.  A workaround is to tell the debugger to stop
whenever it encounters an unhandled exception.  (13325)

* If your line numbers and breakpoints are out of sync, check the file in
Notepad for extraneous characters.  The most common cause is an external editor
that does not use CRLF as the end-of-line (EOL) character.  These characters
often get embedded in the source file when edited outside of JBuilder or via
copy and paste.  A simple editor like Notepad will show these "wrong" characters
as empty boxes.  Removing them or replacing them with a regular EOL character
often solves the problem.

H6. CodeInsight
---------------
* For performance reasons, if you have a slower machine (< 133mhz machine),
you may want to turn off all of the CodeInsight checkboxes on the CodeInsight
tab of the IDE options dialog. You can still use CodeInsight, but it will be
on-demand (by pressing the hotkeys Ctrl+Space, Ctrl+Shift+Space, or
Ctrl+Alt+Space).

The performance when pressing these keys will be less than for someone using
"Background Research", but you won't have slower performance in other places.

Using "Auto-Code Completion" and "Auto-Parameter List" without "Background
research" is not recommended, so these off.

"Syntax Highlight declaration errors" won't work without "Background Research".

H7. IDE
-------
* Paths that contain spaces and # symbols cannot be used in Java programs.
(12993)

* "Browse symbol at cursor" brings up empty navigator, structure, and content
panes if the object being browsed has a fully qualified package path. The
workaround is to convert the explicit package path to an import statement in
the file. Then remove the explicit package name before the class name.  (13341)

* Top of File | Open / Create dialog is truncated under Win 98.  "Look in"
drop-down and other controls at top of dialog are only half-visible.  (14896)

* Unable to set the runnable node on anything in a package.  Workaround is to
add a copy of the runnable node to the top level of the project. (14903)

* In projects with package nodes that also contain top level nodes that are
files in the the package, save all will sometimes shift focus to a different
node.  (15043)

H8. JBCL
--------
* JBCL ChoiceControl leaves the current item displayed in the control if a
subsequent query is executed and choiceControl1.setItems() is called. The
workaround is to set the control's dataSet to null prior to population.  (13177)

-------------------------------
SECTION 3. International Issues
-------------------------------
A. Install
----------
Due to JDK limitations, installation into a directory path containing non-ASCII
characters is not supported.  (3235)

B. Compiler
-----------
1. Native encoded source files
* By default the compiler uses the encoding appropriate for your
environment. The JDK convention is to assume 8859_1 for most Windows
environments (Cp1252).  If you use Cp1252 characters within the
range of x7F through x9F, then you should explicitly set the
encoding to be Cp1252.  (5882)

To select the encoding used by the compiler, click on the IDE
Options item in the Tools menu, then select the encoding from
the list provided. For the command line compiler, use the -encoding option.

2. Local characters in Identifier names
* You can use local characters, including multi-byte characters,
in identifier names. However, due to a JDK limitation,
you can only use ASCII characters in class and package
names. Therefore it is suggested that only ASCII
characters be used as component names. This is because any
event handler classes will use the component name.  (6362)

3. Long lines truncated from text resource files
* At compile time, text resources in projects (such as *.properties files)
are copied to the output path for use when running the compiled project.
Lines longer than 1024 characters will be truncated.  Files that use
many unicode escape sequences, \uNNNN, are particularly susceptible since
each character displayed in a GUI requires 6 characters when expressed
in the \uNNNN format of the text file.

As a work around, use the continuation character ('\') to break long lines
in property files.  Files in the Multilingual sample demonstrate this (such as
<JBuilder_dir>\samples\borland\samples\intl\gui\resources\TextRes_ja.properties).
(14252)

C. Visual Design Tools
----------------------
* When naming components with international characters, see the note regarding
event handlers under the section above, "B.2. Local characters in Identifier
names:".

* When using the IME to enter Chinese characters into the Inspector,
you should use the keyboard. Using the mouse can fail to properly
enter the character.  (5465)

* There is a JDK limitation when creating localized applications whose
menu commands have shortcuts such as Ctrl+S. For example, under a German locale,
the shortcut should appear in the menu as Strg+S, but will always be listed
as Ctrl+S.  (6955)

* The KL Group components are backward-compatible with JDK 1.02.
Therefore there are international limitations with these components.

D. Keyboard Issues
------------------
* Under Windows95, using dead keys with AWT or JBCL controls
may not work and should not be depended upon.  (JDK)(13398)

* Due to a JDK limitation, Swing components do not support character
entry using AltGr.  (JDK)(11375)

* Also, Alt+numpad cannot be used to enter accented characters into
editable components.  (JDK)(11867)
/------------------------------- END OF FILE ----------------------------------/

