NX: GUI drafts (some layout probs)

[Jacques Bosch]

Hi guys.
Firstly, does this GUI draft look OK?
I used text boxes for the find to keep things simple. (Is it really necessary to use populated combos?)
(Image removed)
Secondly, when maximized, it still looks ok, but everything is a bit stretched vertically. I would like everything to stay the same size, with the JTable taking up all the extra space. See below.
(Image removed)
And then, thirdly, my Find buttons disappear when making it smaller. You can see a bit of them under the name box, where they wrapped to. See below. Why is this happening? I thought FlowLayout was supposed to make sure stuff gets displayed right, even when wrapped. There is enough space.
(Image removed)
Short breakdown of what I used:
BorderLayout for the main container, with the menu bar at NORTH, and the lightweight Box container at CENTER. All the other components are nested within this vertical Box, and are as follows:
* Two nested JPanels with BorderLayout and FlowLayout respectively to manage
the find controls.
* The table label, and the JTable itself inside a JScrollPane.
* Another JPanel at the bottom for the Book and Exit button and for the
status label.
Thanx much for any help / comments!
[ February 05, 2004: Message edited by: Jacques Bosch ]

[Terry Martinson]

Jacques -
First, I will preface this with the fact that this SCJD assignment is my first time attempting a GUI. I am more of a web component person at work.
I put my table on top and the potential user action buttons at the bottom as per this thread I don't know if it really matters either way, top or bottom. However, I would probably try to keep the user action buttons either at the top or bottom rather than split.
I ended up not using much for FlowLayout. I am using a GridLayout in a couple places to line up the user prompts/user entry boxes nicely. However, in at least one of the cases it does make the action button stretch out to be kind of big.
I don't think the combo boxes are required. However, I did them as it made a lot of the search stuff very easy and seemed like it would be a good fit since the users would only be doing searches that would most likely pull up data (i.e. I say most likely because if another thread deletes a record, a search on a name that existed before may come up empty). Lots of posts out here regarding combo boxes and probably lots of different opinions.
Gui experts out there - other ideas???
TJ

[Jacques Bosch]

Hi TJ.
Thanx for your thoughts.

I put my table on top and the potential user action buttons at the bottom as per this thread I don't know if it really matters either way, top or bottom. However, I would probably try to keep the user action buttons either at the top or bottom rather than split.

My feeling is, for 'work flow'.
* User starts at the top.
* Enter criteria and does a search.
* Now moves down to the table and the results.
* Selects the one wanted.
* Now moves down more and clicks Book.
Seems natural to me.
Maybe I'm wrong.

[George Marinkovich]

Hi Jacques,
I like the layout and agree with your workflow design. Typically a user searches for a record, selects it in the table, and then presses the book button. Top to bottom is a natural flow I think. I'll let the GUI experts handle the resizing issues.
Hope this helps,
George

[Jacques Bosch]

Thanx George.
Now to sort out the resizing....

[Javini Javono]

Originally posted by Terry Martinson:
Jacques -
I don't think the combo boxes are required. However, I did them as it made a lot of the search stuff very easy and seemed like it would be a good fit since the users would only be doing searches that would most likely pull up data (i.e. I say most likely because if another thread deletes a record, a search on a name that existed before may come up empty). Lots of posts out here regarding combo boxes and probably lots of different opinions.
Gui experts out there - other ideas???
TJ

Hi,
I'm not sure I understand the details of why you would use a combo box?
Could you please explain?
Also, once explained, how does this relate to the requirement that many
people have that the user can search for "an" and get "animal" returned
in the result? It may be obvious once I understand how the combo box
is used to make the searching function easier for the user.
Since I wrote the above, I went through looking for search/find related
links on this system, and found this sub-phrase:
"ComboBox to indicate which fields to compare"
So, is this what you had in mind? The user selects a value from a
ComboBox such as "Name", "Address", "Zip", and that specifies
which database record's field will be searched. Then in a separate,
but related text field, the user types in the search, such as
"Zip" from combo box, then "88" for first two digits of zip?
Thanks,
Javini Javono
[ January 20, 2004: Message edited by: Javini Javono ]

