Object instances reuse and Eclipse API

Reading one of my colleague’s code I saw this:

GridLayout gl = new GridLayout();
gl .numColumns = 1;
gl .verticalSpacing = 0;
gl .marginHeight = 0;
gl .marginWidth = 0;

Composite c1 = new Composite(parent);
Composite c2 = new Composite(parent);

Personally I always create a new layout for each one of my GUI component. It is in my opinion more easy to read that the piece of code above and because there is a small number of such objects (having a UI with thousands of GUI component needing a layout is bad idea I think ;-)), creating a new one for each component doesn’t impact performances.

To go further in the probleme, reading this code lead me to the following question:

How do I know if a given class instance can be “shared” in several contexts ?

In the particular case of the GridLayout above, I was not able to find the answer in the Javadoc here. After looking at the source code of GridLayout it seems that there is no internal state saved anywhere, and thus it’s possible to use the same layout instance for several components.

May be I missed something or maybe it should be interesting to indicate this information in the Javadoc. For sure, I’ll take care of that when writing the documentation for my own libraries.


SWT FileDialog and Windows Hide Extensions For Known File Types

This morning we encountered a strange difference while running the following code on two Windows workstations and directly clicking the OK button of the dialog.

 FileDialog dialog = new FileDialog(window.getShell(), SWT.SAVE);
 dialog.setText("Save as...");
 dialog.setFilterExtensions(new String[]{"*.sav"});
 String path = dialog.open();

The first workstation printed C:\Test\toSave.test while the second one printed C:\Test\toSave.test.sav

Of course the wanted behaviour is the second one !!!

After investigations we identified the difference on the workstations causing this “SWT” difference: the first workstation HAS the windows folder option called Hide Extensions For Known File Types checked while the second one HASN’T !!!

To fix the issue we had to modify the setFileName method call as following:


Conclusion: Looking back to the initial code, it seems logic to have to set a file name matching the specified filter extensions.


JFace’s Viewers Performances

Last weeks I played for the first time with JFace’s viewers (TableViewer and TreeViewer). It was really easy to integrate my first viewers inside my own Eclipse views.

All was working fine when I started to encounter performances problems when setting inputs containing thousands of entries (several seconds for ~50.000 rows in a TableViewer).

A quick look on Google pointed me to LAZY content providers and SWT.VIRTUAL in order to improve performances. Before going further with these content providers we have to identify bottle necks. When working with JFace’s viewers there is potentially 2 bottle necks:

  1. The retrieval of all the model objects from the viewer’s input (it’s the content provider’s job).
  2. The creation of UI elements.

As Tom Schindl said here (Snippet 29): “The bottle neck is often the UI and not the model“.

I checked the time consumed in my content provider to retrieve viewer’s entries. Only few milliseconds. My bottle neck is the UI !!

To solve this performances problem I just added the SWT.VIRTUAL style when creating my TableViewer. Creating the viewer this way tells JFace to create the SWT's TableItem objects on an on demand basis. TableItem objects are created only when they become visible (when the user scroll for example). As a conclusion, all I had to do to solve my performances problem is to set this magic style: SWT.VIRTUAL. It’s so easy to work with Eclipse !!!!! Isn’t it ??

Next i tried the same solution with TreeViewer. Unfortunately it didn’t worked. I had to use the SWT.VIRTUAL style WITH an ILazyTreeContentProvider in order to increase my performances as in TableViewer. It’s fine but this solution has one drawback: Sorting and Filtering are no longer available when using ILazyTreeContentProvider.

Someone told me on the Eclipse Platform newsgroup that the request to support SWT.VIRTUAL style and sorting and filtering for TreeViewer is already in the “pipe” but i can’t find such a request on Eclipse bugzilla. If someone can tell me more on that …

SWT mouseDoubleClicked / mouseUp / mouseDown

You are interested in both double clicks and single clicks in your SWT application ??

You have a problem since when the user double clicks the code for single clicks is also called !!!

Here is a useful discussion on SWT news group proposing a solution. (You must login in eclipse forums to access this link).

This solution works, nevertheless i would be interested in any other way to do this … if you have a solution please let me know.

SWT Key Events on Display – Focus Management

You are interested in any key events of an SWT application??

Unfortunately this can’t be done.

You have to add your KeyListener on a given widget. Your listener will receive events when the user types on the keyboard IF AND ONLY IF the listened widget has focus.

If this widget is the only one intersted in key events in your application then it will work perfectly !!!

If you have an other widget intersted in key events, the widget with focus will receive key events but NOT THE 2 widgets.
Focus is set when the user clicks on a widget having at least one KeyListener associated to it. As a consequence the notified listener depends on the user actions … You can also set the focus programmatically using setFocus() method.

For any further informations look here!

SWT / GTK 16 bits limitation

Have you ever try to draw a very large shape on an SWT Canvas using GC drawing methods on a linux workstation ?

Try to draw a line from (245, 258) to (40000, 150) and it will sometimes result in bad rendering (see here for more details). You are thinking, why draw such a line since my screen resolution can’t exceed 1600 pixels …. ???

You are right so, to easily workaround this limitation we just have to compute the intersection between the line and the underlying Canvas‘s client area.

Fine but ….. in some cases, when drawing very large scrollable diagrams for example, it can be very difficult to compute the visible part of a given shape. Have you for example, already computed the intersection between an SWT polygon == an int[] and an SWT Rectangle ??
It’s not so trivial, and the easyest way i found to do this is to use Java2Dclasses !!! and I don’t want to depend on Java2D. (I opened a new feature request to SWT here).

All this long story to ask these questions :

Have you ever encountered this limitation, how did you solved it ?