Archief - hoe een jcheckbox in een jtable plaatsen

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
b

bikkerss

Legacy Member
ik probeer data in een jtable te plaatsen, dit lukt maar nu zou ik graag een extra kolom aanmaken waar een checkbox in de tabel staat.
ik heb al rondgekeken op internet maar snap er niet veel van.

is er iemand die me even kan verder helpen

dit is de code die ik al heb voor de data in te lezen.


Code: 
initComponents();
        
        DefaultTableModel model = new DefaultTableModel();
        JCheckBox check = new JCheckBox();
         JTable table = new JTable(model);

      model.setDataVector(new Object[][] {
           { new Boolean(true), "",}
           }, new Object[] {
            "", "Wenkenblad"});
        
        Object[] data = {new Boolean(true), "Wenkenbladen"};
                             
        File dbfile = new File("inforegistratie.db3");
        db=SqlJetDb.open(dbfile, true);
        ISqlJetTable sqltabel=db.getTable("wenkenbladen");
        db.beginTransaction(SqlJetTransactionMode.READ_ONLY);
        ISqlJetCursor lezer=sqltabel.open();
     
            
            while(!lezer.eof())
           
            {
              model.addRow(new Object[]{"",lezer.getString(0)});
              lezer.next();
            }
            
       lezer.close();
       db.close();
       jTable1.setModel(model);
b

bikkerss

Legacy Member
ik heb dit even toegevoegd maar zonder resultaat ik krijg nog steeds false te zien ipv de checkbox

table.getColumnModel().getColumn(0).setCellEditor(new DefaultCellEditor(check));

en dit aangepast

model.addRow(new Object[]{new Boolean(false), lezer.getString(0)});
N

NeverwinterX

Legacy Member
De standaard cell renderer van jtable kan al checkboxes automatisch gebruiken. De standaard table model is er echter niet op voorzien. Gebruik deze in de plaats:

Code: 
public class TableModelWithColumnClass extends DefaultTableModel {

	public TableModelWithColumnClass (Object[][] data, Object[] columnNames) {
		super(data, columnNames);
	}

	public TableModelWithColumnClass () {
		super();
	}

	@Override
	public Class getColumnClass(int c) {
		return this.getValueAt(0, c).getClass();
	}

}

Toont overigens ook getallen (integer, float...), datums en imageicons op een mooie manier.
M

MilM

Legacy Member
Werk gewoon met AbstractTableModel ipv DefaultTableModel.
Als je daar een Boolean gebruikt, is dat visueel automatisch een checkbox ...

Dus:
Code: 
public Object getValueAt(int r, int c) {
		if (c == 0)
			return new Boolean(box[r]);
}

En:
Code: 
public void setValueAt(Object object, int r, int c) {
		if (c == 0)
			box[r] = !box[r];
}

box is gewoon een boolean[] om bij te houden of het vakje geselecteerd moet zijn of niet.
In dit voorbeeld is de eerste column (c == 0) de kolom met de checkboxes
f

forloRn_

Legacy Member
MilM zei:
Werk gewoon met AbstractTableModel ipv DefaultTableModel.
Als je daar een Boolean gebruikt, is dat visueel automatisch een checkbox ...
Klik om te vergroten...

Dat kan niet kloppen. Ten eerste erft DefaultTableModel over van AbstractTableModel en zorgt de eerste net voor een implementatie van getValueAt(), en ten tweede is de JTable verantwoordelijk voor het uitzicht van de boolean. MVC, remember?

(En ten derde: in plaats van return new Boolean(box[r]) doe je beter return box[r], tenzij je graag onnodig nieuwe objectjes maakt natuurlijk.)

Edit: ik zie net NeverwinterX zijn post en dat lijkt me nu niet bepaald koosjer, de manier waarop het model bepaalt hoe de view eruit ziet. Bovendien kan je dan maar per kolom een bepaalde view hebben en niet per cel.
N

NeverwinterX

Legacy Member
forloRn_ zei:
Edit: ik zie net NeverwinterX zijn post en dat lijkt me nu niet bepaald koosjer, de manier waarop het model bepaalt hoe de view eruit ziet. Bovendien kan je dan maar per kolom een bepaalde view hebben en niet per cel.
Klik om te vergroten...

