Posts by JamesCherrill

This is a completely different topic, and should really be in a new thread - you shouldn't just keep a handy thread open to post random questions in.

Anyway. The exception says you have a null pointer (uninitialised variable) on line 56 of BestFriendNames$addListener.actionPerformed. That line reads
names.add(name);
there are just two variables in that line, and name is initialised on the line above, Q.E.D. names is uninitialised. And a quick scan of the code confirms that. You declare names on line 24, but you never initialise it.

That's OK. Mark this "solved" please.

If you look at where the exception is being thrown you will see that its in A2's actionPerformed. That's the code that reads the file. Check around line 37 for a missing digit.

Looks pretty much like the same exception to me!
Have you looked to see if the file really there or not?

Count again - they are not both 6! (now you;ll be even more embarrassed)

I really can't think of a clearer way to explain this exception than the version you already have

WrittenText.txt (The system cannot find the file specified)

You solve it by having the same file name for the file you write and the file you read. (count the "t"s in those file names - you're gonna be so embarrassed ;))

Delay the start of playing the sound at the server until the client is ready to start playing it?

Why not go back top readLine like your earlier attempt and parse the input Stirng yourself. No harder than a Scanner, but much more under your control.

What kind of set is only important if you have biggish sets or high transaction volumes. You don't need a TreeSet unless you are orried about keeping the netries sorted.
That code looks OK to me - could be simpler...
return ((State)o).getStateName().equalsIgnoreCase(getStateName());

The API doc for HashSet shows it to be a subclass of Set, and the API doc for Set says "More formally, sets contain no pair of elements e1 and e2 such that e1.equals(e2)"

So there's your answer. The implementation uses the equals(...) method of your objects to see if they are distinct. All classes inherit an equals method from Object, which tests them for being exactly the same instance. Many classes override this (eg String tests for both Strings containing the same sequence of chars). You can override equals for your State class and return a result based on the magic char that they contain.

ps: The answer to most questions is in the API doc. If it's really obscure you can download the source code for the whole API from Oracle and see how it really works.

pps: re overriding equals...
* Note that it is generally necessary to override the {@code hashCode}
* method whenever this method is overridden, so as to maintain the
* general contract for the {@code hashCode} method, which states
* that equal objects must have equal hash codes.

In your case then simply returning the magic char should do it?

Depends on exactly what you are trying to do, but in general
Exprfield.getDocument() will give you the Document object that handles the input and editing of what you see in the text field. Once you have the Document you can insert text at the caret or do whatever else you want

If Im located there, how would I go up a directory (To "C:\Archivos de programa\MyEclipse for Spring\Common\plugins\com.genuitec.eclipse.easie.tomcat.myeclipse_9.0.0.me201109141806\tomcat" ) ?

You don't need all that manual "last index" parsing pain.
Just create a File object to the original dir then use getParent() to give you the parent (one-up) dir.
eg

File f = new File("c:/abc/def/ghi/jk");
      System.out.println(f.getParent());

prints

c:\abc\def\ghi

1. Put a load of print statements into your code, printing the values of the key variables at each stage so you cen see where it's going wrong.
2. Do you need a \n at the end of your writeToTerminal string?

you read the menu choice int from the scanner, but this leaves the newline delimiter unread. Your next read is likely to return "" - ie everything before the next newline. Flush the newline after reading the int.

That's typical of a lot of the Java API - it's a real saga to find out how to use it, but when you finally get it nailed, it turns out that the designers did know what they were doing, and the solution is really simple. If only the guys who do the documentation were as good as the people who designed the APIs!

Anyway, thanks for sharing your solution - I'm sure many people will learn from it, especially if you mark this thread "solved"

Sorry for previous terse reply - I just had a few seconds and thought it better brief than do nothing.
Anyway, more time now...
You can use any character-oriented streams - the ones you're familiar with would be an obvious choice. Here's a really good link about some problems that you 'll probably run into... and their solutions)
http://stackoverflow.com/questions/3643939/java-process-with-input-output-stream

Yes

OK, in that case I can't see how you would improve on triple-nested 0-255 loops. You may be able to squeeze some more speed by doing some of the string conversion/formatting in the outer loops, eg so you don't evaluate a + "." + i + "." + j + "." 255 times with exactly the same values...
but in reality you would have to benchmark to be sure.

You do realise thats 16 million addresses?

Yes, that can be confusing! In your java code you write data to the Output stream, and you read the results back from the Input stream. Ie "input" and "output" are as seen from the Java end of the pipes.

Google the ProcessBuilder class ...

You are just repeating yourself. I tried to help diagnose this problem but you chose to ignore that. I am wasting no more time here.

This excerpt from, the URI API doc mau help?

A hierarchical URI is either an absolute URI whose scheme-specific part begins with a slash character, or a relative URI, that is, a URI that does not specify a scheme. Some examples of hierarchical URIs are:

http://java.sun.com/j2se/1.3/
docs/guide/collections/designfaq.html#28
../../../demo/jfc/SwingSet2/src/SwingSet2.java
file:///~/calendar

Looks to me like you may need new URI("file:///c:/sss.xps")

Come on now Zaad! You have been here long enough to know that you should always include the line number when you post an error message! But presumably it's line 35/6 - is that URI valid? Does the file exist?

SasseMan is right.

The only code in your paint method should be actual painting code - roughly speaking that's just the lines that use the Graphics object g, as in super(g) or g.draw...
All the stuff about layout manager or adding components (choice, button, radio group, etc) belong in your initialisation code so they are executed just once. The easy way to do that is to implement your own public void init() method and put the code in there. It will be called automatically when your applet is loaded.

SasseMan refers to "Swing". When Java was first released (last century) it had a GUI system called AWT. When people used that they found all kinds of problems with how it was designed, so Sun had a second try and released Swing, an updated version of AWT that fixed many problems. You can tell which is which because the old AWT classes have names like Applet, Button etc, and the replacement Swing classes all have names that begin with a J, eg JApplet, JButton etc. Your code uses the old AWT classes, but in general you should always use the newer Swing classes.

What do yo mean "you tested my code?" That code was never going to fix anything. It was a diagnostic. You needed to run it and share the results.
Let me explain:
Internally Java uses 16 bit UniCode to hold chars, so accented chars are no problem. But you have input from an 8 bit cmd/file environment where there is no definitive implementation for accents. You are then displaying via fonts that may or may not implement UniCode chars outside the ASCII set.
So your problem could be when the chars are input OR when they are displayed. By printing the numeric values for your text in your program we can see whether the problem is in input or display. Once we know which it is we can progress towards fixing it.

It's your thread, so you can safely ignore my post and just display a load of code that doesn't even compile. Good luck.

First, you could check that the letters are being transferred correctly from your Runtime exec, and if so, how they have been encoded. Try printing the string with its UniCode numerical values, eg

String s = (the string you get from exec)
for (int i=0; i<s.length();i++)
 System.out.println(s.charAt(i) + " = " + (int)s.charAt(i) );

Rather than overriding paint, you;ll be on easier ground by creating a gridlayout of JLabels and using ImageIcon to place your graphics in the JLabels. (just Google it)
If you must override paint then don't re-load the images from disk every time paint is called. It can get called very frequently and all that repeated IO will grind your GUI to snails-pace. Load them all into memory once when the program starts.

there occured compilation error...

Sorry - I was illustrating how you didn't need to pass the length, but I didn't point out the logic error that was there in the first place.

OK
ps You don't need to pass the length of the array with the array - you can always query the length of any array whenever you need it with .length, as in
cipher = (int)((Math.pow(c[c.length],e)) % n);

Please mark this "solved" for the archives. Thanks.

m is the name of the array you declared, so the [] in m[] on that line is invalid syntax. To pass the array named m you just need int ct = a.getCipherText(m,l);

1. Post your code in code code tags so we can read it easily
2. If you have an error tell us what it is! - Exact complete error message(s) including the line number(s)

The regex is [.:|] (ie any of the three chars in the []) EXCEPT that . and | are special chars in regex and need to be escaped with a \ to indicate that you want to use them literally, ie [\.:\|] Next problem is that \ is a special character in Java string literals, and needs to be escaped with an extra \ you want to use it literally. This means that the Java string you need is "[\\.:\\|]"

If this is a financial application where fractions of a cent are not allowed, then the simplest and safest approach is to store the amounts in integer cents. With float or double there are always going to be rare cases where rounding gives a slightly wrong result.
If you must use double, and you want to round down to 2 dec places, then mutliply by 100, use Math.floor(...) to round it down, then divide by 100 again.

Do you just want to display the result rounded down to 2 dec places, or do you need to perform the calculation and round down that result to2 dec places before doing anything else (eg storing or printing it)

You may also hit a memory limit - I don't know how much heap one connection and its associated application objects use, but even if its only 4k bytes a million connections pushed you over 4 gig. I think you need to look at a server farm that spreads the load over many machines.

If you start the player playing in its own thread, as correctly advised by cOrRuPtG3n3t!x, then I see no reason why you can't just call ap.stop() directly from the Swing thread (eg in a button's action listener) - no need for flag variables etc. (If you can't call stop() from a thread other than the one where play() was called, then it has no possible use!)

My pleasure. Mark this thread "solved" for the archives please.

Presumably there's an ItemEvent.SELECTED and an ItemEvent.DESELECTED when the selection changes. You can query which it is via the event's getStateChange() method, then only update your text on an ItemEvent.SELECTED

I think Norm's onto something there. This is from the JComboBox API doc:

public void addItemListener(ItemListener aListener)
Adds an ItemListener.
aListener will receive one or two ItemEvents when the selected item changes.

A quick print inside the itemStateChanged method will confirm or refute this.

how can I resolve this problem please help me,I'am a biginner in java

Did you try setForeground(someColor) like I suggested?

I edited that down to the essential code to see into the zip file, and used a file input dialog to ensure the zip file path was correct. This code works for me - maybe you can try it with your zip file?

void doZip() {

      try {
         JFileChooser fileChooser = new JFileChooser();
         fileChooser.showOpenDialog(null);
         File chosen = fileChooser.getSelectedFile();

         FileInputStream fis = new FileInputStream(chosen);
         ZipInputStream zis = new ZipInputStream(new BufferedInputStream(fis));
         ZipEntry entry;
         while ((entry = zis.getNextEntry()) != null) {
            System.out.println("Found: " + entry);
         }
         zis.close();
      } catch (Exception e) {
         e.printStackTrace();
      }
   }

In theory it uses the locale of the machine where it is running - but in practice that's often US for some reason.

OK, thank you. J.

Here's a really dumb question... is it possible that the code your are executing isn't what you think - eg out-of-date .class files hanging around etc? Maybe a quick print at the start and end of execution would give positive confirmation?

Presumably, if System.out.println("Extracting: " +entry); isn't outputting anything, AND there isn't a java.io.FileNotFoundException then the input file has been found, but it doesn't contain any zipped content?

On line 8 did you put the name of a real zip file?

Ditto. Maybe you're creating something for each connection or transaction and failing to null all the references to it/them (eg adding them to a List that's not cleared).