Posts by JamesCherrill

ps The third array is just an output from this method - there's no point passing it in as an input parameter - just create it inside the method and return it.

Small confusion about index1 and index2 here. AFAIKS you don't need 3 indexes, ie
L3 = L1*l2
... but if you do then you should be incrementing them all, not just index3.

You need to parse the text from the textfield to get its integer value, Have a look at the Integer.parseInt method.

At the four places where you construct the question you can also calculate the correct answer, and save it in a variable so you can check the user's answer against that value when they press "submit".

Quick answer: call textfield2.requestFocusInWindow();
Proper answer: read this tutorial to understand how Swing manages moving the focus, and how you can control it:
http://download.oracle.com/javase/tutorial/uiswing/misc/focus.html

In your actionPerformed(ActionEvent e) method you can use e.getSource() to return the object on which the Event initially occurred.

No, not leading Q, just suggesting that you may have better things to do than worry about a slight flicker. I'm always interested in what people are up to, but I don't have remotely enough time to follow up more than a tiny fraction. Mostly its just help fix the problem, mark it solved, onto the next.
J

I've

got a temporary double array that has the same values as one of the arrays stored

No, that's completely wrong. (Beginners in Java usually hit this particular confusion sooner or later. temp is NOT an array, despite the misleading syntax. temp is a reference (a.k.a. pointer) to an array.
Your line 1 above creates a variable temp that refers to exactly the same array as names.get("Matthew") . When you update temp[i] that is exactly the same as updating names.get("Matthew")[i] . There is only one array, but there are two ways to refer to it.

Excellent! Please mark this solved so others will know.

If it doesn't bother you then that's OK. Time to move on to more important things?

OK, this is fun! The Map is the way to go.
Have a Map that maps a String name to double array. HashMap is the one to use here:

Map<String, double[]> names = new HashMap<String, double[]>();

when you need a new array just add it the map

names.put("Matthew", new double[15]); // new array with name Matthew

then you can just retrieve the one you need

double[] temp = names.get("Matthew");

or use them directly

names.get("Matthew")[0] = 12.3;

If the names are a known fixed set then you can probably do this more simply with a switch that selects the right array, or, even better, put them all in a Map with the name as key and the array as value.
Otherwize you get the Class object for your class, get the Field using getField(String name), then use get(Object o) on the field to get the object it refers to (the parameter is the instance of your class to use for instance variables). Finally cast the returned Object to the appropriate array. (But map is simpler.)

You can do access things like method or variable (reflection refers to variables as "Fields") names using the Reflection classes in java.lang.reflect
eg the Field class has a getName() that returns the name of the field.
Start with the Class class - that's where you get the Fields and Methods from.

ps: but why do you want to do this?

Yes, you need to create new Objects, one for each array element, not just references (pointers) to objects.
The only way memory allocation is going to fail is if you run out of memory in the Java VM. In that case you will get a OutOfMemoryError exception thrown, but frankly there's not a lot you can do practically at that point except let the program crash and increase the VM memory settings for the next run.

That doesn't allocate any memory for ObjectL objects - it allocates memory for an array of int a references (pointers) to possible ObjectL objects.
To allocate memory for the objects themselves you need to execute new ObjectL(...); where ... is zero or more parameters as required by ObjectL's constructor(s).

Because you defined and initialised the array numberL on line 3, it can never be null on line 5, so the test is redundant.
Note also that the array numberL was defined inside the formStyleOfLyle method, so it will go out of scope and be garbage collected as soon as you exit that method.

In summary, that whole method is equivalent to

public static int formStyleOfLyle(int a) {
   return 0;
}

What exactly do you want to achieve here?

This approach to keyboard handling is always a complete pain in the * because of precisely those focus issues.
Swing was enhanced back in Java 1.3 to provide a better way of doing things via two new classes: InputMap and ActionMap. Here's a good write-up on the theory behind it:
http://java.sun.com/products/jfc/tsc/special_report/kestrel/keybindings.html#new_bindings
and this is the tutorial:
http://download.oracle.com/javase/tutorial/uiswing/misc/keybinding.html

"flicker" is an important clue.
When you have code like pack(); setSize(800, 600); in a listener there are zero screen updates until your whole method is completed, then the screen is repainted with the final version. Swing is by default double-buffered, so no flicker. Flicker implies that there is another method somewhere else that's also changing the screen, so it goes:

your code changes the GUI as many times as it wants
your code completes
Swing updates the screen
some other code changes the GUI
... and completes
Swing updates the screen again

It's 6pm here now, so I'll have a look in the morning. Keep me updated if you get any progress at your end, please.
J

