I would be very grateful if someone could help me understand the passing of variables and methods between classes. For some reason, this concept completely eludes me, and I am never going to advance if I can't grasp it.

I understand the format when calling things from another class:


Code:


But it is never as simple as this, especially when using GUI's, JTables, arrays, vectors, etc. There's always implementing and extending, instantiating, declarations, exceptions, arguments....ugh!

It's like the English language; almost every instance has some kind of exception ("i" before "e" except after "c" or when sounding like an "a" as in "neighbor" or "sleigh").

Can someone please help me learn the Java rule exceptions (not exceptions as in handling...*grumble* try and catch....*grumble.*

What? It is that simple - always.

<some object>.<method>(<0 or more arguments>);

That's it, that's all it ever is. Doesn't matter if the class is extending, inheriting, overriding, whatever - doesn't matter at all to the caller.

Because he has className, I think he may be talking about static methods.

The difference in a static method and a non-static is that a non-static needs an actual object to be called on. It looks like:

myObject.myMethod(arguments);

A static method looks like:

myClass.myMethod(arguments);

With non-static you need an actual instance of an object. With static you just need the code that defines the class.

Take for example:

Bicycle myBicycle = new Bicycle();
myBicycle.getTopSpeed();

This is a non-static method. It needs an actual object (in this example, "myBicycle") to operate on. Non-static methods only know about data contained within that object, and data passed in as arguments.

A static method might be:
Bicycle.getTotalNumberOfBicycles();

In this, I am calling the function on the class Bicycle, rather than a Bicycle object (such as myBicycle). My class Bicycle might have a static int counter that increments every time I instantiate a new bicycle, thus keeping track of the total number of bicycles. Since it is dealing with all bicycles as a group (or rather, with no bicycle in particular), I make it a static method of the class Bicycle.

I didn't really get into arguments and spent this post describing static and non-static. Arguments are basically just data you pass to a function to give it access to that data. It works the same way Kllrnohj described.

Thank you. It seems fairly straight-forward, but when you start throwing in ActionListeners, it throws a monkey wrench into my understanding. Let me give an example:

In the college class that I just completed, we were creating a GUI that calculated payments on a mortgage. Input is provided by the user for the loan amount, the interest rate, and the length of the loan, and then the application displays a monthly payment, and a table full of amortized payments. The sample provided to us my the professor contained these classes:

MortgageCalculatorApp - This built the panel and contained the main method
MortgageCalculator - This contained the calculation methods
CalculateListener - This contained the ActionEvent for the Calculate Button
ClearListener - This contained the ActionEvent for the Clear Button
RateTermComboBox - This contained the constructor for the JComboBox with 3 rates/terms vectors

My assignment was to alter the application to allow the user to select between two options - Either he/she can use the combo box or he/she can input the rates and terms into a text field. To accomplish this, I tried to create a new class that would create a dialog box to pop up and give the user that option using radio buttons. The problem was that I couldn't get the user selection in one class to be recognized by the other class.

Was I over-thinking? I tend to do that.

In terms of style, I wouldn't use the dialog box. Instead, I would put the items for the choice on the form itself: selecting the combo box item would enable the combo box and disable the text box, and selecting the text box item would enable the text box and disable the combo box.

If you want to get stuff back from the dialog box, I would have the dialog send an action event when it closes, which is listened to by the main window. Then, you can expose a method on the dialog box that returns the results, which the listener method calls to set the appropriate options.

<begin educated tirade>
But the entire idea of ActionListeners is why I hate Java so much, because Sun stolidly refuses to implement function pointers and true events. Essentially, function pointers allow you to store function names as data, passing them around in arguments, and so forth. Here's an example in C#:

Code:

Events are essentially trigger points that can register any number of methods that match a certain delegate signature. When the event is triggered, all of those methods are called. For example:

Code:

<end educated tirade>