4.2.15 (Dec 2007)

NetService Enhancements

Package com.nexaweb.client.netservice now allows developers to listen for events affecting the push connection, and to consume those events. This added functionality allows, among other things, the developer to detect when a server has become non-responsive. For example, in an application with a push connection and these new services, the developer can now show a dialog alerting the user the server has become non-responsive.

This is accomplished by the following additions to the NetService interface.

addPushConnectionListener - Adds a push connection listener

removePushConnectionListener - Removes a push connection listener

And through a new interface in the NetService package:

PushConnectionListener

Please see 4.2.15 Platform API for more details.

Tooltip Enhancement

It is now possible to set a display delay on tooltips. The default delay is 0 milliseconds.

This setting can be adjusted by modifying the following line in nexaweb-client.xml.

<tooltip-delay>0</tooltip-delay>  

Context Popup Changes

Overview
One of the goals of this MR is to bring consistency to the use of popups. This section outlines the order of events that occur after a particular action. The following bugs identify several areas of inconsistencies with the use of the popups and popupMenus as context popups that were addressed in this maintenance release. (See the end of this 4.2.15 MR note for a full list of fixed defects.)

This section outlines new functionality, important notes on the use of popups and popupMenus, and the order that events fire after a particular action takes place.

Right Click on component to invoke context popup.

Proposed new order of events for both popup and popupMenu.

1. onBeforeActiveLost on invoker ( the component on which right mouse button was clicked)

2. onActiveLost on Invoker

3. onActiveGained on context popup (either popup or popupMenu)

Notes:

• The onBeforeActiveLost() allows for potential validation on the invoking component before bringing up the popup or popupMenu.

• The activeGained on the context popup, allows focus to be sent to any component when using a popup.

• Since focus is being taken away from the invoker, this means that the selection in a textField will also be taken away. Bug 8794, states that they wanted selection to stay. This can be done by setting the attribute of the textField to "always".

Selecting menuItem of a popupMenu
Proposed new order of events

1. onBeforeActiveLost on popup

2. onActiveLost on popup

3. onActiveGained on invoker

Clicking outside the bounds of the context popup

Proposed new order of events

1. onBeforeActiveLost on popup

2. onActiveLost on popup

3. onActiveGained on selected component if focusable

This means that if you click into a textField while a context popup is visible, the popup will go away and the textField will gain focus and be selected. This is a change from how it worked before Platform 4.2.15. Previously, in order to select the textField, you had to click twice. Once to dismiss the context popup, and a second time to select the textField.

Pressing Escape Key when context popup is being displayed.

PopupMenu
For a popupMenu, the order of events will be as follows

1. onBeforeActiveLost on popup

2. onActiveLost on popup

3. onActiveGained on invoker

Popup
Previously, nothing happened when pressing escape when the context popup is defined as popup. Version 4.2.15 has the following behavior.

1. The component that has focus gets first chance to handle escape key

2. If not handled by focused component, the popup will close with the following events.

   • onBeforeActiveLost on popup

   • onActiveLost on popup

   • onActiveGained on invoker

Pressing Tab Key when context popup is being displayed

PopupMenu
For a context popup defined as a poupMenu, pressing the tab key has no effect, which is the desired behavior.

Popup
For popup in builds before 4.2.15, focus could be transferred away from the popup when pressing the tab key. This is the emphasis of bug 8871. This has been changed in 4.2.15 to keep the tabbing within the popup when it is being used as a context popup.

Menus within Menu Bar

Issue

In versions before 4.2.15, selecting a menuItem sent focus to the next focusable component, as defined with the Focus Manager. This is often a bit confusing. Focus will now be passed to the first focusable ancestor of the invoker.

Note:

Since menubars are not focusable by default, this could end up passing focus to the client panel. The workaround for this would be to set the menubar to be focusable or put the menubar in a panel that is focusable. By default the menubar is not focusable. This is something that was changed for accessibility, but only do if the application is "accessible."

Context popups on subcomponents

Issue
In previous builds to 4.2.15 there was an issue with focus when using context popups on a subcomponent such as headers or columns of a table. In 4.2.15 focus is sent to next focusable component.

Fix
The same logic proposed for menubar works here as well, passing focus to the first focusable ancestor of the invoker. So in the case of the context menu on the header or column, this would pass focus back to the table.

More Java Improvements

Selection behavior using right click of mouse

The following outlines the improved right-click selection behavior.
 

• Any right mouse click within a selection of cells, rows, or columns, should not result in the selection being changed, but should show the context menu. This is regarless of whether the control or shift keys are down.

• A right mouse click outside the current selections should select the single cell, row or column and bring up the context menu.

• Ctrl-Right mouse Click or Shift-Right mouse click, should add rows, columns, or cells, to the selection if the occurs outside the current selections.

Window improvement when using attribute centered="true"
When using centered="true", now, window will not re-center itself everytime window is redrawn.

A note on dynamic dialog or window resizing

When a pane is dynamically made visible in a dialog or window, the dialog or window (container) will automatically resize to show the contents of the visible pane. Please keep in mind that any manual user resizing of the container before the invisible pane is made visible (before the pane automatically resizes) will cause the container to not automcatically resize. This behavior is correct because the user’s sizing takes precedence over automatic container resizing when a pane is dynamically made visible. So, if the developer's application relies on dynamic resizing provoked by making a pane visible, the developer should use resizable=”false” so the user can not change the size of the container, thus allowing the container to always automtically resize according to the developer's intentions.

Events can now be stored in Style Sheets
It is now possible to add events to elements in style sheets.

For example,
stylesheet.xss:

Defects Resolved