getSystemClipboard != system clipboard

2001-04-15 Thread Dick Repasky


Why doesn't a call to getSystemClipboard give me what's in the
system clipboard?  Briefly, I'm working under Linux using X
windows.  I load something into the system clipboard from an
xterm using the left mouse button.  Then, when I move into my
application and click on a home-grown paste button that
uses the getSystemClipboard call, I get nothing.  Ironically,
X11 copy and paste operations that rely solely on the left and
middle mouse buttons work fine.  I can also copy into the system
clipboard using the mouse in an xterm and then paste directly
into an editable TextArea just fine.

I'm coming to the conclusion that what java thinks is the system
clipboard isn't that at all.

What I'd like is a nice unified cut/copy/paste system.  That is,
I'd like to cut/copy/paste within an editable TextArea as
well as to cut/copy/paste between the text area and other
applications in Linux and Windows 98, using the mouse buttons
and/or cut/copy/paste buttons that are home-grown MenuItems,
complete with ctrl-x,c,v shortcuts.

So, if Java's system clipboard isn't really the system clip
board, what is it?

Thanks,

Dick


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Rules for names of text encoding schemes?

2001-07-29 Thread Dick Repasky

Subject: Rules for names of text encoding schemes?

Hi,

I'm working with text encoding and retrieved a list of encoding
schemes from Sun's web site.  While all of the names that I
retrieve work, meaning that I can instantiate either an
OutputStreamWriter or an InputStreamWriter with them, the name
of the default encoding scheme on my system that is returned
by System.getProperty("file.encoding") differs from that on
Sun's list.  The system call returns "ISO-8859-1" whereas the
name on the list is "ISO8859_1".  The difference makes life
tough for me, and there are two things that might solve the
problem.

1) Is there a standard naming scheme that all JVM's use to
   return names of encoding schemes? 

   Under this option, I just need to change everything from Sun's
   page to conform to the standard.

2) Is there a standard pattern that names must match to be
   acceptable? For example, are all dashes optional or
   representable by underscores?

   Under this option, I can do some parsing of names to come up
   with least common denominators.


Thanks,

Dick








--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




ugly html rendering by JEditorPane

2001-08-05 Thread Dick Repasky


Wow, html rendered by JEditorPane looks nothing like the nice looking figure in
Niemeyer and Knudsen's book "Learning Java" (O'Reilly).  Gaps between letters
within words are as large as gaps between words.  I've built the JEditorPane using
defaults, and my runtime environment is Blackdown j2sdk1.3.0.  Before I start trying
things, has anyone already figured out what it takes to render respectable html?

Thanks,

Dick



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




isHTMLDocumentEmpty()

2001-08-25 Thread Dick Repasky


Hi,

I need to determine whether a document lacks content. The doc may have
body and paragraph tags but be empty.  I've tried and failed, so I
have 2 questions.

1) Is there an obvious way to do this that I'm overlooking?

2) Is my strategy OK?  Here is what I've tried.
   - Get an HTMLDocument.Iterator for tag type HTML.Tag.CONTENT, from
 the Document returned by JEditorPane's getDocument method 
 (inherited from JTextComponent),
   - Iterate through the tags using their getString methods to find
 text.

Here is what happens.

The first call to the iterator's isValid returns false. End of show.

If I try other Tag types, for example TD (of which there are loads in a 
test doc) or BODY (which will be there even in empty documents) the
iterator itself is null.

What am I doing wrong?

I'm using blackdown j2sdk1.3.0 on a Red Hat 7.1 system under kernel 2.4.7.

Thanks,

Dick


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




System.getProperty("file.encoding") = 646

2001-09-04 Thread Dick Repasky


I have some code that I compiled with blackdown java j2sdk1.3.0 under linux,
and when I run it on a Solaris 7 box using Sun's runtime j2re1_3_0,
the call System.getProperty("file.encoding") returns the value 646. The code is quite 
simple.  

   public class ShowMe {
public static void main(String[] argv) {
System.out.println(System.getProperty("file.encoding"));
}
   }