Mja niet helemaal. Het is eerder het model dat bepaalt wat de view mag zien van het model, namelijk of het het enkel als object mag zien of als meer specifiek. Je zou het een soort van information hiding kunnen noemen (niet echt helemaal, maar goed).

Het is trouwens de manier die wordt aangeraden in de java tutorials.
M

MilM

Legacy Member
forloRn_ zei:
Dat kan niet kloppen. Ten eerste erft DefaultTableModel over van AbstractTableModel en zorgt de eerste net voor een implementatie van getValueAt(), en ten tweede is de JTable verantwoordelijk voor het uitzicht van de boolean. MVC, remember?

(En ten derde: in plaats van return new Boolean(box[r]) doe je beter return box[r], tenzij je graag onnodig nieuwe objectjes maakt natuurlijk.)

Edit: ik zie net NeverwinterX zijn post en dat lijkt me nu niet bepaald koosjer, de manier waarop het model bepaalt hoe de view eruit ziet. Bovendien kan je dan maar per kolom een bepaalde view hebben en niet per cel.
Klik om te vergroten...

Erft blijkbaar idd van Abstract.
Ik heb gewoon in een stuk oude (onopgekuiste) code gekeken hoe ik het gedaan had.

Is gewoon zeer simpel out of the box. Kan best zijn dat er bepaalde drawbacks zijn en andere oplossing beter zijn, maar nog geen problemen tegengekomen bij het gebruik ervan.

Gaat hij trouwens niet automatisch een Boolean object aanmaken? Return type is namelijk Object.

getValueAt() wordt trouwens al geimplementeerd in TableModel, dus wel degelijk al beschikbaar in AbstractTableModel en DefaultTableModel is niet nodig.

Ivm MVC:

Een gewone JTable zonder model kan volgens mij niet met checkboxes werken omdat hij niet cast naar een boolean. Hij zal gewoon false/true uitprinten. Met AbstractModel werkt dat wel, omdat je zelf kan kiezen welke Klasse teruggegeven wordt (getColumnClass).

Deze is echter niet verplicht om geïmplementeerd te woorden in uw eigen subklasse en als je dat niet doet, zal het ook false/true uitprinten in de plaats.

Dus los van de rendering moet je bepaalde stappen ondernemen in het model die zuiver bepalen of false/true getoond wordt (Object) of de JCheckBox (boolean/Boolean)

Los daarvan is het logisch dat sowieso elk mogelijk model (dus ook DefaultTableModel) ondersteuning biedt voor het returnen van Class, dus ik begrijp uw reactie op mijn post, maar goed, ik zag gewoon reacties van een custom cell editor en i reageerde dat de combinatie JTable/AbstractModel dit out of the box kan zonder een CellEditor.

Ik heb daarbij niet gekeken naar DefaultTableModel en met die "in de plaats" was het niet de bedoeling te suggereren dat het met DefaultTableModel niet zou lukken.
W

Wolf2000me

Legacy Member
MilM zei:
Gaat hij trouwens niet automatisch een Boolean object aanmaken? Return type is namelijk Object.
Klik om te vergroten...

We spreken hier idd van "auto boxing". Dit zorgt ervoor dat primitieve datatypes zoals boolean "ingepakt" worden in de wrapper class Boolean wanneer de methode een Object als return type heeft. Dit is zo sinds Java 5 en uiteraard algemeen gebruikt.


MilM zei:
getValueAt() wordt trouwens al geimplementeerd in TableModel, dus wel degelijk al beschikbaar in AbstractTableModel en DefaultTableModel is niet nodig.
Klik om te vergroten...

TableModel is een interface en implementeert niks. Dit wordt ook niet geïmplementeerd in AbstractTableModel, dat klopt wel. Je moet dit dus wel zelf implementeren indien je dit wil gebruiken, of ergens een implementatie vandaan halen.



MilM zei:
Ivm MVC:

Een gewone JTable zonder model kan volgens mij niet met checkboxes werken omdat hij niet cast naar een boolean. Hij zal gewoon false/true uitprinten. Met AbstractModel werkt dat wel, omdat je zelf kan kiezen welke Klasse teruggegeven wordt (getColumnClass).

Deze is echter niet verplicht om geïmplementeerd te woorden in uw eigen subklasse en als je dat niet doet, zal het ook false/true uitprinten in de plaats.

