The problem in Java FX when we hide controls is that once we set it to setVisible(false), the control will be hidden yes. But its bounded space will still be in effect and it would look pretty ugly seeing a huge empty area in your user interface.

While some have suggested placing it in an HBox or VBox and removing and adding them when needed, the better solution for me is to call this control.managedProperty().bind(control.visibleProperty()); before any calls to setVisible() whether you want to hide it or not.

Once that is called, when you hide a control, its bounded space will be removed from the user interface as well making it look like it is not there at all.

The answer to this problem is that the object that you pass into the TableCell must have a boolean property inside of it that you need to bind to the table column.

If not, then the item and empty parameters in the updateItem() method of the TableCell class will always return null and true so there is no way to be able to determine when the CheckBox control should appear for rows that are present.

If you call setGraphic(checkbox) without adding any conditions, then every row visible in the TableView will have its own checkbox regardless if it has only a few rows.

Just add a BooleanProperty in your custom object and bind it to the TableCell value factory and you should see those checkbox.

When Android Lollipop was released, I was excited. Who wouldn’t? Every new version always comes packed with new features and enhancements.

Sad to say when I upgraded to Lollipop it gave my app problems instead. Two things my app used, an XML drawable that displays a radial gradient effect and an animated inside an AsyncTask class that uses Thread.sleep in between.

So first, the radial drawable.

I had a custom color and named it theme_green. It worked okay in previous versions but in Lollipop 5.0, the radial effect does not work anymore, and so does the color. It seems like only the startColor is used hence the different color result.

The other issue I had was the Thread.sleep inside the doInBackground() where I had a for loop that shows an animated and used the Thread.sleep to simulate a pause in between animation.

The result was that the animated got slow. I had to switch to using a TimerTask instead to preserve the smoothness of the animated that was working prior to Lollipop 5.0.

Oh, and even SystemClock.sleep() inside doInBackground() did not work either.

So there. Just to give you a heads up that you might think it is the Lollipop 5.0 operating system that is the issue. They definitely changed some things that affected how the Thread.sleep() works inside the doInBackground() method of an AsyncTask class.

Related Posts Plugin for WordPress, Blogger...