macOS Java equivalent in Obj C

[larswik]

Yesterday in my Java class I instantiated an object to use called CheckBoxGroup. This allowed me to group a bunch of check box items and made sure that if one box was selected the others were deselected. We used it to select a color to paint with. It seemed like a neat pre built code to use and was wondering if there is an objective C equal?

 

[lee1210]

Do you want a radio button? If not, what's better about this exclusive checkbox setup?

-Lee

 

[Sydde]

It seemed like a neat pre built code to use and was wondering if there is an objective C equal?

In Cocoa, this typically does not involve any coding. We usually just put together a NSMatrix of buttons in Interface Builder and set the matrix mode to what we need (I cannot remember the mode off-hand).

 

[larswik]

I thought I would post the code. Since I am learning I thought there might be an equivalent since it was so convenient. The CheckboxGroup manages the state of the check boxes and makes sure that only one is on at a time when they are grouped. I Had some code that I had to write to pick a sided dice that had 6 boxes. I had to write a bit of code to make sure when I checked a new box the other box was unchecked.

import java.applet.*;
import java.awt.*;
//import java.awt.event.*;
import java.util.Random;
//import java.awt.Color;

public class CheckBox extends Frame {
    String msg = "";
    Checkbox Red, Black, Magenta, Blue, Green, Yellow;
    [COLOR="Red"]CheckboxGroup cbg[/COLOR]; // Creates an instance of a selector that makes sure only 1 button is pressed
    Color theColor = Color.black; 
	public CheckBox( ) {
	    setLayout(new FlowLayout()); // this code creates 2 boxes.
		cbg = new CheckboxGroup();
		Red = new Checkbox("Red", [COLOR="Red"]cbg[/COLOR], true);
		Black = new Checkbox("Black", cbg, true);
		Magenta = new Checkbox("Magenta", cbg, true);
		Blue = new Checkbox("Blue", cbg, true);
		Green = new Checkbox("Green", cbg, true);
		Yellow = new Checkbox("Yellow", cbg, true);
   		add(Red);
		add(Black);
		add(Magenta);
		add(Blue);
		add(Green);
		add(Yellow);
		
	}	

	  public Color getCurrentColor(){

		  if(cbg.getCurrent()== Red)
			  theColor = Color.red;
		  if(cbg.getCurrent()== Black)
			  theColor = Color.black;
		  if(cbg.getCurrent()== Magenta)
			  theColor = Color.magenta;
		  if(cbg.getCurrent()== Blue)
			  theColor = Color.blue;
		  if(cbg.getCurrent()== Green)
			  theColor = Color.green;
		  if(cbg.getCurrent()== Yellow)
			  theColor = Color.yellow;
		  
		  return theColor;
	  }
}

 

[chown33]

Button Programming Topics : Using Radio Buttons.
In particular, look at NSRadioModeMatrix, and also see Listing 1: Creating a radio-button matrix programmatically.

And I'll repeat what Sydde said:

In Cocoa, this typically does not involve any coding. We usually just put together a NSMatrix of buttons in Interface Builder and set the matrix mode to what we need (I cannot remember the mode off-hand) [the mode is NSRadioModeMatrix].
​

This is one of the big differences between Java GUIs and Cocoa GUIs. Java frequently requires writing code that builds the entire GUI at the time it's used (i.e. in the program that uses it). There are ways to avoid that, but they're rarely used. In Cocoa, the GUIs are often built entirely in Interface Builder, stored in nib files. There's little or no code to actually build the GUI in the program that uses it. It's built before-hand (in IB) and the program that uses it simply loads it, which also establishes outlet connections.

 

[PatrickCocoa]

One more thing . . .

Objective-C is a language. Cocoa is the set of APIs for OS X. In your original post you used "objective C" when "Cocoa" would be more appropriate.

More lingo: Cocoa Touch is the set of APIs for iOS. Interface Builder is now a subset of Xcode 4.x, the development environment supplied by Apple. Checkboxes are boxes that can be checked independently of any other checkboxes. Radio buttons are a set of buttons that can have at most one button selected.

Interface consistency is very important in OS X and iOS. This is reinforced by the tools encouraging preferred interface behavior and discouraging or not allowing non-preferred interface behavior. It's also reinforce by the developer community, which is quick to point out inconsistent or "non-Mac" interface behavior.

Welcome to the machine.