Archives for category: Tips n’ Tricks

I had some little sample I wanted to write where I had a TextField that restricted input. Maybe somebody else out there has already figured out how to do this elegantly, but I hadn’t and thought it would be worth a small post to demonstrate the technique.

Within the TextInputControl is a Content, which actually models the TextInputControl’s content. So for example, this is where we strip out newlines and such if you paste a String into a TextField that contains such characters, but in TextArea we allow those sorts of modifications. There is a protected getContent() method, so in theory a subclass of TextInputControl can manipulate the content directly, although in the case of TextField, it does not.

In fact, the only places in all the code that actually modify the TextField’s text is in the replaceText and replaceSelection methods defined on TextInputControl. So all you have to do is subclass TextField and override these two methods.

field = new TextField() {
    @Override public void replaceText(int start, int end, String text) {
        // If the replaced text would end up being invalid, then simply
        // ignore this call!
        if (!text.matches("[a-z]")) {
            super.replaceText(start, end, text);
        }
    }

    @Override public void replaceSelection(String text) {
        if (!text.matches("[a-z]")) {
            super.replaceSelection(text);
        }
    }
};

In the future we may want to add a more specific method (maybe called “accept” which takes the proposed new string after the modification) so that in the off chance that TextField or TextInputControl ends up modifying the content from some additional methods beyond these two, you could still have a reliable way to reject invalid input. However for the time being, this should work just fine!

Phil Race has posted a blog post over at the JavaFX Blog on the addition of LCD text support in the latest JavaFX 2.1 developer preview.

LCD sub-pixel text has become a must-have for many Windows desktop users, who have become accustomed to its superior legibility and less blocky appearance at smaller point sizes over hinted black and white text, and being sharper than grey scale anti-aliased text at the same size.

Java SE has supported LCD subpixel text on AWT heavyweights and also on Swing components using Java 2D for many years. However up until now, JavaFX has supported only more Mac OS X-like grey scale smoothed text.

For the JavaFX 2.1 release we’ve added the ability to use Windows-style LCD sub-pixel rendering. All the JavaFX UI controls will be LCD-text enabled by default on Windows, as will “WebView”, the Webkit-based node for rendering Web content.

Applications can also opt-in to use LCD text on the low-level scenegraph “Text” node by a new API : Text.setFontSmoothingType(FontSmoothingType.LCD));

I was experimenting today with extending AreaChart to do curve fitting for some example code I was hacking on. It is also a example of what can be done with styling JavaFX charts with CSS. Here is the result:

(more…)

I came across the interesting blog “JavaFx and HTML5 differences” by Chika Okereke. Looking at the example code and comparing to the HTML Canvas version I thought the Java code could be made less verbose and easier to read.

Original Code

Path path_4 = new Path();
ObservableList shape_4 = path_4.getElements();
shape_4.add(new MoveTo(50,50));
shape_4.add(new LineTo(150,50));
shape_4.add(new LineTo(150,150));
shape_4.add(new LineTo(50,150));
shape_4.add(new LineTo(50,50));
path_4.setStrokeWidth(2);
path_4.setStroke(Color.rgb(255,0,0));

So I hacked together a Extended version of the PathBuilder that ships with JavaFX 2.0 adding methods for all of the path elements like moveTo() etc. The end result seems much cleaner code to me, what do you think?

Code with new Builder

Path path4 = PathBuilderExtended.create()
        .moveTo(50, 50)
        .lineTo(150, 50)
        .lineTo(150, 150)
        .lineTo(50, 150)
        .closePath()
        .strokeWidth(2)
        .stroke(Color.RED)
        .build();

This seemed a lot cleaner and simpler to read. I have filed a feature request RT-19266 in JIRA to add this to the platform. Feel free to comment on the bug if you any feedback or better suggestions. Also I have attached a implementation of this builder to the bug so you can see how it would be implemented or use it with your code today.

With JavaFX 2.0.2, we’ve included support for interop with SWT in the same way that we support interop with Swing. That is, you can embed JavaFX within your SWT applications! Although e(fx)clipse has been doing this for a little while by embedding FX -> Swing -> SWT, you can now skip the intermediate embedding into Swing and just go straight to SWT. Because FX and SWT share the same basic threading model, this is really easy to do.


(more…)

A number of people have asked me recently can I create this look or that look using CSS in JavaFX. Or they have said that you could never do that! So I thought I would do a little experiment and try recreating a bunch of common button styles purely using CSS. So without further ado, here is the result:


(more…)

One thing I see asked a lot (either directly via email, or in the rather excellent JavaFX Forums) is why does TableView (and ListView) look like this in JavaFX 2.0:

A TableView control using default styling and API as provided in JavaFX 2.0.

(more…)

I was just writing a quick little application and I wanted to do something special whenever the user released the enter key inside a TextArea. You might be tempted to do it like this:

final TextArea editor = new TextArea();
editor.setOnKeyReleased(new EventHandler<KeyEvent>() {
    public void handle(KeyEvent t) {
        if (t.getCode() == KeyCode.ENTER) {
            System.out.println(editor.getText());
        }
    }
});

Can anybody spot the problem in this code? It correctly gets the key event, and it only prints out the text if the code of the key event is ENTER. The problem is that it also executes this code if you typed ALT+ENTER, or CTRL+ENTER, or any other combination of modifiers with the key code! JavaFX 2.0 contains a handy little class called KeyCombination which will handle all the annoying checking of key modifiers + key code to see if a specific key event matches. Here is the more correct version:

final TextArea editor = new TextArea();
editor.setOnKeyReleased(new EventHandler<KeyEvent>() {
    final KeyCombination combo = new KeyCodeCombination(KeyCode.ENTER);
    public void handle(KeyEvent t) {
        if (combo.match(t)) {
            System.out.println(editor.getText());
        }
    }
});

One extra line of code, and you get correct matching of the key events. Sweet!

JavaFX 2.0 shipped with a declarative XML-based language for defining user interfaces, called FXML. FXML is a key part of our strategy around making it easier to create user interfaces in Java. Certainly having a markup language has been attractive to web developers since it is a familiar and comfortable way to approach describing a user interface. But there are other key strategic reasons why FXML is important, how it fits into the broader JavaFX ecosystem, and how it helps you write testable user interfaces with minimal fuss. In essence, FXML helps you follow best practices while also making your life easier.

(more…)

We’ve introduced a SplitPane control in JavaFX 2.0, and today I thought I’d point out an interesting subtlety in the API. For the longest time our SplitPane API primarily consisted of the normal ‘left’ and ‘right’ (or ‘top’ and ‘bottom’) properties (indeed, the JavaDoc as of today still refers to this API). These were synonomous – if you set ‘top’ and ‘bottom’, they were literally copied to the ‘left’ and ‘right’ code, and our SplitPaneSkin just knew to draw with the items stacked vertically, rather than to lay them out horizontally.

(more…)