• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

What else needed to setRowIndex ?

 
Frederick Douglass
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The shortest way to state my question is :
why do setRowIndex and setColumnIndex not work in a GridPane as simply as they would/should appear to ?

In other words when I say set the row for a button ( say ) it may or may not actually end up in the row I actually specify.
I am obviously missing something. ( For instance, I obviously do not know enough about set rowConstraints
to figure out whether I actually need it here ).

Let me explain in more detail.

I have a GridPane with various Labels, TextAreas, Buttons and a ComboBox, all of various sizes.

I am adding them one by one to the gridpane and run the job every time I include all the code for the next object.
The latest object I have added is a ComboBox. Actuallly it fits more or less where I want it to go.
The problem arises when I try to add a label for the ComboBox ( l_type).
I show the relevant part of my code below. The code for l_type is what is commented out.
If I activate that block of code by removing the commenting then first, the label does NOT go where specified
by the setRowIndex and setColumnIndex. ( Actually It ends up in row 1, column 4 ).
And at least one other label moves also. ( " Investment Term (years) : " moves down to row 4 ).

What am I missing ? Thanks.

[
[/code]
 
John Damien Smith
Ranch Hand
Posts: 299
15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You call this:

Then you call this:

That is a weird thing to do.

The first add call includes parameters to set the row and column indices of the added item. So the second set of static constraint specifiers are both redundant (because you have already set the row and column constraints) and confusing (because you are setting the values different to the values used when you initially added the item). My advice is to either use one form or the other to initialize row and column indices but not both.
The other thing you have is things like this:


So, adding two different nodes at the same cell position (3,3). I haven't tested it, so I don't know what it would do, but in any case I wouldn't advise it. Instead use unique row/col settings for each node you add to the GridPane.
You are doing a similar thing with l_type and CSB_combobox:

So again, don't do that. If you really want two nodes to share the same cell space, then place the two nodes in a parent pane, then place only the parent pane in the grid. For example:

When sharing code with other developers, uou may also benefit from applying standard Java naming and camel case conventions:
https://google.github.io/styleguide/javaguide.html#s5-naming
https://google.github.io/styleguide/javaguide.html#s5.3-camel-case

You may benefit from playing with SceneBuilder a little bit to try out various layouts and constraints in a visual environment.
 
Frederick Douglass
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First, thank you for what you did NOT say but implied, namely that placing an object in a gridpane is ONLY
a question of setting row and column ( and indeed there are at least two ways to do that ).

Now I agree about what you call 'a weird thing to do' in effectively assigning rows and columns TWICE.
But there was a reasonable explanation for that.
For reasons I forget now, when I used 'add', the object did not go where I expected. ( I probably mixed up row and column. )
And the problem with setRowIndex and setColumnIndex statements was that they did not in themselves
actually add the object to the gridpane. So I did use BOTH 'add' and 'set'.

Now I have removed all the setRowIndex and setColumnIndex statements and taken much greater care with the add statements,
giving the code shown below, which puts everything where I want it.
( I note especially that the colons in the various Labels should line up directly above and below each other and they actually do. )
So thanks for the advice.

That leaves the ta_response TextArea. Its main difference from the other textareas is that it occupies several rows.
And its add statement includes a 'getChildren' clause. I did try to remove this but then a whole load of objects
went all over the place. Also when I increase the setPrefColumnCount parameter, from 16 to say 20,
the textareas ABOVE shift to the right accordingly. I conclude that the width of a given column is determined by
the widest object in that column ( in this case ta_response ). So in a grdpane what you CANNOT do is say
that different rows have different column sizes ?

 
John Damien Smith
Ranch Hand
Posts: 299
15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
> So in a grdpane what you CANNOT do is say that different rows have different column sizes ?

I'm not exactly sure what you mean by that.
You can set a columnSpan constraint on a node in the grid so that it may span across multiple columns. Perhaps that is what you want to do, perhaps not.

> That leaves the ta_response TextArea. Its main difference from the other textareas is that it occupies several rows.

Perhaps you want to set a rowSpan constraint for it then.

----

If you want further help, it might be an idea to provide an mcve (a minimal, complete program that somebody could copy and paste to compile, run and replicate any issues without making any code modifications). You also might want to include screenshots of what your program currently produces and a clear mock-up image of what it needs to produce.
 
Frederick Douglass
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As far as I am concerned the gridpane is working as required now and so there is no need for an mcve.
rowSpan and columnSpan looki interesting, thanks, but not actually necessary here.

Thank you very much for your help. Case closed.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic