Hi James,
I don't know much about how the game works in practice, but one
potential simplification would be to use just five edit fields, one per
row, each five characters wide. That would simplify the layout and the
amount of book-keeping you need to do.
However, as far as Forms are concerned, whether a Form would be a good
choice here depends on how much you need to do in response to user
input. A Form is great when you want a user to fill out some fields and
apply some validation to them before accepting the form as a whole set
of values. In this case that doesn't sound to me like what is going on,
where instead you probably want to have a stateful progression of input
(based on "... the user fills in a row [and] they press enter to submit
... and move on to the next row.").
If it were me, I'd skip using a Form and just lay out five editors in a
sequence and set up the event handling to transition the focus between
them based on the game's rules.
But to answer your questions about forms:
1) you can have as many forms as you want, but the issue here is not
how many you have, but whether you want to have them all present in
the UI at the same time with some ability to go between them. It's
technically possible because you intercept all of the events, but I
wouldn't recommend it.
2) From the docs: "Also note that, by default, forms and their field
inputs are concatenated together in a vBox. This can be customized
on a per-field basis and for the entire form by using the functions
setFieldConcat and setFormConcat, respectively." So you'd want
to use "setFormConcat hBox".
3) You'll need some way to build a Name for each editor, so if you
have 25 editors, you either need 25 constructors (not recommended) OR
something like one constructor parameterized on something like editor
index. Still, this is a bad smell: if you think you need 25 editors,
there is probably a better way (which is what led me to think of the
five-editor proposal above).
I hope that helps!
--
Jonathan Daugherty