I do not have access or disk space to compile using Sun's SDK on the Solaris
box.  So, I'm wondering: what in the world is going on?

Thanks,

Dick


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




JDialog.setVisible(true) -> iconified

2002-05-25 Thread Dick Repasky


Hi,

I'm having difficulty with JDialog.setVisible() on Blackdown Java-Linux 
Java(TM) 2 SDK, Standard Edition Version 1.3.1  FCS and above (meaning the
latest, too).  The first time that I use the setVisible method of
a dialog it comes up fine.  After I hide it with setVisible(false),
calls to setVisible(true) make the JDialog visible but only as a closed
icon, and I must click on the icon to actually see the JDialog.  This wasn't
a problem on earlier versions of Blackdown, and I don't have the problem
using Sun's JRE on Windows or Solaris or using the latest Apple MRJ
for Mac OS X.

What's up?

Thanks,

Dick


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




window manager bug - how to report?

2005-03-02 Thread Dick Repasky
I believe that I've discovered a bug in how a window manager deals with 
JDialogs.  Briefly, if I create a JFrame and a number of JDialogs that are 
owned by it, JDialogs that are made visible before the JFrame is made
visible perform correctly in that calling their toFront methods and their
setResizable(true) methods work as they should.  JDialogs that are made 
visible after the owning JFrame has been made visisble do not perform as 
they should: calling their toFront methods does not bring them to the 
front of other windows, and calling setResizable(true) before the JDialogs
are displaye does not make them resizable. I believe that this is a 
problem with the window manager because I do not have the problem with 
Gnome, KDE or Xfce (or MS Windows - but that's not blackdown).  I do have 
the problem with fluxbox and with Mac OS X (and, that's not blackdown 
either).  I'd like to report the problem to the developers of flux box and 
Mac OS X, and I'd like to be able to say something besides Java JDialogs
don't work as they should.

Does anyone who has experience developing Java for X have an idea of 
what's wrong on the X side so that I can give the developers something 
more than JDialogs don't work as the should?  My fear is that if the 
developers don't know how java works they may not know where to look.

Thanks,
Dick
P.S.  Below is a program that demonstrates the problem.  It generates 5 
JDialogs that are owned by a JFrame.  The menu can be used to select the
JDialog that should be at the front.  It works for A and B, but not for C, 
D, and E.  Also, note that JDialogs A and B are resizable and that C, D 
and E are not.

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.JDialog;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JMenu;
import javax.swing.JMenuBar;
import javax.swing.JMenuItem;
public class JToFrontDemo extends JFrame {
JMenuthe_menu = new JMenu("MENU");
public static void main(String[] argv) {
JToFrontDemo demo = new JToFrontDemo("JToFrontDemo");
JDialog da = demo.addJDialog("Dialog A");
JDialog db = demo.addJDialog("Dialog B");
JDialog dc = demo.addJDialog("Dialog C");
JDialog dd = demo.addJDialog("Dialog D");
JDialog de = demo.addJDialog("Dialog E");
// if demo.setVisible(true) were here nothing would work!
da.setVisible(true);
db.setVisible(true);
demo.setVisible(true);
dc.setVisible(true);
dd.setVisible(true);
de.setVisible(true);
// if demo.setVisible(true) were here everything would work!
}
public JToFrontDemo(String title) {
super(title);
JMenuBar menubar = new JMenuBar();
menubar.add(the_menu);
setJMenuBar(menubar);
getContentPane().add(new JLabel("THE FRAME"));
pack();
addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent we) {
System.exit(0);
}
});
}
public JDialog addJDialog(String label) {
JDialog adialog = new JDialog(this, label);
adialog.getContentPane().add(new JLabel(label));
JMenuItem jmi = new JMenuItem(label);
jmi.addActionListener(new ML(adialog));
the_menu.add(jmi);
adialog.setLocation(100, 100);
adialog.setResizable(true);
adialog.pack();
return adialog;
}
private class ML implements ActionListener {
private JDialog the_dialog;
public ML(JDialog adialog) {
the_dialog = adialog;
}
public void actionPerformed(ActionEvent e) {
the_dialog.toFront();
}
}
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]