Is there something better than ComponentListener on Resized

[clusardi2k]

The following code produced results which sometimes looked bad. I.E.: Resizing the window did not stop at my preferred width or the window had an unrealistic jerkly look to it. It's hard to discribe.

Is there some way other than the below code which will prevent resizing beyond a certain limit. I'm typed this in from a piece of paper!

myframe.addComponentListener(new ComponentAdapter()
{
@Override
public void componentResized (ComponentEvent e)
{
setSize (new Dimension (myPreferredWidth, getHeight()));
//super.coponentResized (e);
}
});

Thanks,

 

[Eric Sosman]

The following code produced results which sometimes looked bad. I.E.: Resizing the window did not stop at my preferred width or the window had an unrealistic jerkly look to it. It's hard to discribe.

Is there some way other than the below code which will prevent resizing beyond a certain limit. I'm typed this in from a piece of paper!

myframe.addComponentListener(new ComponentAdapter()
{
@Override
public void componentResized (ComponentEvent e)
{
setSize (new Dimension (myPreferredWidth, getHeight()));
//super.coponentResized (e);
}
});

It's not quite what you asked for, but would setResizable(false)
meet your need?

 

[clusardi2k]

It's not quite what you asked for, but would setResizable(false)

meet your need?

No, because I want one dimension to be resizable!

 

[Jeff Higgins]

On 09/21/2013 02:40 PM, (e-mail address removed) wrote:
LayoutManager

 

[John B. Matthews]

I want one dimension to be resizable!

BoxLayout; override get*Size() for the reasons mentioned here:

<http://stackoverflow.com/q/7229226/230513>

 

[clus]

On 09/21/2013 02:40 PM, (e-mail address removed) wrote: LayoutManager

How would I do this with GridLayout, since I'm using GridLayout. Here are the details.

In a frame, I first add a push button at the top. Below the button I add two tables, side by side.

The frame already resizes vertically to any length which is good.

But, I want the frame to not resize horizontally beyond a certain hardcodedlimit. I.E.: I want the frame to resize horizontally, but attempts to resize beyond a certain limit are prevented. So, if a user were to try to resize horizontally beyond the limit then the resulting horizontal width of the frame would be the limit.

Thanks,

 

[Eric Sosman]

How would I do this with GridLayout, since I'm using GridLayout. Here are the details.

In a frame, I first add a push button at the top. Below the button I add two tables, side by side.

The frame already resizes vertically to any length which is good.

But, I want the frame to not resize horizontally beyond a certain hardcoded limit. I.E.: I want the frame to resize horizontally, but attempts to resize beyond a certain limit are prevented. So, if a user were to try to resize horizontally beyond the limit then the resulting horizontal width of the frame would be the limit.

Perhaps it's time to ask a question: Why do you think it's a
good idea to prevent the user from arranging his own screen as
he pleases? Does your program understand the user's needs and
desires better than he himself does?

 

[Jeff Higgins]

Shrugs: provide some code and perhaps we'll see.

Perhaps it's time to ask a question: Why do you think it's a
good idea to prevent the user from arranging his own screen as
he pleases? Does your program understand the user's needs and
desires better than he himself does?

I've used such a program.

 

[Eric Sosman]

Shrugs: provide some code and perhaps we'll see.


I've used such a program.

Did you enjoy it? ;-)

That is: Did you consider it a benefit, a point in the
program's favor, when the program's window resisted all your
efforts to make it larger? Did this behavior improve your
experience of using the program?

 

[John B. Matthews]

I've used such a program.

Did you enjoy it? ;-)

That is: Did you consider it a benefit, a point in the
program's favor, when the program's window resisted all your efforts
to make it larger? Did this behavior improve your experience of
using the program?[/QUOTE]

I too have used such a program, almost daily, and I do not enjoy it.
This example is somewhat contrived, but it gives the flavor of the
experience.

<http://stackoverflow.com/a/12532237/230513>

 

[Eric Sosman]

Did you enjoy it? ;-)

That is: Did you consider it a benefit, a point in the
program's favor, when the program's window resisted all your efforts
to make it larger? Did this behavior improve your experience of
using the program?

I too have used such a program, almost daily, and I do not enjoy it.
This example is somewhat contrived, but it gives the flavor of the
experience.

<http://stackoverflow.com/a/12532237/230513>[/QUOTE]

Yeah, although I was thinking more about "accessibility,"
as it's now often called. Somebody with vision difficulties
may well use a

M U C H L A R G E R F O N T
M U C H L A R G E R F O N T
M U C H L A R G E R F O N T

than the programmer gifted with good eyesight had anticipated.
The large-font user might not be pleased at being forced to
scroll back and forth and back and forth instead of just making
the damn' window wider.

Now, perhaps the programmer is foresighted enough to
calculate his NoBiggerThan dimension based on the chosen font
size (if that's straightforward; I don't know how well Java
font metrics interact with externally-imposed overrides).
But wouldn't it be simpler just to let the user adjust the
window to whatever dimensions he likes?

We programmers grow accustomed to issuing commands to our
computers, telling them what to do in every circumstance (the
entire art of debugging amounts to discovering how our own
commands differ from what we really meant). The tendency to
treat the users as extensions of our computers -- to command
them the same way we do the machines -- must be resisted.

