static help

[Jammer]

So I've been getting a null pointer exception for the last hour and I couldn't understand what it was. After som testing I realised what it was and now I have some questions.

This is what's in the gui class:

JRadioButton rdbtnVarrock;

public String getLocationName() {
		if(rdbtnVarrock.isSelected()) {
			return "Varrock";
		}
		else {
			return "Falador";
		}
	}

This is in the main class:

public Location getLocation() {
		for(Location loc : Location.values()) {
			if(loc.getName().equals(gui.getLocationName())) {
				return loc;
			}
		}
		
		return null;
		
	}

What I've realised is that if the radiobutton isn't static i get a null pointer exception. I've also noticed that for example here where I call a gui method directly without the use of a method inside main it works.

shouldProgressive = gui.shouldProgressiveMode();

I can't recall having seen this problem earlier. Is this some fundamental shit I've missed?

 

[Apaec]

14 minutes ago, Jammer said:

Is this some fundamental shit I've missed?

Ye:

Essentially, when you're defining rdbtnVarrock in your gui class, you are not instantiating it. You need to 'create' an instance of the JRadioButton object by calling the JRadioButton constructor. This can be done in-line, For example:

JRadioButton radioButton = new JRadioButton("Some text");

(Alternatively you can do this in the GUI class constructor) Also, it looks like you've got an enum storing various Locations, whatever they are. I'm not sure why you're encoding/decoding location data between your gui class and main class, but you can simply pass a reference to the respective enum values:

/* GUI Class */
public Location getSelectedLocation() {
  return radioButton.isSelected() ? Location.VARROCK : LOCATION.LUMBRIDGE;
}

/* Main Class */
Location desiredLocation = guiInstance.getSelectedLocation();

GL!

Apa

 

EDIT:

Incase it wasn't clear, the reason for the NPE was because you were referencing your radiobutton in the public method of the GUI class, however you may not have instantiated this radiobutton. If you find yourself making this mistake often, or just want to follow good practice, you might find defining the component as with 'private' and 'final' access modifiers. This should provide in-IDE error messages to remind you!

Edited January 11, 2018 by Apaec

[Jammer]

11 minutes ago, Apaec said:

Ye:

Essentially, when you're defining rdbtnVarrock in your gui class, you are not instantiating it. You need to 'create' an instance of the JRadioButton object by calling the JRadioButton constructor. For example:

JRadioButton radioButton = new JRadioButton("Some text");

Nah, I've instantiated it in the initialize() which initializes the jframe.

I put the object reference in the top so I could make a simple getter.

 

private JRadioButton rdbtnFalador;


public getLocation(){
if(rdbtnFalador.isSelected() {
//blabla
}
}


public void initialize() {

rdbtnFalador = new JRadioButton;

}

I also use call the getlocation method after initialize so the button is instantiated. 

It works when the button is static but not when it isn't, why is that?

 

edit: and also, is there a better way of keeping your object references for the jFrame and such than having them outside the "initialize" method?

Edited January 11, 2018 by Jammer

[Alek]

This is a very bad practice because this means you're relying on your GUI to be stored in memory after you're done using it.

Call gui.dispose(); and then figure out a way to store all the values which you collected from it prior to disposal. This will solve 2 issues of yours. 

[Explv]

@Jammer it would be helpful if you showed more code, to understand when getLocation() is being called, how you are setting up your GUI and closing your GUI etc.

Also side note:

I think it would make more sense for you to use a JComboBox<Location> instead of a JRadioButton.

By using a JComboBox you wouldn't need the getLocation() method, you would just call comboBox.getSelectedItem().

[Jammer]

Okay, it's solved now that I get the location directly through the gui as apaec suggested but I'm still curious why it didn't work from start.

20 minutes ago, Alek said:

This is a very bad practice because this means you're relying on your GUI to be stored in memory after you're done using it.

Call gui.dispose(); and then figure out a way to store all the values which you collected from it prior to disposal. This will solve 2 issues of yours. 

this is basically what it looked like:

public class GUI {

JRadioButton rdbtnFalador;
private JFrame frame;

public String getLocationName() {
return rdbtnFalador.isSelected() ? "Falador" : "Varrock";
}

//more variables


public void dispose() {
frame.dispose();
}

public void initialize() {
frame = new JFrame();

//initialized the buttons and more

}

}



public class Main {

GUI gui = new GUI();

public Location getLocation() {
		for(Location loc : Location.values()) {
			if(loc.getName().equals(gui.getLocationName())) {
				return loc;
			}
		}
		
		return null;
		
	}



public Static Location chosenLocation;
public static boolean shouldProgressive;

public void onStart() {
gui.initialize();

while(!gui.hasStarted) {
//sleep
}

chosenLocation = getLocation();
shouldProgressive = gui.getShouldProgressive; //This worked fine among other variables that were called directly through the gui instance

gui.dispose();

}

}

So it's not a matter of storing the variables or anything. 

Here is the thing: getLocation() returns null when the JRadioButton is not static.

Edited January 11, 2018 by Jammer

[HeyImJamie]

28 minutes ago, Jammer said:

Okay, it's solved now that I get the location directly through the gui as apaec suggested but I'm still curious why it didn't work from start.

this is basically what it looked like:

public class GUI {

JRadioButton rdbtnFalador;
private JFrame frame;

public String getLocationName() {
return rdbtnFalador.isSelected() ? "Falador" : "Varrock";
}

//more variables


public void dispose() {
frame.dispose();
}

public void initialize() {
frame = new JFrame();

//initialized the buttons and more

}

}



public class Main {

GUI gui = new GUI();

public Location getLocation() {
		for(Location loc : Location.values()) {
			if(loc.getName().equals(gui.getLocationName())) {
				return loc;
			}
		}
		
		return null;
		
	}



public Static Location chosenLocation;
public static boolean shouldProgressive;

public void onStart() {
gui.initialize();

while(!gui.hasStarted) {
//sleep
}

chosenLocation = getLocation();
shouldProgressive = gui.getShouldProgressive; //This worked fine among other variables that were called directly through the gui instance

gui.dispose();

}

}

So it's not a matter of storing the variables or anything. 

Here is the thing: getLocation() returns null when the JRadioButton is not static.

Not sure if it has an affect but you have a 'static' that's capitalised 

[Alek]

Looks like some sort of issue with initialization because the only way for getLocationName() to return null is for "rdbtnFalador" to return null. Have GUI extend JFrame then you won't have to worry about it. Alternatively look at your stacktrace, the IDE will literally tell you where the null is coming from.

[Jammer]

6 minutes ago, Alek said:

Looks like some sort of issue with initialization because the only way for getLocationName() to return null is for "rdbtnFalador" to return null. Have GUI extend JFrame then you won't have to worry about it. Alternatively look at your stacktrace, the IDE will literally tell you where the null is coming from.

It's really strange because calling gui.getLocationName directly without the use of getLocation() doesn't return null. 

I'll just use apaec's solution which is cleaner than what I thought of. Thanks for the help guys.

 

 

[Apaec]

43 minutes ago, Jammer said:

It's really strange because calling gui.getLocationName directly without the use of getLocation() doesn't return null. 

I'll just use apaec's solution which is cleaner than what I thought of. Thanks for the help guys.

It's odd that making it static changes how it behaves in this respect. Maybe there's something else going on, or I missed something, but that shouldn't affect it in this case.

As other people said though, you should probably extend JFrame - you will inherit lots of useful and well-written(~) functionality! <- much better than relying on externally calling the initialize method to not get a face-full of NPEs!

Good luck with your project

Apa