I have two Panes with populated nodes.
when I layout the panes side by side I can act on them and all works fine.
what I now want to do is, that I stack them at the same position, so that only one pane is visible. Similar nodes with the statement: node.toFront();
Is that possible?
M
Definitively is possible, you just need to use a StackPane, this component has the required behaviour by default. However, I would recommend you remove the first node before to add another one, just for performance reasons.
Related
i'm struggling with a vertical box i added a transition to, it stays at the back of the other nodes like label and imageview. i tried using toFront() but it didn't work. also i tried using .setStyle("-fx-view-order: [number]") but i was lost a bit in what the numbers represent exactly is it the order of nodes ascending or descending.
#1
vb.setStyle("-fx-view-order: 0");
img.setStyle("-fx-view-order: 1");
didn't work
#2
vb.setStyle("-fx-view-order: 1");
img.setStyle("-fx-view-order: 0");
didn't work
The easiest way to get a Node to render on top is to move it to the end of the child node list for its parent Node.
Note the documentation for -fx-view-order mentions: "The parent traverses its children in decreasing viewOrder order." To me that means higher view order is behind (drawn first) relative to lower view order. However, this is all relative to the parent node, not the Scene. Give us a reproducible example of what you are doing.
Also, what version of JavaFX are you using? -fx-view-order was not in JavaFX 8 (JDK 8)
https://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html#node
I have complex design that has several layers on top of each other. Problem is that if I click on object, other object that on top of it gets selected. How I can switch off visibility of my top objects while working on my bottom layer, so that they won't get in the way?
I finally found how to achieve what I wanted. Just select element that in the way and in properties remove tick from visible. Now you can design without anything obstructing your view! Just don't forget to make visible all elements before you save your work.
I'm working on a simple widget system, and I'm implementing some containers right now.
Here's the situation I find myself in:
I have a Widget base class, a Container class, which is a widget that can contain other widgets, and several widget sub classes like Button.
I have two types of container: Container itself, which positions children absolutely, and Box, which will stack widgets next to each other, either horizontally or vertically.
Each widget draws itself at x=0, y=0. Therefore, containers need to add an offset to the drawing context before the widgets are told to draw themselves.
Each widget does its own hit testing based on its x/y position.
So far, it works fine. But it falls apart now that I'm implementing Box: What I do is that I overwrite the drawfunction inherited from Container to draw them all in next to each other, instead of based on their x/y position. Quite simple.
But event handling is totally off now, as the widget's x/y position has become meaningless.
I think I have two options:
Have the widget do hit testing at position x=0, y=0, like drawing. Then recalculate the mouse position to match that in Container.
Make each layout set x/y for its children, and make children draw themselves at their x/y position again. No more offsets for the drawing context
The first one is a bit ugly, I think. The second one is pretty complicated to implement, since I need to react to position changes in widgets.
How to other widget systems like Qt, Gtk and wxWidgets generally tackle this? I've looked at the source of some of these, but can't quite figure that out, it's too sophisticated. I don't have any resizing or packing issues to consider.
You are trying to implement your own layout system. You should expect it to be difficult.
I would advise against the first method. The x,y coordinates of a widget are not only used by the widgets themselves, but by anyone outside of the container who wants to do something with the widget.
The second solution is what I've chosen to implement custom widgets made of several smaller widgets and it's not that hard to put together if you don't want too many features.
Just get the widgets when they are added to your container, set their position to the current free spot, and move on to the next.
How can I display one component on the top of another one in flex without explicitly mentioning x-axis & y-axis?
Use canvas and inside canvas you can add controls that will be displayed one above another, the last one added will be the top most one and first added will stay in behind.
Something else to consider, depending on your UI:
This is still a bit 'hacky' (any solution for doing this will be), but given a container (VBox etc) with two or more components, set the includeInLayout property in the first component to false. When the container renders the second component will ignore the first and draw on top.
This also would allow you to add additional components in that same container, but obviously it depends on your UI a great deal.
Why is it that the mx.core.Container uses its contentPane sometimes, but doesn't at other times?
Or, in other words, how come the children of Container are only put into the contentPane if some complex logic decides that they should be put there? Why not simply always put all children in the contentPane?
If memory serves, addingChild() (which is probably an inherited method) in the sdk will be your answer. It has to do with styles and since I'm not the person to talk to about styles, I'm turning this answer into a community wiki, can't say I've ever done this...
Content pane is a simple display object that the container uses internally to host children but only when scrolling enabled. So this is why the children are 'sometimes' being placed inside the content pane. :)
This content pane is then being moved and this is how the container is being scrolled.
When switching 'scrollContent' ON and OFF, Flex moves the children from the container itself to the content pane and vice versa. Before the first move to the content pane it creates the pane.
What's also important is that this process is being transparent to the user, i.e. when adding/removing children, the container takes care of where to put them (to the container itself or the content pane). Also note that the layout mechanism operates on the children the same way in both cases (either with or without the content pane).
And now the answer to the question "Why not simply always put all children in the contentPane?".
Performance! We always tend to minimize the number of components in the application, so why use the content pane with each and every container while only the small number of containers has scrollContent set to true? The majority of containers in the average Flex app is just grouping its children in the horizontal or vertical fashion.