Thomas Kiersted

Yes, the document listeners are definitely not being removed - they have visible effects on the GUI that are still occur even after their supposed removal. TextBoxes only appears empty as I didn't actually post the entire (partially) abstract class this code is from.

But does it look like I'm going about this in a sensible manner? Right now all the logging statements indicate my listeners should be gone, but going by the GUI they clearly are not removed. I guess I'll take it for a go through the debugger - better than nothing.

There will be some decrease in execution time. But unless you are using your vectors quite heavily, it is unlikely that you will be able to notice the difference. Even if the vectors are by far the bottleneck of your code, expect modest gains - it wouldn't halve your execution time even if the only thing you do is modify Vectors.

I thought this was pretty straightforward with the removeDocumentListener method, but unfortunately, it is not removing my document listeners. I have tried two approaches. I have a class that I'll call MyDocumentListener, which implements DocumentListener, and is used in this code. There is a situation in my program where I want to remove document listeners. Here is my first approach to remove them:

protected void addMyDocumentListener(JTextField txt, Object... arguments) { initializeTextBox(txt); //adds this text box to the ArrayList textBoxes (below) if it is not already there txt.getDocument().addDocumentListener(new MyDocumentListener(txt, arguments...)); } protected void clearMyDocumentListeners() { if (textBoxes == null) //textBoxes is an ArrayList of all JTextFields which have MyDocumentListeners attached to them textBoxes = new ArrayList<JTextField>(); for (int h = 0; h < textBoxes.size(); h++) { javax.swing.event.DocumentListener[]list; list = ((javax.swing.text.AbstractDocument)(textBoxes.get(h).getDocument())).getDocumentListeners(); for (int i = 0; i < list.length; i++) { if (list[i] instanceof MyDocumentListener) { if (logger.isDebugEnabled()) logger.debug("removing a document listener"); textBoxes.get(h).getDocument().removeDocumentListener(list[i]); } } } }

I figured this would suffice to go through all the DocumentListeners attached to each JTextField, and remove all those that were MyDocumentListeners. Unfortunately, that is proving not to be the case.

So I tried a second approach:

protected void addMyDocumentListener(JTextField txt, Object... arguments) { if (myDocListenersMap == null) myDocListenersMap = new HashMap<MyDocumentListener, JTextField>(); MyDocumentListener newListener = new MyDocumentListener(txt, arguments); myDocListenersMap.put(newListener, txt); txt.getDocument().addDocumentListener(newListener); } protected void clearMyDocumentListeners() { //myDocListenersMap is a Map<MyDocumentListener, JTextField> that contains all MyDocumentListeners if (myDocListenersMap != null) { Set set = myDocListenersMap.entrySet(); Iterator it = set.iterator(); while (it.hasNext()) { Map.Entry e = (Map.Entry)it.next(); JTextField txt = (JTextField)e.getValue(); if (logger.isDebugEnabled()) logger.debug("About to remove a document listener"); txt.getDocument().removeDocumentListener((MyDocumentListener)e.getKey()); it.remove(); } logger.debug(badValDocListeners.size() + " bad val doc listeners remain"); } }

Here I figured I'd iterate through all the MyDocumentListeners, and remove them from whichever JTextField they were attached to as I encountered them. I added them to the map as they were created, and the final debug statement does confirm that my map no longer contains any document listeners.

But in both cases, the MyDocumentListeners are still processing events and reacting to them. My attempts to cut them off from the flow of events have been in vain. Thus, rather than continue to as further attempts to solve this fail, I thought I'd ask here: how, exactly, do I remove a document listener?

D. Ogranos wrote:If you don't specify an absolute path then the file is searched in the current directory. Example, if your .jar file is located in testdir1/testdir2, and you run java from testdir1 as current dir, then the file won't be found. If you "cd" to testdir2, and then run the program, the file will be found.

As a solution, you could try to put the location of the file into an environment variable, and access that with System.getenv(). Perhaps there are better solutions tho.

You're right... it does default to whatever directory the .jar is in. Turns out my program was loading the config file correctly when I didn't specify a directory, and the problem was in the config file itself - I specified the path I wanted to use after loading the config file in quotes, and Java tried to change to that directory with quotes .

Question though, would not using an environment variable significantly increase the risk of decreased portabiliity? At least half the reason I'm using Java is the design-anywhere-debug-everywhere paradigm not being too bad, so I'm trying to avoid operations that might increase that problem.

So I'm not sure quite where to put this, so I chose general. But the gist of my problem is, I have a program that I package in a JAR file, and I want to be able to access a configuration .ini file outside of the JAR file - so the user can configure it themselves easily. But I can't get the relative paths working to access the .ini file.

My .jar file is and the associated directory is structured like this, according to 7Zip:

config.ini
MyProgram.jar
--Main.class
--Main$1.class
--Main$2.class
--Main$3.class
--Main$4.class
--Main$5.class
--53OtherClasses.class
--META-INF (directory)
----MANIFEST.MF

The Manifest contains:

Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.1 Created-By: 14.3-b01 (Sun Microsystems Inc.) Main-Class: Main Class-Path: lib/AbsoluteLayout.jar lib/swing-layout-1.0.3.jar X-COMMENT: Main-Class will be added automatically by build

I want to access config.ini from Main.class. In my source code, I've tried File config = new File("config.ini"); and File config = new File("../config.ini");, but both fail on my if (file.exists()) check. The only thing I can figure is that perhaps I need something else in my Class-Path? Such as the config.ini file itself? But then would File config = new File("config.ini"); work?

Currently testing on Windows, but I want it to run on any OS, so I'd rather use / than \. And when I specify an absolute path, / works, even on Windows. But I can't very well specify an absolute path and expect everyone to have the same file structure, especially as they're unlikely to all be running Windows. Thanks in advance for the help.

santhosh varala kumar wrote:It varies with system. basically it is system look and feel.

Basically we should UImanager tosetup as to use either systemlook& feel or cross platform look and fool.

If we want same font on all over platforms, the we need to explicitly use to set the font for the components. so the component should same font irrespective of the platform.

Thanks! I ended up adding a dialog asking the user (me right now) which font to use prior to having my regular GUI initialize, so that all components would use the font the user selected. That proved to be the key thing I needed, as that made testing considerably easier. It turns out most of the fonts render nearly identical on XP and Mac, and with a list of common fonts on both OS'es, I was able to test a number of them and come up with a couple (Tahoma and Trebuchet MS) that looked good on both platforms, so I can now default to those and ask the user only if neither font is present. I've yet to find an excellent default one for Linux, but it shouldn't be too difficult now.

Ulf Dittmer wrote:You shouldn't expect Swing GUIs to be identical pixel-by-pixel across platforms. That means using absolute sizes (in pixels) doesn't work. But if you call "pack()" after layout the components, then none should be invisible, provided the top-level container is large enough.

I have a call on pack(). I suppose this means, though, that it isn't possible to guarantee that the top-level container will fit on a 1024x768 screen? I'd like to be able to guarantee minimum requirements.

Is there some sort of way to have near-equivalency between fonts between platforms? That's really the issue here - the Metal LAF is close enough to identical that it works, it's just the font throwing everything off. I've read a little bit about a way to specify small fonts in a .plist file that will make Mac fonts smaller, but that's the only shot in the dark I have right now, other than randomly trying fonts. If there's any way to choose some sort of cross-platform-friendly font, that would be great.

The alternative of developing a separate version for Mac/Linux and Windows isn't very appealing - I chose Java in part because it was supposed to be good cross-platform. And while it's still a bit better since Linux and Mac appear to be the same in appearance, it's not proving as cross-platform friendly as I'd hoped.

The invisibility problem is just that the larger font pushes every element of the pane I am using farther right, which pushes the ones on the right end off the panel, using Group Layout. The best alternative I've found is Absolute Layout, which at least ensures nothing will fall off the screen (at the expense of a bit of overlap). Needless to say, it isn't ideal given the font size issue, either.

I've been programming what I hope to be a cross-platform Swing application on Windows XP, and when testing on Mac/Linux, I've noticed that the GUI doesn't quite line up, regardless of layout, and despite using the same Metal look and feel on all platforms. The crux of the problem is that the fonts on Mac/Linux take up more horizontal space by approximately 10%, pushing everything further over, and causing my components to run off the edge of the window (as well as causing visibility problems in some panels).

So my suspicion is that the default font for Java is different on Windows than on Mac/Linux. However, I'm not sure quite how to fix this problem. According to NetBeans, the font I'm using is called "Dialog". Does anyone know a way to get the same font width on Mac as Windows?

I've been trying to design a GUI program with NetBeans, but the stupid IDE keeps resizing all my objects when I change the size of a single one of them. I'll change the size of a combo box or even label within a pane and it'll go and move around and resize every single pane on the entire form. It's to the point where I can't even try putting things in a slightly different position for fear of NetBeans rearranging things and it taking 10 minutes to get everything back to how it was - either that or I'll have to save after each and every single change (a bit more tedious than I'd like).

So, is there any way to tell NetBeans to NOT move something and have it listen? The GUI builder is pretty much useless for anything complicated with it moving things around willy-nilly all the time. Or, failing that, is there another Java GUI builder around somewhere, preferably one that could read what I already have? I'd really like to make some cross-platform GUI Java apps, but this behavior from NetBeans is unacceptable. Makes me want to go back to good ol' Visual Basic 4 where GUI elements actually stayed where you put them.

I realize the resizing is supposed to be so it looks better across systems, but if you can't design it in the first place, what's the point? And as I'm planning to set the Metal style for my program everywhere, I'd rather have absolute positioning and have it not be a nightmare to make the GUI. Sure it might not look perfect on every OS, but if it's that bad to get the GUI to stick I might just not program it at all.

Maneesh Godbole wrote:Moving to a more appropriate forum.

Thanks. Sorry about that, didn't even spot this forum.

And I did end up finding the answer. Google hadn't been helping, but AltaVista actually was very effective.

Per the title - I can preview my projects in Metal, Nimbus, CDE/Motif, Windows, and Windows Classic, but I have to design my project with the Windows look and feel. Since I want it to be cross-platform (and most Java's default to Metal anyways), is there a way I can set Project Matisse (the GUI builder) to let me design my project with the Metal look and feel? I've read how to get NetBeans to use a different layout, but everything I read says that changes NetBeans itself, but not the GUI builder therein.

On a related note, is there a way to disable the snap-to-edges-or-other-objects feature for certain objects? It's certainly useful at times, but other times it makes it very frusterating to try to build a truly free-form project.

Thanks! I found the String constructor you're referring to in the Javadocs, and it seems to be doing the trick, along with ISO 8859-1. Only other issue I've run into is Big Endian/Little Endian integers (my file uses Little Endian, Java defaults to Big Endian), and Integer.reverseBytes(int) appears to have solved that issue.

Great job knowing just what I needed!

I usually use Scanner for inputting from files, but now I'm trying to input a from a non-Java optimized file that contains both fixed-length strings (effectively char arrays, of varying lengths), and 32-bit integers. There is a specified format for this, but the integers and strings are interspersed. For example, this might be an input file:

book meow 8490 strawberry 2239 boom

Supposing that book, meow, and boom were four-letter char arrays and strawberry was a ten-letter char array. I know what the format is ahead of time, so I can program it so it anticipates when a 4-char array/10-char array/32-bit integer/etc. is coming. The problem I've run into is, I don't know of a Java input method that will handle both fixed-length strings and integers. It seems like there ought to be one, but if there is, I haven't encountered it.

Scanner is my default, but I don't see any way to input fixed-length strings with it. As there's no Java-specific formatting in my input files, next() and nextLine() aren't adequate.

BufferedReader does what I need for the fixed-length strings, but I just get



(squares) when I try to input integers with it. Adding a StreamTokenizer to it doesn't help at all with the integers, and tokenizes the fixed-length strings incorrectly.

FileInputStream didn't seem to be doing anything correctly, and didn't work well at all for the fixed-length strings, giving me such nonsense as [B@45a877.

So far the best I've got is:

char[] length4String; //length 4 char[] thirtyTwoBitInt; length4String = new char[4]; thirtyTwoBitInt = new char[4]; fileName = JOptionPane.showInputDialog("Enter filename"); File file = new File(fileName); BufferedReader in = new BufferedReader(new FileReader(file)); in.read(length4String, 0, 4); System.out.println(length4String); //works System.out.println(); in.read(length4String, 0, 4); System.out.println(length4String); //works System.out.println(); in.read(thirtyTwoBitInt, 0, 4); System.out.println(thirtyTwoBitInt); //prints out boxes

It doesn't work if I try making thirtyTwoBitInt a Byte or an int, either - BufferedReader can only read in fixed-length char arrays, not fixed-length integers.

So what is the class that I'm looking for that will let me input both fixed-length strings and 32-bit Integers, as I specify? I figure there has to be some such class out there, but I'm not finding it.

edit: Tried DataInputStream, too, but its method to input characters is two bytes at a time, and the characters in my file are one byte each.

Edit: Strangest thing. It seemed like no matter what I kept getting errors with my original project, but when I created a new project, followed exactly what Freddy Wong said, and copied the code over, the JAR file worked fine. The only difference I can think of is that I had the main class named Russian.java in the original and Main.java in the new one - perhaps NetBeans is persnickity about the main class actually being named Main.java. But I've got it working - so long as it keeps working I'm happy.

Thanks!

edit: Odd, when I did what Freddy Wong said with a brand-new project it seemed to work. Not sure why it didn't for my already-existant one, will have to look into it...

[SPOILER]I've got the correct class selected as the main class in NetBeans. I looked at the uncompressed JAR and the manifest looked like this:

Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Created-By: 10.0-b19 (Sun Microsystems Inc.)

I opened up project.properties in NetBeans and changed the manifest file from the default to "manifest", a file which I created. I put in it the following:

Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Created-By: 10.0-b19 (Sun Microsystems Inc.) Main-Class: russian.Russian

which does include a newline at the end. It seems to be trying to use this manifest file, but I now get an error "Could not find the main class. Program will exit." when I try to run the JAR. When I look at the uncompressed manifest from the JAR, I get

Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Created-By: 10.0-b19 (Sun Microsystems Inc.) Main-Class: russian.Russian Class-Path:

I'm guessing the Class-Path is causing the error. The aforelinked Java JAR help HTML pages, though, say that the Class-Path is used for when things in other JARs are being used as utilities. But I've only got one JAR here - I don't want to reference any others. Unless I need to reference the javax.swing and other libraries I use? But I can't believe that would be the case - if so I'd have to know where all their JARs are.

The other possibility is that it's just not finding the file for some odd reason. The decompressed JAR's directory structure is like this:

Russian (root of uncompressed JAR)
>>>>>>META-INF (dir)
>>>>>>>>>>>>>>>MANIFEST.MF
>>>>>>russian (dir)
>>>>>>>>>>>>>>>Russian.class
>>>>>>>>>>>>>>>RussianGUI.class

I think I've got the right Main-Class syntax here, not sure why it wouldn't be finding it like it claims. But I never did understand these manifest/jar things very well, so it's possible.[/SPOILER]

[ October 24, 2008: Message edited by: Thomas Kiersted ]

[ October 24, 2008: Message edited by: Thomas Kiersted ]
[ October 24, 2008: Message edited by: Thomas Kiersted ]

I've been attempting to create a JAR from netbeans following this example. Unfortunately, whenever I try to run the JAR, I get an error "Failed to load Main-Class manifest attribute from [JAR name]" Is there any simple way to get around this in NetBeans - trying to avoid the problem from the command line was so exasperating I eventually gave up, but it seems like it shouldn't be quite so difficult in NetBeans. Right now I'm just compiling to .java in the command line when I want to run a program outside of NetBeans, but I'd like to be able to get a JAR.

Relevant info:
NB Version: 6
File name is not Main.class - not sure if that causes the problem.
OS: XP SP3

I did Google it a bit but couldn't find any straightforward answer on it and hadn't found any in extensive searching that solved my command-line JAR problems, so I thought asking here might be more efficient. I guess that's just what comes from starting with VB and getting used to everything working right away without tweaks (including created .exe's). But Java does allow me to do a wider range of things, so for this program, Java it is.