Posts by JamesCherrill

When you pass an array as a parameter you just use its name, you do not append a []

Yes, if we're discussing the try/catch, then with Java 7 or later you should be using a "try with reources" as being by far the easiest and safest way to ensure your streams are closed correctly under any/all circumstances, including when an exception is thrown. (And if you're not using Java 7 then you should be!)

try ( FileWriter foStream = new FileWriter("file1.txt");
      BufferedWriter out = new BufferedWriter(fostream)
) {
   out.write("gfgdgfdfg"); 
}
catch(Exception e){
   e.printStackTrace();
}

http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

You are confusing variables and objects. Variables just contain references (pointers) to an object. You create new FileWriter and BufferedWriter objects each time. Because you only use one at a time it's perfectly OK to re-use the same variables to refer to those objects.

If it's OK now please mark this solved for our knowledge base

javac is part of the development kit, the JDK. It's not in the JRE,that's just the runtime environment.
Download the JDK - version 7 is the current major version

You have two parts to this task.
The second part is to create and start a new Thread to execute your code, but that requires a run() method (see the Thread API doc for examples etc).
So, the first part is to extract the relevant code from its current place and restructure (refactor) it so it can be called from the Thread's run() method. In its simplest form this could just be to cut that code and paste it into a run method. You'll have to messs about with your existing variables a bit to make them accessible in the run method. With a bit more work you can make it a lot tidier by refactoring the existing code into one or more methods with the appropriate values being passed in as parameters, and have a simple run() that just calls those methods. Best of all, you may even want to have a new class (extending Thread or Runnnable) to perform the function, so you create a new instance passing the values to the constructor, then just execute that in a new Thread. (This will all make more sense when you have read the API doc for Thread).

... this link is a good intro
http://www.javaprogrammingforums.com/java-programming-tutorials/7321-how-use-observer-pattern.html

It's called the "Observer" pattern - sorry, no time to explain right now, but Google it for lots of examples etc.

Button at the bottom left of this screen labelled "Mark Question Solved"

That code looks OK. You start two threads, you expect two printlns.

Callling run executes those methods on the current thread. You need the Thread class and its start method.

Simply pass a reference to the JTable as a parameter to the constructor of your editor class, and keep a copy of that as an instance variable. Then you can access the methods of that JTable whenever you want.

just use getValueAt(int row, int column) (Returns the cell value at row and column.) to get the necessary values for the other cells and compute the total(s) to see if the value being edited is acceptable

You respond to one cell, yes, but in that code you can still get the values of any other cells to peorform you validation.

You should be able to do that by creating your own TableCellEditor - Google for lots of examples

It's not painting because you don't call its paint method. (You create a new Player on line 18, but you never do anything with it).

From the code fragment you have posted it's hard to see what value the Player class is bringing to this program. The map has the position of the player, so why not just paint a green rectangle in Level::paint?

Yup, there's no diifculty understanding what the output should look like. This isn't a difficult program, and it looks like you have it nearly right - the obvious problem being that you still have 3 loops where you only need 2.
The problem is that you are not helping us to help you fix your code! You say "... not coming quite as i want them", and post some out-of-date and unreadable code. How is anyone supposed to help you with that?

There are plenty of people here who will help, but here's what you have to do first:
1. Post a complete, correctly indented listing of the current version of your code with all the {} corrected.
2. Post a sample of the output that code produces so we can see how that differs from what it should be.

I'm not going to waste my time trying to understand code that is incorrectly indented and has inconsistent use of {}. But after a quick scan you seem to have 3 nested loops where you only need two (row and col).

Excellent! Please mark this "solved" for our knowledge base.
Cheers
J

Are you sure your arrays are initialised? Just declaring them isn't enough...

char[] outPass;  // declares a reference variable of type char[]. Its initial value is null;
// any attempt to use outPass will give a null pointer exception
outPass = new char[99]; // creates a char array, and sets var to refer to it.
// can now use outChar

println always adds a new line at the end of whatever you are printing. If you don't want every print on its own line just use print, or printf if you want more control over formatting.

ps your lack of indentation, and random use/non use of {} for single-line ifs makes your code almost unreadable. If you need to post again please indent correctly and use {} consistently for all if statements.

The idea is to ensure that you always get a valid completely initialised object - you keep calling the setters in the builder until your object is fully specified, then, and only then, you call build() and that returns a complete valid object (or throws some kind of "incomplete or invalid" exception).
If you just create a new object then call its setters you cannot guarantee that the object will be complete and valid, or maybe there's exact subclass you need to create depending on the supplied values.

The reason the builder's setters return the builder object is so you can chain calls, as in
myObject = new Builder().setThing(value1).setOther(value2).setAnother(value3).build();