Dus los van de rendering moet je bepaalde stappen ondernemen in het model die zuiver bepalen of false/true getoond wordt (Object) of de JCheckBox (boolean/Boolean)

Los daarvan is het logisch dat sowieso elk mogelijk model (dus ook DefaultTableModel) ondersteuning biedt voor het returnen van Class, dus ik begrijp uw reactie op mijn post, maar goed, ik zag gewoon reacties van een custom cell editor en i reageerde dat de combinatie JTable/AbstractModel dit out of the box kan zonder een CellEditor.

Ik heb daarbij niet gekeken naar DefaultTableModel en met die "in de plaats" was het niet de bedoeling te suggereren dat het met DefaultTableModel niet zou lukken.
Klik om te vergroten...

Ik ben geen swing guru, maar het lijkt mij toch sterk dat je geen checkboxes op een JTable kan plaatsen. In MVC is de JTable toch een View component als ik mij niet vergis. Ik denk dus wel dat de checkbox geregeld zal worden in de implementatie van JTable.

How to Use Tables (The Java™ Tutorials > Creating a GUI With JFC/Swing > Using Swing Components)

edit:

Whether you are setting the editor for a single column of cells (using the TableColumn setCellEditor method) or for a specific type of data (using the JTable setDefaultEditor method), you specify the editor using an argument that adheres to the TableCellEditor interface. Fortunately, the DefaultCellEditor class implements this interface and provides constructors to let you specify an editing component that is a JTextField, JCheckBox, or JComboBox. Usually you do not have to explicitly specify a check box as an editor, since columns with Boolean data automatically use a check box renderer and editor.
Klik om te vergroten...
M

MilM

Legacy Member
Wolf2000me zei:
TableModel is een interface en implementeert niks. Dit wordt ook niet geïmplementeerd in AbstractTableModel, dat klopt wel. Je moet dit dus wel zelf implementeren indien je dit wil gebruiken, of ergens een implementatie vandaan halen.
Klik om te vergroten...


Je moet hier blijkbaar echt op uw woorden letten :p
Gedefinieerd was dan mss beter geweest.

En ze wordt wel degelijk geïmplementeerd in AbstractTableModel.
AbstractTableModel is namelijk verplicht ze te implementeren, het zou anders ook niet kunnen werken zonder ze zelf te implementeren.

Als je zelf geen implementatie doet in uw eigen subklasse, zal gewoon Object teruggegeven worden als klasse.

Wolf2000me zei:
Ik ben geen swing guru, maar het lijkt mij toch sterk dat je geen checkboxes op een JTable kan plaatsen. In MVC is de JTable toch een View component als ik mij niet vergis. Ik denk dus wel dat de checkbox geregeld zal worden in de implementatie van JTable.
Klik om te vergroten...

Natuurlijk kan het wel.
Ik geef zelf een voorbeeld.
En natuurlijk is het het model niet dat de uiteindelijke draw zal doen.

En met een gewone JTable bedoel ik dus een simpele tabel waarbij je uw booleans meegeeft aan de constructor en niet met cell rendering begint te werken (ik zie ook niet direct in waarom je met cell rendering zou moeten werken, maar mss zijn er wel redenen ...)

Mijn punt is:

Als je een bepaalde MVC implementatie hebt en je wilt bepaalde zaken aan de View aanpassen, dan kan het best zijn dat je het Model ook moet aanpassen. Er is dus wel degelijk een invloed.
W

Wolf2000me

Legacy Member
Euh..

Een abstracte class hoeft helemaal niks te implementeren.
Een implementatie is dan ook fundamenteel verschillend van een declaratie. Zoiets mag toch wel gezegd worden zeker.


Sent using Tapatalk
M

MilM

Legacy Member
Sorry, zoals je kunt afleiden uit de rest van mijn post, was ik bezig over getColumnClass die geen verplichte methode is en dus geimplmenteerd wordt in AbstractTableModel en altijd Object teruggeeft.

Ik zie nu pas dat het gaat over de getValueAt methode. Dat is inderdaad een abstracte methode van de interface TableModel die niet geïmplementeerd wordt in AbstractTableModel en dus verplicht nog geïmplementeerd moet worden in uw eigen subklasse.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan