I am currently using a JavaFX TableViewin an application and experiencing the following strange behaviour:
The resize policy is set to CONSTRAINED_RESIZE_POLICY, and when I start the application, the window is not maximized. However, when I maximize the window, two things happen:
The columns do resize, but do not fill the whole space, there is still some space left on the right side.
The columns do not line up with the headings anymore.
As soon as I resize one column manually, the layout is adjusted and everything looks as expected - meaning the columns fill the whole space and line up with the headings.
This is the css I apply to the table:
.rowWithTopBorder {
-fx-background-color: #555555, -fx-background ;
-fx-background-insets: 0, 2 0 0 0;
}
.boldRow {
-fx-font-weight: bold;
}
Is there a bug or am doing something wrong?
Related
I have a table with relatively long values in some columns and have dynamic scaffolding turned on for it in my Grails application (I'm using Grails 3.3.8). Thus, on some screen resolutions, they don't fit on the screen and the rightmost columns end up outside of the screen - thing is, the horizontal scrolling bar does not appear then and so the user doesn't even know they're there. The only way to bring them back in is to zoom out - you can't scroll with either the bar (cause it's not there) or the mouse wheel; arrows aren't working either.
How can I fix this so that the horizontal scrolling bar appears like on a "regular" webpage on which content exceeds the size of the screen?
OK, figured this out! So the trick is to edit the assets/stylesheets/main.css file in the app folder, specifically this bit:
body {
background-color: #F5F5F5;
color: #333333;
overflow-x: hidden; /* <<<< */
-moz-box-shadow: 0 0 0.3em #424649;
-webkit-box-shadow: 0 0 0.3em #424649;
box-shadow: 0 0 0.3em #424649;
}
We edit the overflow-x from hidden to auto and voila! :)
As I have custom cells for a particular ListView, I have big trouble to understand how to to remove the "natural" sort of margin / spacing there is between each cells, and, even worse, on the right and left sides of said cells.
Here's an example:
]1
As you can see, I use a color to bring out each cell. You cannot see the space at the end of the cells (on their right side), because I need to scroll, but you can trust me, the white space is equal on each side (bigger on the left & right, though...) which is not normal as I have specifically designed these cells so that their width is as large as the ListView so that there is no need to use horizontal scrolling. My issue kinds of defeat my purpouse...
Each cell consists of one AnchorPane with the image and the one label.
The AnchorPane is painted in yellow (-fx-background-color: yellow;).
And as you can clearly see, there is these white spaces all around the cells.
FYI, here I am using JavaFX 8 / 2.2 SDK but I intend to use JFoenix JFXListView & JFXListCell. However, the spacing is even worse using those.
Strange point: I also painted the ListViewin green, but such color is nowhere. to be seen. I guess all the cells (and the empty one) overwrites the ListView content, so it would make sense not to see its background. However, this means the cells are somehow "corrupted" since white spaces are "added" all around my cells.
I have tried to set padding to 0 for everything but in vain.
Finally, in the onUpdateItem method, I do call the super method and when the cell is not flagged as empty, I set the graphic to the aforementioned AnchorPane otherwise I set it to null, which is clearly consistent to my screenshot.
Thanks for the help !
If you look at the default CSS stylesheet for JavaFX, modena.css, you'll see:
.list-cell {
-fx-padding: 0.25em 0.583em 0.25em 0.583em; /* 3 7 3 7 */
}
This is where the padding for the ListCells is coming from. To remove this padding simply add your own stylesheet which contains:
.list-cell {
-fx-padding: 0px;
}
Or call setStyle for each of your ListCells:
setStyle("-fx-padding: 0px;");
The second option would best be done by using a custom cell factory.
listView.setCellFactory(v -> new ListCell<>() {
{
setStyle("-fx-padding: 0px");
}
#Override
protected void updateItem(Object item, boolean empty) {
super.updateItem(item, empty);
if (empty || item == null) {
setText(null);
setGraphic(null);
} else {
// your custom display logic
}
}
});
Also, after some quick testing with JFoenix it looks like using the above will also work for JFXListCell; though you have to be careful about overriding updateItem because JFXListCell does a lot in its implementation.
I set the red background of the cell as default to make sure that the artifacts I see between cells are in fact created by the .list-cell.
No matter how hard I tried, I could not get rid of it, even with the padding 0px. The red background was still visible every other cell in my case.
I suppose, it is a rounding error...
So, the only thing that worked was using a negative padding to remove any spacing | padding | margin between cells.
.list-cell{
-fx-font-weight: normal;
-fx-text-fill: white;
-fx-padding: -1px;
-fx-background-color: red;
}
So in my Java Application I have a grid pane with a time table of various names.
To change the color of the one my mouse is hovering over I do this:
.hours_grid_cell_pane:hover{
-fx-background-color: #ffff00;
-fx-border-color: #000000;
}
This is pretty simple. I want to know how I do the same thing to all the cells to the left, right, top, and bottom of the one I'm hovered over. Essentially forming big where my mouse is.
I've tried
.hours_grid_cell_pane:hover:left
and
.hours_grid_cell_pane:left
but that doesn't work. Is there any way to do this?
I'm displaying a dashed border around an input text element with:
border: 1px dashed black;
Can I somehow define an "offset" to tell the browser where to start with the border?
My goal is to define a timer, and alter the offset of the dashed border (using java GWT element.setAttribute()), so that the simulation of a clockwise-moving dashed border results.
Is there any existing offset for borders with css?
There is a somewhat convoluted workaround to achieve a similar effect using an animated .gif as the background of a div, with whatever content you wanted "bordered" placed in a second div nested within the first with a 1px margin.
The animated .gif should be a small square (8px x 8px) with 3px-wide diagonal lines moving across it from left to right (you can adjust the sizes to adjust the width of the lines). When only a pixel's width or height of this image is visible, it appears to be a moving dashed border.
This technique is detailed here by Matthew Taylor at his blog: http://matthewjamestaylor.com/blog/animated-photoshop-selection-on-a-web-page.
I have a JavaFX app that atm is just a BorderPane with a ToolBar at the top. It looks like this:
I was wondering whether there was a way to remove the line between the top of the window and the ToolBar so that it looks something like this:
I've already tried setting the ToolBar's border width and the BorderPane's border width to 0 but neither helped.
The line is toolbar's first background color that is only shown 1px above and bottom of it. Checkout -fx-background-insets below
.tool-bar:horizontal {
-fx-background: derive(-fx-base,-30%);
-fx-background-color:
linear-gradient(to bottom, derive(-fx-base,-30%), derive(-fx-base,-60%)),
linear-gradient(to bottom, derive(-fx-base,65%) 2%, derive(-fx-base,-20%) 95%);
-fx-background-insets: 0, 1 0 1 0;
-fx-background-radius: 0, 0 ;
-fx-padding: 0.416667em 0.833em 0.416667em 0.833em; /* 5 10 5 10 */
-fx-spacing: 0.333em; /* 4 */
-fx-alignment: CENTER_LEFT;
}
To remove the top line, change the inset to:
-fx-background-insets: 0, 0 0 1 0;
To tweak default looks of JavaFX control's, I suggest to take a look at caspian.css file.
I tried amru's answer and it removed the line from the top of the toolbar. Unfortunately, there was still a line at the bottom of the window decoration. After spending a couple of hours researching this, I found that there's currently no way to do what I wanted to in JavaFX (without embedding the JavaFX in a swing window which isn't an option for other reasons) although it's a known issue and a fix is being worked on for a future release (see here).