Clusardi: If your goal proves difficult or even impossible
to achieve, that may not be entirely a Bad Thing. Try to look
on the bright side, and strike a blow for libertarianism.

 

[Jeff Higgins]

Did you enjoy it? ;-)

That is: Did you consider it a benefit, a point in the
program's favor, when the program's window resisted all your
efforts to make it larger? Did this behavior improve your
experience of using the program?

Oh. I was responding to your comment concerning the program(mer)
who perhaps understands my needs and desires better than I do.
Many programmers provide sensible default behavior for users,
like me, who might not be familiar with the program or even
the subject matter. I don't recall seeing a GUI behavior such as
(e-mail address removed) describes, but maybe the subject matter warrants such.

 

[Eric Sosman]

Oh. I was responding to your comment concerning the program(mer)
who perhaps understands my needs and desires better than I do.
Many programmers provide sensible default behavior for users,
like me, who might not be familiar with the program or even
the subject matter. I don't recall seeing a GUI behavior such as
(e-mail address removed) describes, but maybe the subject matter warrants such.

Sorry for the misunderstanding.

It's certainly possible that Clusardi's situation does in fact
make such Thou Shalt Not behavior desirable, perhaps useful or even
essential. That's why I raised the question: Not to deny that there
could be a reason, but to ensure that the reason had actually been
examined and evaluated.

I guess there are three questions, really:

1) Is the size restriction really desirable?

2) If (1), then must it be applied to the entire frame
rather than to a sub-component like an interior JPanel?

3) If (2), then Clusardi's original question: "How?"

Maybe if the reasons for "Yes" answers to (1) and (2) were
made public, somebody might have a better idea how to answer
(3) -- or how to do something different but satisfactory.

 

[Jeff Higgins]

Sorry for the misunderstanding.

It's certainly possible that Clusardi's situation does in fact
make such Thou Shalt Not behavior desirable, perhaps useful or even
essential. That's why I raised the question: Not to deny that there
could be a reason, but to ensure that the reason had actually been
examined and evaluated.

I guess there are three questions, really:

1) Is the size restriction really desirable?

2) If (1), then must it be applied to the entire frame
rather than to a sub-component like an interior JPanel?

3) If (2), then Clusardi's original question: "How?"

Maybe if the reasons for "Yes" answers to (1) and (2) were
made public, somebody might have a better idea how to answer
(3) -- or how to do something different but satisfactory.

Oops. I need to learn to read, or at least pay attention.
I missed the fact that we were discussing the resize behavior
of a top level window. Not really sure how one would go about that.
Maybe back to the listener route.

 

[Jeff Higgins]

Oops. I need to learn to read, or at least pay attention.
I missed the fact that we were discussing the resize behavior
of a top level window. Not really sure how one would go about that.
Maybe back to the listener route.

Or maybe there's a way to disable the gripper when you reach a size?
Shrug. Over and out.

 

[clusardi2k]

Perhaps it's time to ask a question: Why do you think it's a good idea to
prevent the user from arranging his own screen as he pleases? Does your program
understand the user's needs and desires better than he himself does?

I want to prevent the user from horizontally resizing the window beyond a certain width because (if I didn't) anything to the right of my two tables would be a a solid gray color of nothing.

So, without the functionality that I want, if the user resizes the window it will look somthing like this exaggerated example:

[][]||||||

Where I represent a table with [] and gray solid areas are represented by |.

The code that I've, unsuccessfully, tried to use is similar to the code here:

http://docs.oracle.com/javase/tutorial/uiswing/layout/gridbag.html

 

[Eric Sosman]

Why do you think it's a good idea to
prevent the user from arranging his own screen as he pleases? Does your program
understand the user's needs and desires better than he himself does?

I want to prevent the user from horizontally resizing the window beyond a certain width because (if I didn't) anything to the right of my two tables would be a a solid gray color of nothing.

So, without the functionality that I want, if the user resizes the window it will look somthing like this exaggerated example:

[][]||||||

Where I represent a table with [] and gray solid areas are represented by |.

Maybe the user will find the blank gray expanses soothing?
In any event, they're of his own making -- and he can un-make
them again if he finds them objectionable. I sincerely doubt
that your efforts to protect him from his own faulty aesthetic
sense are worth while.

The code that I've, unsuccessfully, tried to use is similar to the code here:

http://docs.oracle.com/javase/tutorial/uiswing/layout/gridbag.html

Notice that this page is in a section whose title is
"Lesson: Layout Out Components *Within* a Container" [emphasis
mine]. You can control the sizes and layouts of things *inside*
a top-level container pretty closely, but the TLC itself is a
creature of the native windowing system, sized and positioned
(and decorated, hidden, revealed, ...) by that native system.
You're free to provide hints -- for example, the layout manager
of the frame's content pane can suggest the pane's dimensions --
but the native windowing system is not obliged to honor your
suggestions. (This is viewed as a Good Thing, because it gives
your desktop app a fighting chance of being usable on a teeny-
tiny phone screen, for example.)

To put it more simplistically: Java doesn't own "the screen"
and has no layout manager for it.

 

[Arne Vajhøj]

Did you enjoy it? ;-)

That is: Did you consider it a benefit, a point in the
program's favor, when the program's window resisted all your
efforts to make it larger? Did this behavior improve your
experience of using the program?

The program was hard to code - only fair if it is also hard
to use.



I mean UX does mean "User eXpel" right?



Arne