I think I was too casual in the language of my post. I should have said something more like "subclass or replace the component in JTable that is responsible for painting the headers"
... but then I came to Java from SmallTalk, and am a big fan of appropriate subclassing. (Not everybody agrees, but this isn't the place to debate it.)

The "proper" way to do it is probably to subclass JTable and override the method that implements the UI for the table header. There are a few discussions about that on the web. It looks pretty difficult to me.

In my opinion while you should always strive to do the best, real life constrains you, and sometimes a quick fix is the most appropriate thing to do.
In this case for example, if the exercise is all about UI then you need to do it properly, but if it's an exercise in database mananagement then spending a too much time on prettyfying the UI is probably a mistake...

"ABC" is NOT a value stored in s. This is where you are going wrong.
"ABC" is a value stored somwhere in the Java VM's heap memory. The "value" stored in s is a reference (you can think of it as a pointer if you like) to the place where "ABC" is stored. The reference value in s can be changed at any time, but the "ABC" value in teh heap cannot be changed.

You are confusing objects with reference variables. When you say
String s = "ABC";
"ABC" is an immutable String object, and s is a (not immutable) reference to a String. The current value of s is a reference to the "ABC" object.
s = s + "DEF";
You now have 3 String objects, "ABC", "DEF", and "ABCDEF", all immutable. The reference variable s has been updated to refer to the "ABCDEF" object.

I have to say that mKorbel is not always easy to understand, but he is usually right, and he is making some very valid points here.
The code I posted was an example of how you could fudge or fake a quick solution for a simple case, but that's all. I certainly don't recommend it as a general approach. It's up to you to decide whether your current requirement can be met with a quick fudge or whether it needs a properly engineered solution.

I want the whole thing to be centered In the Middle of the frame

When I run my code the whole thing is centered in the frame (?)
If you want to use it in a frame with other components then you would need to put my three components in a JPanel then put that JPanel with your other components in the main JFrame.

Not sure what rules you are referring to... "A display area for a short text string or an image, or both. A label does not react to input events."
But anyway, I chose JLabel because it comes with font/text attributes that make it easy to implement some control of formatting of the headings, and sets its height appropriately, but otherwize, yes, a JPanel would be a sensible choice.

Here's a simple way to do it provided you don't want to get too clever...
It just adds a JLabel across the top of the whole table, and paints the top-level headings into that JLabel at the right places - which it gets from the table's column model. By listening for column resizes it also adjusts to match the new column widths.
The following runnable proof of concept shows the idea... feel free to criticise!

import java.awt.Graphics;
import java.awt.GridBagConstraints;
import static java.awt.GridBagConstraints.*;
import java.awt.GridBagLayout;
import java.awt.Insets;
import javax.swing.*;
import javax.swing.event.*;
import javax.swing.table.*;

public class TableWithHeadings {

   public static void main(String... args) {
      new TableWithHeadings();
   }

   TableWithHeadings() {
      JFrame frame = new JFrame("Demo");
      JTable table = demoTable();

      frame.setLayout(new GridBagLayout());
      frame.add(new HeadingsLabel(table), new GridBagConstraints(0, RELATIVE, 1, 1, 0.0, 0.0,
              NORTHWEST, HORIZONTAL, new Insets(0, 0, 0, 0), 0, 0));
      frame.add(table.getTableHeader(), new GridBagConstraints(0, RELATIVE, 1, 1, 0.0, 0.0,
              NORTHWEST, HORIZONTAL, new Insets(0, 0, 0, 0), 0, 0));
      frame.add(table, new GridBagConstraints(0, RELATIVE, 1, 1, 0.0, 0.0,
              NORTHWEST, HORIZONTAL, new Insets(0, 0, 0, 0), 0, 0));

      frame.pack();
      frame.setLocationRelativeTo(null);
      frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
      frame.setVisible(true);
   }

   JTable demoTable() {
      String[] headings = {"A", "B", "C", "D"};
      String[][] data = {{"1", "2", "3", "4"}, {"5", "6", "7", "8"}};
      JTable table = new JTable(data, headings);
      table.setAutoResizeMode(JTable.AUTO_RESIZE_ALL_COLUMNS);
      return table;
   }

   class HeadingsLabel extends JLabel {

      JTable table;
      DefaultTableColumnModel colModel;

      String heading1 = "Heading 1";
      String heading2 = "Heading 2";
      int colsForHeading1 = 2; // how many cols to span

      HeadingsLabel(JTable table) {
         super(" ");
         this.table = table;
         colModel = (DefaultTableColumnModel) table.getColumnModel(); …

I recommend that you avoid java.awt.GridBagLayout

Just for balance - most of my Java work is GUI-centric, and GridBagLayout is the only layout manager I use for anything other than trivial cases. It's the only one that gives me enough control over what happens when the systen font is different or the window is resized. In my opinion it's well worth the effort to learn to use it.

Yes yes! YES. That's exactly the "Observable" pattern that I recommended earlier. It's how the Java API handles re-painting windows when required, responding to keystrokes or mouse events, everything. Java maintains its own event queue, but it dispatches the events by calling registered "listeners" ("callbacks") for each type of event. It's a way that any experienced Java programmer would do this.

You define an interface (one or mode method signatures) for passing network events. Your GUI implements that interface, and registers itself as a listener on thr network handler. When a network event happens, the network handler calls all the registered listeners, passing the relevant data.

You could push your messages onto a LinkedBlockingQueue from one thread, and loop processing them in another (take from the queue blocks if the queue is empty)
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/LinkedBlockingQueue.html
(but I agree with jwenting)

ps: Looking at the 8 ways in your link, it's number 4 ("Observable") that The Java GUI API uses for cases like this.

OK, thanks for explaining that.
In that case I would say the logic looks reasonable once you fix the names and capitalisation.

Obviously you haven't compiled this code, let alone tested it.
Before you ask people to spend time looking at it, take the time to compile it and fix all the compiler errors that you can. If you can fix them all (which yu should be able to do) the write a really simple main method that tests you code with a simple test case.
Take that process as far as you can, then when you get stuck come back here for help.

To help you get started with the compile...
1. Java is case-sensitive. Queue and queue are not the same. By convention class names are captialised, variables and methods are not.
2. Read the API documentation for Queue to find the correct names for its methods

OK, I've got other things to do. Maybe someone else will help you.

Yes, you already said that.
last chance: What exactly is your problem/question? We have no idea what you already know/do not know. Do you need help defining a method, writing an action listener, creating a Virus instance? Did you write the code you posted?

What date do you want to display?

ps: Date (capital D) is the name of a class. date (small d) is a variable. Check your capitalisation.

chars are unsigned 16 bit numbers, so values 0-255 are no problem. Use them just like any other integer type.
But is that really what you need? The fact that you create your byte[] with hex values seems to suggest that the numeric equivalent isn't what it's about. When you put 0xC8 into a byte, it really does hold the value 0xC8.
Maybe giving a bit more background will held you get the most appropriate answer.

What exactly is you problem/question?

and what exactly is the error that it is showing?

Java byte variables are signed, so they are in the range -128 to +127, hence -56 rather than +200

What exactly is you problem/question?

I tried to use only one method, it makes more sense doesn't it? but it was a bit difficult to find a way to say to the method, if it's a row then print 'Row and press enter or type exit to leave the program' and if it's a column print 'Col and ...

Yes you're right, one method would make more sense. Once you spot duplucated code like that your first instinct is to generalise it. You could generalise what you have quite a lot like this, for example:

int getValidatedInt(String name, int min, int max, Scanner in) {
     print "Please enter value for " + name;
     ...
     validate input is an integer 
     ...
     if (num < min || num > max) print "enter a value for " + name + " between "+ min + " and " + max
     ...

Then call it like

int row = getValidatedInt("row", 1, 3, input);

That does make sense, but only because it's one very specific case. The langauge/compiler have to be designed for all the other more complicated cases.
Suppose, for example, that you wrote and compiled the class with the validation methods and put that in a jar and added it to your classpath. Then, later, you wrote the class that calls that method. When the compiler was compiling the method your Scanner variable didn't exist, you hadn't even started that code yet.
ps It's also misleading to think of the Scanner variable as being used in the validation method. It's not. Java calls by value, so it's a copy of the value of that variable that is created for the validation method.

Excellent!

ps: The rule for imports is that if you want to say "Scanner" rather than "java.util.Scanner" anywhere then you need the import at the head of that file. The reason is more obvious for cases where the name is ambiguous, eg Timer. If you say
void myMethod(Timer t) {...
is that a java.util.Timer or a javax.swing.Timer? The fact that you happened to declare a java.util.Timer in some other file doesn't help.

You need the import statement in every file where you refer to the class.
ps You have two class to getRowNumber - pesumably one should be getColNumber?

Sorry yes, typo, "import" not "include"
(A good example of why not to use an IDE - I can't remember the last time I actually typed an import myself)

You can pass anything as a parameter, including a Scanner. That looks like a good thing to do here. Your error message is a bit of a mystery to me.
Have you declared a variable or method called Scanner anywhere? Did you put the method declaration somewhere it shouldn't be? Do you have the necessary include statement for Scanner at the start of that file? Have you tried
public int getRowNumber( java.util.Scanner scanner ){ ...

Almost. The syntax allows for a list of expressions in each part of the for, so for(i=0,ii=result.length;i<ii;i++) is OK. See Java Language Spec section 14.14
It's probably written that way to avoid re-evaluating result.length on each pass of the loop in a (mistaken?) attempt to optimise execution speed.
But your code has a 1 instead of an i, resulting in 1=0, which is invalid syntax.

Nothing you can do will ever turn a String into an int. Integer.parseInt(s) returns a new int value that you have to assign to a variable.
ps: Please do run your code thorugh the compiler if possible before posting it, otherwize people may spend a lot of time manually finding an error that the compiler would have diagnosed instamtly.