Ah - just saw that you are using a null layout managers. (It's your program, so that's up to you). That changes everything. Forget the pack(), that's for real layout managers. Sorry about that, null layout is something you just don't see in "real life" development, so I had a false hidden assumption.
On the other hand, it's simpler because I now have no idea why the size should depend on where the add method is called from. If you can let me have a stand-alone single file version I'll run it and see what I can find; otherwize I'm afraid I'm not going to be much more use to you :-(

OK, that's not going to be easy to run. It uses a package Default.Engine and also requires other stuff from /Resources/, neither of which I have.
Can you cut this down to a single file (only 1 public class, other classes not public) with no external dependencies?

Hi, I'm back. Without the code for TestPanel I'm unable to reproduce your problem here. Is it possible for you to post a complete source file that I can compile and run to reproduce the problem? It doesn't have to be your whole app, in fact the smaller the better...

Sorry, got to go out for bit now - I'll have another look at this when I get back, unless you fix it in the meantime (don't forget to mark it solved in that case). J.

You can specify a full path from the root (eg c:) to the file, check out the API doc for File. You can also get useful directories like the user's home dir or a temp directory from System.getProperty, eg System.getProperty("user.home") and use that to locate a file.

Like I said:
When you add stuff to a window you need to call pack() after adding everything.
so yes, after you add your panel in the mouse event you need to call pack()

When you add stuff to a window you need to call pack() after adding everything.

public void pack()

Causes this Window to be sized to fit the preferred size and layouts of its subcomponents. The resulting width and height of the window are automatically enlarged if either of dimensions is less than the minimum size as specified by the previous call to the setMinimumSize method.

If the window and/or its owner are not displayable yet, both of them are made displayable before calculating the preferred size. The Window is validated after its size is being calculated.

If you want the window to start out big enough to show a panel that you will add later you can either use setMinimumSize or use a place-holder component of the right size.

This is all part of the sometimes painful magic of layout managers. They're great and essential when you get control of them, but at first they seem totally out of control and prone to random behaviour.

Do you have a pack(); somewhere in your code. Do you call pack(); after adding the new panel?

OK, so the maze class has a "template" maze that the Robot can change, but if a second robot is started it will have the original maze, not the changed one? In that case yes, you need a copy, not just a shared reference to the same maze. You can get clever with the arrays class, but it's probably easier create a new array of the same size, and use a simple nested loop to copy the contents from the original array to the copy array.
Something like:

String[][] getNewMaze() {
   create new String[][] same size as maze
   copy all the data from maze to the new array
   return to new Array
}

If you have the image, and are drawing it in a paintComponent method, then you can cast the Graphics g parameter to Graphics2D and use its rotate method. (which is an easier cover method for a rotational AffineTransform)

Encryption: there's no reason to go further than the API classes that are included with every Java installation.
http://download.oracle.com/javase/6/docs/technotes/guides/security/

You can start by adding those buttons to the elseifs in you actionPerformed method - have them just call methods add(), save() etc, then write those methods, one at a time, testing each small step with lots of print statements as you go.

I assume you are drawing the grid in an overridden paintComponent?
After moving the label you should just call repaint() to let Swing know that the container's paintComponent needs to be called a.s.a.p.

maybe the problem is here: // listProveedores.removeAll(); why is that commented out?
It looks to me like you do need to remove the old data before adding the latest data. What happens if you do a listProveedores.removeAll(); before any updates?

Your use of && looks OK to me. That isn't the neatest/shortest way to code it, but as far as I can see it should work as you intended, apart from some marginal cases where the ranges don't quite meet up, eg 3.05, which isn't a B+ or a B
Rather than all those else ifs and the afore-mentioned range problem, you could code it like this:

if (grade >= 4.0) return "A+";
if (grade >= 4.85) return "A"; 
etc

The secret of understanding this is to remember that list1, list2, list, and result are references (llike pointers) to an Object of type ArrayList<String>. The only way an actual ArrayList<String> object can be created is with the new keyword (line 3). If you follow the code 1 step at a time you will discover that there is only one ArrayList is this program, and that all those variables are just copies of the variable list1, so they all refer to the same object.
It's not easy to grasp 1st time round. Grab a sheet of paper with boxes for the variables and fill in the boxes as you step through the code. Remember the variables are references (pointers) they are not ArrayLists.

Can we please see more of the code - those two lines don't show enough to create or diagnose a problem. Ideally, post a small runnable program that demonstrates your problem.

I'm sure there are many of us here who would like to help you, but its really hard to debug 900 lines of completely uncommented code with variable and method names in a language that few of us speak.
Unless you can create a smaller simpler version that displays the same problem, the only help I can give is to advise you to add a whole load of print statements around the relevant areas so you can see where the values are differing from what you
expect.
Good luck anyway.

newMaze contains a copy of a reference (pointer) to the maze array in the instance of Maze, so yo can just use that as in newMaze[i][j] which will reference exactly the same memory location as the original maze[i][j]