[Jacques Bosch]

Hi Javini.

So, is this what you had in mind? The user selects a value from a
ComboBox such as "Name", "Address", "Zip", and that specifies
which database record's field will be searched. Then in a separate,
but related text field, the user types in the search, such as
"Zip" from combo box, then "88" for first two digits of zip?

No, I don't think so. At least not me.
But that's quite a good idea for a real world app too.
What I meant was to have the name and location combos populated with the possible unique values from those columns in the DB. So instead of having to type in "Smallville" it could just be selected from the location combo.
But, IMHO, that is unneeded for the scope of the project. Just wanted some other opinions.
But what I really want to know is how to sort out my layout problems.

[Javini Javono]

Hi,

But what I really want to know is how to sort out my layout problems.

I may not be qualified to answer your questions, in that I myself am unsure
about the preliminary solutions I've come up with.
Main Window Shrinking in Size
--------------------------
My main window can shrink in size to about 800 x 600, and what happens
at this far less than idea size, is that scroll bars appear for quite a few things:
namely, the JTable gets its own vertical scrollbar (and somehow it was coded
so that the JTable does not scrunch together making very small columns, thus,
there never is a horizontal scrollbar0, and the window itself, gets horiztonal
and vertical scrollbars.
So, at this small size, 800 x 600, the application is not as usable in the sense
that your screen is simply considered to be too small; but, if the user insists
on using this tiny screen size, the user can still get away with using the application,
as long as the user doesn't might using the scroll bars to manuevre about.
I don't know if this is a great solution. But I will document that my minimum
window size is 1024 x 764, and most anything less than this will kick in the
scroll bars.
So, this is, perhaps, one way to handle the master window getting smaller;
I don't know what others have done or what they may suggest. I'd put up
a picture of my application's user interface, that is, post it on a web site,
but I suspect that that is frowned upon in this newsgroup (that is, Andrew
may have been busy recently and has not had a chance to read these posts;
but, generally, I think posting complete locking solutions, and any kind of
posting of the implemented user interface is against the rules). Hopefully,
however, my explanation can give you an idea of how I solved it, even though
this explanation is not worth a thousand words.
Basically, and I think I may have said this already, if not in this thread, then in
another, I did this (though I have not looked at my code, so this may not be exact):

Master Window --> JTabbedPane --> BorderLayout's Center --> JPanel --> JScroll gizmo --> JTable

So, try out the above, or a variant of it, and see if your table width stays reasonable.
Whatever I did, I found by applying common principles of the layout managers,
and probably being lucky, though I did have to iterate a few times to make the
table behave correctly.
Also, stick some dummy data into your JTable during this phase, if you wish.
Thanks,
Javini Javono

[Jacques Bosch]

For anybody interested, I sorted my layout problem, when maximized, out as follows:

// Make sure the table uses the max amount of screen space that is available.
Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
dbTable.setPreferredScrollableViewportSize(new Dimension(screenSize));

[Javini Javono]

Hi,

//Make sure the table uses the max amount of screen space that is available.
Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
dbTable.setPreferredScrollableViewportSize(new Dimension(screenSize));

Here's a little bit of esoteric information I read within the month or so.
If you check the getDefaltTookit() method it can throw an unchecked exception
"if there is any error." But, I read, somewhere, or saw, somewhere, that one
should not rely 100% on Toolkit, as it is based on run-time specific implementations,
some of which may not work in all environments.
So, while I will certainly use Toolkit to size my initial window and center it on the
screen, I will also certainly put it in a try-catch block, and if Toolkit fails, make
a guess at a "reasonable" screen size.
Just a thought. Whether Sun is aware of these subtleties or not, which would
fall under "general considerations," is unknown by me.
Thanks,
Javini Javono

[Jacques Bosch]

Oh no. That's scary.
Thank you for pointing that out for me.
Well, I suppose I don't even have to use DefaultToolkit. I could just do something like this:

//Make sure the table uses the max amount of screen space that is available.
dbTable.setPreferredScrollableViewportSize(new Dimension(3000, 3000));

Since the point is just to get the JTable to use as much space as is available, you can actually use ridiculously large dimensions.