 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
ashwinijain
Guest
|
 Posted: Tue Nov 28, 2006 8:11 am Post subject: Re: how to print the data with components? |
 |
|
Andrew Thompson wrote:
| Quote: | ashwinijain wrote:
...
even i want to save that form as it is (i mean, i want to save that
data with its GUI)...
There are a number of ways (and levels) of saving
and restoring the state of a GUI.
Here are some..
- implement serializable on the classes*, then
write/restore them as required. That is fragile
across class version changes (breaks).
- If using 1.4+, use the XMLDecoder/Encoder
for the same basic thing.
* Although you might store/restore 'the frame' and
all its components, it might makes sense to store a
more limited form of the data, such as a CSV file
that is the data in the JTable. If that is the case,
simply create a custom object to contain the
data of interest (or store the Vector that is the data,
etc.) - this can even help prevent the class version
changing when using serialisation.
- Use Properties(?) class
- Use the Web-Start API PersistenceService
The last two will only accept token/value String's, AFAIR.
HTH
Andrew T.
|
thanks but i want to print the java components on paper..
how can i print it..
how to use printable class? |
|
| Back to top |
|
 |
Michael Dunn
Guest
|
| Posted: Tue Nov 28, 2006 10:44 pm Post subject: Re: problem with setting a panel size within a frame |
|
|
"Adam Sandler" <corn29 (AT) excite (DOT) com> wrote in message
news:1164729419.208051.309040 (AT) h54g2000cwb (DOT) googlegroups.com...
try this
import java.awt.*;
import javax.swing.*;
class MyFrame extends JFrame
{
private static final long serialVersionUID = 1L;
public void showFrame()
{
setTitle( "Please Wait..." );
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setLayout(new GridBagLayout());
JPanel centerPanel = new JPanel();
centerPanel.setBorder(BorderFactory.createLoweredBevelBorder());
//centerPanel.setPreferredSize(new Dimension(50, 25));
centerPanel.setPreferredSize(new Dimension(50, 25));
//Dimension screenDim =
//Toolkit.getDefaultToolkit().getScreenSize();
//Rectangle winRect = getBounds();
//setLocation((screenDim.width - winRect.width) /
//2,(screenDim.height - winRect.height) / 2);
//getContentPane().add(centerPanel);
getContentPane().add(centerPanel,new GridBagConstraints());
setSize(225, 100);
setLocationRelativeTo(null);//<-----
setVisible(true);
}
public static void main(String[] args){new MyFrame().showFrame();}
} |
|
| Back to top |
|
|
Michael Dunn
Guest
|
| Posted: Tue Nov 28, 2006 10:51 pm Post subject: Re: how to print the data with components? |
|
|
"ashwinijain" <ashwinijain27 (AT) gmail (DOT) com> wrote in message
news:1164694016.524437.241360 (AT) 45g2000cws (DOT) googlegroups.com...
| Quote: |
thanks but i want to print the java components on paper..
how can i print it..
how to use printable class?
|
from sun's forums, author of Standard/SpecialPrint is Tom Jacobs
I'd post a link, but I had to modify a couple of things to get it to work,
so easier to post the code.
(don't ask me how it works, I have no idea)
import java.awt.Dimension;
import java.awt.Graphics;
import java.awt.*;
import java.awt.image.BufferedImage;
import java.awt.print.*;
import javax.print.PrintException;
import javax.swing.*;
import java.awt.event.*;
class Testing
{
public void buildGUI()
{
JFrame.setDefaultLookAndFeelDecorated(true);
JPanel p = new JPanel(new GridLayout(2,1));
p.add(new JLabel("Hello"));
JButton btn = new JButton("World");
p.add(btn);
final JFrame f = new JFrame();
f.getContentPane().add(p);
f.pack();
f.setLocationRelativeTo(null);
f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
f.setVisible(true);
btn.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent ae){
StandardPrint sp = new StandardPrint(f);//<----f is the component to print
try{sp.start();}catch(Exception e){}
}
});
}
public static void main(String[] args)
{
SwingUtilities.invokeLater(new Runnable(){
public void run(){
new Testing().buildGUI();
}
});
}
}
class StandardPrint implements Printable, Pageable {
Component c;
SpecialPrint sp;
PageFormat mFormat;
boolean mScale = false;
boolean mMaintainRatio = true;
public StandardPrint(Component c) {
this.c = c;
if (c instanceof SpecialPrint) {
sp = (SpecialPrint)c;
}
}
public StandardPrint(SpecialPrint sp) {
this.sp = sp;
}
public boolean isPrintScaled () {
return mScale;
}
public void setPrintScaled(boolean b) {
mScale = b;
}
public boolean getMaintainsAspect() {
return mMaintainRatio;
}
public void setMaintainsAspect(boolean b) {
mMaintainRatio = b;
}
public void start() throws PrinterException {
PrinterJob job = PrinterJob.getPrinterJob();
if (mFormat == null) {
mFormat = job.defaultPage();
}
job.setPageable(this);
if (job.printDialog()) {
job.print();
}
}
public void setPageFormat (PageFormat pf) {
mFormat = pf;
}
public void printStandardComponent (Pageable p) throws PrinterException {
PrinterJob job = PrinterJob.getPrinterJob();
job.setPageable(p);
job.print();
}
private Dimension getJobSize() {
if (sp != null) {
return sp.getPrintSize();
}
else {
return c.getSize();
}
}
public static Image preview (int width, int height, Printable sp, PageFormat pf, int pageNo) {
BufferedImage im = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);
return preview (im, sp, pf, pageNo);
}
public static Image preview (Image im, Printable sp, PageFormat pf, int pageNo) {
Graphics2D g = (Graphics2D) im.getGraphics();
int width = im.getWidth(null);
int height = im.getHeight(null);
g.setColor(Color.WHITE);
g.fillRect(0, 0, width, height);
double hratio = height / pf.getHeight();
double wratio = width / pf.getWidth();
//g.scale(hratio, wratio);
try {
sp.print(g, pf, pageNo);
}
catch(PrinterException pe) {
pe.printStackTrace();
}
g.dispose();
return im;
}
public int print(Graphics gr, PageFormat format, int pageNo) {
mFormat = format;
if (pageNo > getNumberOfPages()) {
return Printable.NO_SUCH_PAGE;
}
Graphics2D g = (Graphics2D) gr;
g.drawRect(0, 0, (int)format.getWidth(), (int)format.getHeight());
g.translate((int)format.getImageableX(), (int)format.getImageableY());
Dimension size = getJobSize();
if (!isPrintScaled()) {
int horizontal = getNumHorizontalPages();
int vertical = getNumVerticalPages();
int horizontalOffset = (int) ((pageNo % horizontal) * format.getImageableWidth());
int verticalOffset = (int) ((pageNo / vertical) * format.getImageableHeight());
double ratio = getScreenRatio();
g.scale(1 / ratio, 1 / ratio);
g.translate(-horizontalOffset, -verticalOffset);
if (sp != null) {
sp.printerPaint(g);
}
else {
c.paint(g);
}
g.translate(horizontal, vertical);
g.scale(ratio, ratio);
}
else {
double ratio = getScreenRatio();
g.scale(1 / ratio, 1 / ratio);
double xScale = 1.0;
double yScale = 1.0;
double wid;
double ht;
if (sp != null) {
wid = sp.getPrintSize().width;
ht = sp.getPrintSize().height;
}
else {
wid = c.getWidth();
ht = c.getHeight();
}
xScale = format.getImageableWidth() / wid;
yScale = format.getImageableHeight() / ht;
if (getMaintainsAspect()) {
xScale = yScale = Math.min(xScale, yScale);
}
g.scale(xScale, yScale);
if (sp != null) {
sp.printerPaint(g);
}
else {
c.paint(g);
}
g.scale(1 / xScale, 1 / yScale);
g.scale(ratio, ratio);
}
g.translate((int)-format.getImageableX(), (int)-format.getImageableY());
return Printable.PAGE_EXISTS;
}
public int getNumHorizontalPages() {
Dimension size = getJobSize();
int imWidth = (int)mFormat.getImageableWidth();
int pWidth = 1 + (int)(size.width / getScreenRatio() / imWidth) - (imWidth == size.width ? 1
: 0);
return pWidth;
}
private double getScreenRatio () {
double res = Toolkit.getDefaultToolkit().getScreenResolution();
double ratio = res / 72.0;
return ratio;
}
public int getNumVerticalPages() {
Dimension size = getJobSize();
int imHeight = (int)mFormat.getImageableHeight();
int pHeight = (int) (1 + (size.height / getScreenRatio() / imHeight)) - (imHeight ==
size.height ? 1 : 0);
return pHeight;
}
public int getNumberOfPages() {
if (isPrintScaled()) return 1;
return getNumHorizontalPages() * getNumVerticalPages();
}
public Printable getPrintable(int i) {
return this;
}
public PageFormat getPageFormat(int page) {
if (mFormat == null) {
PrinterJob job = PrinterJob.getPrinterJob();
mFormat = job.defaultPage();
}
return mFormat;
}
}
interface SpecialPrint {
public Dimension getPrintSize();
public void printerPaint(Graphics g);
} |
|
| Back to top |
|
|
J. David Boyd
Guest
|
| Posted: Tue Nov 28, 2006 11:28 pm Post subject: Re: Are there any good Java XML UI toolkits |
|
|
"Chris Uppal" <chris.uppal (AT) metagnostic (DOT) REMOVE-THIS.org> writes:
| Quote: | Dale King wrote:
Is there any really good XML API for creating Swing UI's?
I can't help with suggestions for what already exists, but the thought strikes
me: how hard would it be to do yourself ? Since (as I understand it) you are
not looking for any kind of abstraction away from Swing, but rather the ability
to specify Swing GUIs in XML instead of boilerplate Java code, it seems that a
table-driven approach would be quite powerful. Your hand-written Java code
(for interpreting the XML) would be table driven, mapping XML tags/attributes
into Swing constructions via either reflection or some sort of factory; and the
tables would be generated (off-line) by reflection on the Swing classes.
YAGNI, of course, is your friend in any such project ;-)
-- chris
|
<SWAGmode> Doesn't JGoodies use XML to store its UI information? </SWAGmode> |
|
| Back to top |
|
|
Adam Sandler
Guest
|
| Posted: Tue Nov 28, 2006 11:41 pm Post subject: Re: problem with setting a panel size within a frame |
|
|
Michael Dunn wrote:
Thanks for the reply.
A couple of things... I thought GridBag was going in away in favor
FormLayout. Also, with regard to using setPreferredSize, see
http://groups.google.com/group/comp.lang.java.gui/browse_thread/thread/199fe80825ff337/0e96c1a7ea07b03b
So while your code works (thanks again!), I'm wondering what is the
root cause behind why the original code doesn't. If there's some
serious issues regarding the use of GridBag and setPreferredSize, then
perhaps another solution needs to be sought.
Thanks! |
|
| Back to top |
|
|
Jason Cavett
Guest
|
| Posted: Wed Nov 29, 2006 12:44 am Post subject: Re: Saving Windows Position/Size |
|
|
On Nov 28, 9:58 am, "Jason Cavett" <jason.cav...@gmail.com> wrote:
| Quote: | I'm writing a program in which I want to save information like window
size, window position, is it maximized, etc. I have it (mostly)
working, but I've noticed one bug that's been annoying me, and I'm not
entirely sure how to fix it.
If the application window is maximized when I leave the application, it
saves the previous size and position (before the maximization) to an
XML file.
The problem is, when I start the application the next time, it is
maximized. That's good. When I click the button to "unmaximize" it,
it doesn't always return to the original size and position (which I
have saved). Sometimes it will be placed at position -4, -4 (the upper
left corner of the screen).
The only thing I can think of is that, because I am firing two
listeners (I'm watching for component resized and component moved)
something isn't registering correctly. Here's the portion of my code
that is performing the actual resizing. (It gets called twice if I
perform a maximize because Java sees a maximization as both a resize
and a position change.)
private void maximize() {
if (view.getExtendedState() != JFrame.MAXIMIZED_BOTH
&& config.isMaximized()) {
config.setMaximized(false);
this.setLocation(config.getWindowPosition());
this.setSize(config.getWindowSize());
} else if (view.getExtendedState() == JFrame.MAXIMIZED_BOTH) {
config.setMaximized(true);
} else {
config.setWindowPosition(this.getLocation());
config.setWindowSize(this.getSize());
}
}
Any suggestions would be appreciated. If I'm doing this entirely
wrong, I'd appreciate knowing that as well. Thanks!
|
I figured out what I was doing wrong, and in case anybody was
wondering, there are two issues here.
First of all, I should not have been using the ComponentListener to
monitor state change. I didn't realize that JFrames had a
WindowStateListener. However, my code would have still worked.
The other issue I didn't realize is that, in order for a window to go
from maximized state to it's "normal" state, it had to have a previous
size and location already set for it to revert to. Unfortunately, I
was completely ignoring the fact that I needed to set it's previous
size and location when I created the view from the config file.
....it's always the stupid errors... :-p |
|
| Back to top |
|
|
Fred Kleinschmidt
Guest
|
| Posted: Wed Nov 29, 2006 12:55 am Post subject: Re: problem with setting a panel size within a frame |
|
|
"Adam Sandler" <corn29 (AT) excite (DOT) com> wrote in message
news:1164735690.470933.19080 (AT) 80g2000cwy (DOT) googlegroups.com...
| Quote: |
Michael Dunn wrote:
try this
Thanks for the reply.
A couple of things... I thought GridBag was going in away in favor
FormLayout. Also, with regard to using setPreferredSize, see
http://groups.google.com/group/comp.lang.java.gui/browse_thread/thread/199fe80825ff337/0e96c1a7ea07b03b
So while your code works (thanks again!), I'm wondering what is the
root cause behind why the original code doesn't. If there's some
serious issues regarding the use of GridBag and setPreferredSize, then
perhaps another solution needs to be sought.
Thanks!
|
The default layout manager for the content pane is a BorderLayout.
CENTERed objects will expand/contract as necessary
to fill the available space - BorderLayout ignores any positioning
or sizing information of its CENTER child.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Software Reuse Project |
|
| Back to top |
|
|
Michael Dunn
Guest
|
| Posted: Wed Nov 29, 2006 1:35 am Post subject: Re: problem with setting a panel size within a frame |
|
|
"Adam Sandler" <corn29 (AT) excite (DOT) com> wrote in message
news:1164735690.470933.19080 (AT) 80g2000cwy (DOT) googlegroups.com...
| Quote: |
Michael Dunn wrote:
try this
Thanks for the reply.
A couple of things... I thought GridBag was going in away in favor
FormLayout. Also, with regard to using setPreferredSize, see
http://groups.google.com/group/comp.lang.java.gui/browse_thread/thread/199fe80825ff337/0e96c1a7ea07b03b
So while your code works (thanks again!), I'm wondering what is the
root cause behind why the original code doesn't. If there's some
serious issues regarding the use of GridBag and setPreferredSize, then
perhaps another solution needs to be sought.
|
default layout for contentPane is borderLayout, default placement is CENTER,
and default behavior for CENTER is to occupy all remaining space after
NORTH,SOUTH,WEST,EAST are set, so
getContentPane().add(centerPanel);
means centerPanel will occupy all of the size, regardless of its preferredSize
I could have added a panel (holdingPanel) and added centerPanel to that, then
added holdingPanel to the contentPane - the effect of this would be that
holdingpanel would take up the additional space in CENTER, and
centerPanel would get its preferredSize, but centerPanel would appear at
the top center - not what you want.
GridBagLayout was used so centerPanel would be 'centered', left/right and
top/bottom. The effect would have been the same if holdingPanel was set as
a GridBagLayout, and contentPane remained as BorderLayout.
experiment, changing as described above, to see the differences (or no differences) |
|
| Back to top |
|
|
Adam Sandler
Guest
|
| Posted: Wed Nov 29, 2006 2:07 am Post subject: Re: problem with setting a panel size within a frame |
|
|
Michael Dunn wrote:
| Quote: | "Adam Sandler" <corn29 (AT) excite (DOT) com> wrote in message
news:1164735690.470933.19080 (AT) 80g2000cwy (DOT) googlegroups.com...
Michael Dunn wrote:
try this
Thanks for the reply.
A couple of things... I thought GridBag was going in away in favor
FormLayout. Also, with regard to using setPreferredSize, see
http://groups.google.com/group/comp.lang.java.gui/browse_thread/thread/199fe80825ff337/0e96c1a7ea07b03b
So while your code works (thanks again!), I'm wondering what is the
root cause behind why the original code doesn't. If there's some
serious issues regarding the use of GridBag and setPreferredSize, then
perhaps another solution needs to be sought.
default layout for contentPane is borderLayout, default placement is CENTER,
and default behavior for CENTER is to occupy all remaining space after
NORTH,SOUTH,WEST,EAST are set, so
getContentPane().add(centerPanel);
means centerPanel will occupy all of the size, regardless of its preferredSize
I could have added a panel (holdingPanel) and added centerPanel to that, then
added holdingPanel to the contentPane - the effect of this would be that
holdingpanel would take up the additional space in CENTER, and
centerPanel would get its preferredSize, but centerPanel would appear at
the top center - not what you want.
GridBagLayout was used so centerPanel would be 'centered', left/right and
top/bottom. The effect would have been the same if holdingPanel was set as
a GridBagLayout, and contentPane remained as BorderLayout.
experiment, changing as described above, to see the differences (or no differences)
|
Thanks! |
|
| Back to top |
|
|
Oliver Wong
Guest
|
| Posted: Wed Nov 29, 2006 2:52 am Post subject: Re: problem with setting a panel size within a frame |
|
|
"Adam Sandler" <corn29 (AT) excite (DOT) com> wrote in message
news:1164735690.470933.19080 (AT) 80g2000cwy (DOT) googlegroups.com...
I disagree with the claim that setPreferredSize() is evil. IMHO, that
method is not incompatible with Layout Managers (whereas something like
setSize() is).
- Oliver |
|
| Back to top |
|
|
Andrew Thompson
Guest
|
| Posted: Wed Nov 29, 2006 7:47 am Post subject: Re: problem with setting a panel size within a frame |
|
|
Oliver Wong wrote:
Babu did qualify that statement directly after that, WTE
'unless absolutely necessary'. AFAIR, the only times I
have absolutley needed to set the preferred size of
components is when I override paint()/paintComponent().
| Quote: | ...IMHO, that
method is not incompatible with Layout Managers (whereas something like
setSize() is).
|
Yes. But I still think that any case of setting the preferred
size, or setting a null layout* should be something that you
can argue exactly *why* it needs setPreferredSize().
If you cannot justify it's use, you probably *should* not
use it, and instead investigate other possible ways to get
what you want - which usually comes back to, 'fix the
current layout'.
It seems far too many people approach it the other
way around, thinking that setting the preferred size
of a component will fix a broken layout.
* Only reason I can think of is 'implementing a
custom LayoutManager'.
Andrew T. |
|
| Back to top |
|
|
Andrew Thompson
Guest
|
| Posted: Wed Nov 29, 2006 7:55 am Post subject: Re: problem with setting a panel size within a frame |
|
|
Adam Sandler wrote:
| Quote: | Hello,
I'm trying to make a GUI which looks like this:
|----------------------------|
|Please Wait... o O X |
|----------------------------|
| |
| |----------------------| |
| | | | <--- centerPanel
| |----------------------| |
| |
|----------------------------|
|____________________________|
|
|
frame
.....
The problem is that centerPanel is taking on the same dimensions as the
frame.
|
This post is a follow on to my post to Oliver.
Please read it first.
In this situation, I would ask..
"So what is going to go *inside* centerPanel,
and why is it not logical for centerPanel to be
the exact preferredSize of its *contents*?"
As a wider question, is this 'Please Wait' message
more suited to a JProgressBar in a floating
JDialog or JOptionPane?
Andrew T. |
|
| Back to top |
|
|
Adam Sandler
Guest
|
| Posted: Wed Nov 29, 2006 8:11 am Post subject: Re: problem with setting a panel size within a frame |
|
|
Andrew Thompson wrote:
| Quote: |
This post is a follow on to my post to Oliver.
Please read it first.
In this situation, I would ask..
"So what is going to go *inside* centerPanel,
and why is it not logical for centerPanel to be
the exact preferredSize of its *contents*?"
As a wider question, is this 'Please Wait' message
more suited to a JProgressBar in a floating
JDialog or JOptionPane?
Andrew T.
|
A JProgressBar is very well suited if you have a task where the
duration, or the criteria for finishing a task is known. What about
those times where the completion of a task isn't so clearly known?
I'm translating a "busybar" from a couple of other languages I work
with over to Java. So instead of building a left to right stack of
rectangles to the end of the dialog (as in JProgressBar), I have two
rectangles that bounce back and forth in "pong"-like fashion until the
thread dies. IMHO, this is better feedback for the users than simply
waiting on an hourglass cursor (again, only when the length of the task
completion is unknown); they see the application is performing an
action and they can relate to that. What I have in these other
languages is pretty elegant. I grew frustrated with seeing all the
hacked flavors of progressbars out there, rife with code smells and
bugs, and decided to emulate one instead. It involves drawing two
contrasting rectangles (and one the same color as the background to
'erase' tracks) and using some remainder division and a timer to
control the scrolling back and forth. |
|
| Back to top |
|
|
Dale King
Guest
|
| Posted: Wed Nov 29, 2006 8:11 am Post subject: Re: Are there any good Java XML UI toolkits |
|
|
J. David Boyd wrote:
| Quote: | "Chris Uppal" <chris.uppal (AT) metagnostic (DOT) REMOVE-THIS.org> writes:
Dale King wrote:
Is there any really good XML API for creating Swing UI's?
SWAGmode> Doesn't JGoodies use XML to store its UI information? </SWAGmode
|
I couldn't find anything to confirm or deny that.
--
Dale King |
|
| Back to top |
|
|
Dale King
Guest
|
| Posted: Wed Nov 29, 2006 8:11 am Post subject: Re: Are there any good Java XML UI toolkits |
|
|
Chris Uppal wrote:
| Quote: | Dale King wrote:
Is there any really good XML API for creating Swing UI's?
I can't help with suggestions for what already exists, but the thought strikes
me: how hard would it be to do yourself ? Since (as I understand it) you are
not looking for any kind of abstraction away from Swing, but rather the ability
to specify Swing GUIs in XML instead of boilerplate Java code, it seems that a
table-driven approach would be quite powerful. Your hand-written Java code
(for interpreting the XML) would be table driven, mapping XML tags/attributes
into Swing constructions via either reflection or some sort of factory; and the
tables would be generated (off-line) by reflection on the Swing classes.
YAGNI, of course, is your friend in any such project 
|
Oh, this is definitely not driven by real need. I already have the UI
specified mostly in code.
I am kind of using this particular project as an experiment in terms of
investigating the best ways of doing things both for my learning and to
serve as example code. So I am very much over-engineering this. For
example, in one part of the code I am taking the MVC notion to the
extreme as learning exercise in what code should look like. I am also
being very emphatic that the code supports localization even though the
code will likely never be localized.
So YAGNI is not an issue for me here. I am not trying to do the simplest
thing that works. I am trying to investigate the most elegant, best
design that works.
I had rolled my own scheme for creating and localizing menus and
toolbars specifying the structure using Properties files. But that's all
that it supported and was not very satisfying. I've read about using XML
for specifying GUIs and there was a lot of buzz about it, but it seems
to me to mostly be hype and in the end they all seem to fall short. I
was hoping that I was just missing something.
--
Dale King |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