No, it's not valid. The method currenttemp() must either have a body in {} or be declared abstract, in which case the class must also be declared abstract.
Without the () currenttemp becomes a float variable, not a method, and the code is valid.
We can only guess what the original author intended, but if he was following standard Java conventions that method would be called getCurrentTemp(), but then it wouldn't be private. My guess is that it's probably intended to be a variable.

Yes, absolutely. No criticism of your post in any way intended. I was just adding my own take on that subject.

It's not so much that it "violates encapsulation laws", it's more that it creates design problems and bugs that are really hard to fix. Declaring a constant as public is safe, but declaring a variable public means that anyone, anywhere, executing in any thread, may change its value at any time. You can code

public int a;
...
a= 1;
System.out.println(a);

and you have no guarantee that it will print the value 1, because some other code somewhere may have access and changed a's value.
Even if your code is single-threaded, you still have to worry about side-effects and consequences of changing a value. When some particular value is changed it may be necessary to update other values to match, or you may need to store that new value in a database. If you allow anyone to change the value you have no chance to deal with these.

ps, but yes, I am a hard-core OOPS guy, so I'm going to go with private variables and accessor methods every time.

^ like Stevanity says. Especially make your new classes inner classes of class KeyPad (ie define them inside the { and } of class KeyPad. If you make them separate public classes outside class KeyPad then you will need some extra code to give them access to the vars and methods of class KeyPad.
and...

JPanel kp = new JPanel();
kp.setBorder(BorderFactory.createEtchedBorder());
kp.add(new KeyPadPanel());

Since KeyPadPanel is JPanel there's no need to put it inside yet another panel. You can simply add it directly...

JPanel kp = new KeyPadPanel();
// set the border inside KeyPadPanel's constructor, not here 
...
frame.add(kp, BorderLayout.CENTER); // you haven't needed the .getContentPane() since Java 1.5

This is a standard problem with a standard solution:
Change the NewJFrame constructor to take an instance of Watcher as a parameter and store it. So your main now looks like

Watcher beholder = new Watcher();
NewJFrame GUI = new NewJFrame(beholder); // pass Watcher instance to GUI

now in NewJFrame you can use the beholder you have stored to access the variables and methods of your Watcher instance

... and I think the angles increase anti-clockwize as well

Taywin's right - the Math trig functions work in radians, not degrees (2*Pi radians = 360 degrees). Also I think zero angle is pure "East" (is along the x axis), not North.

1)Is Method Overloading considered as polymorphism?
2)Is there two types of polymorphism(run time and compile time ) available?

1. According to Oracle's web site - yes.
2. Given that Q1 answer is yes, then yes. Overridden methods are resolved at run time based on the target's run-time type. Overloaded methods are resolved at compile time based on the number and types of the arguments. Overridden overloaded methods are presumably resolved by a combination of the two.

The list of VK_... key codes can be found in the JavaDoc for KeyEvent. eg the control key is VK_CONTROL.
I don't know about how the Mac Command key is coded, maybe its its the same as VK_WINDOWS? (easy to try!), but you could write a very small program with a KeyListener and print out the key code that is passed into your keyPressed method,

That's almost certainly a good idea. The code for GUIs with lots of controls like this gets out of hand very quickly; it's very long, horrible to debug, and incomprehensible for anyone else. Splitting it into separate classes for each panel helps enormously.
One hint: Keep a class for the whole window, and make the panel classes sub-classes of it. That way the panel classes have access to the class variables and methods of the window class. You can use that to handle anything that needs to be shared or communicated between the panels. Any methods that can't be handled within just one panel can go up in the window class.

UDP is a connectionless protocol. What exactly do you mean by "disconnect the client" when there is no connection?

ps Are you thinking of the connect method in DatagramSocket? - that just simplifies the syntax for sending messages by pre-determining the addresses. From the server end you can ignore that. If you want, for some reason, the client to execute a disconnect() then I think you will have to make the server send a request to the client for the client to "disconnect". However, even if you do that the client can still send datagrams to the server, so if the intention is to prevent further messages from the server you will have to implement some kind of filter on the messages that he server receives.

It's true that any experienced Java developer would use ArrayList here, not an array, but the OP's task has been defined by his instructor, and he has to use an array. :-(

Within the limits set by the individual components' min/max sizes, GridBagLayout distributes the available space according to the x/y weights - the higher the weight the more of the available space goes to that component. If you set all the weights equal then, within the min/max constraints, the window should scale proportionally.
In most cases you will want some non-porportional behaviour - eg if you have a list box with buttons under it you want the space for the buttons to remain constant and all the rest of the space to go to the list box. In that case the list box would have xweight of 1 and the buttons zero.