JMenuBar en CardLayout wisselt cards niet

[Verwijderd]

Hallo Tweakers,

Ik heb een beetje een raar probleem sinds ik gebruik maar van een JMenuBar i.p.v een awt menubar.

Ik heb een application die gebruik maakt van een classe GUI_Panels hierin staan al mijn JPanels waarvan de applicatie gebruikt maakt ook heb ik een Classe Taskbar deze krijgt in zijn constructur de main classen van de applicatie (Client) meegestuurd.

Nu heb ik volgende Probleem als ik nu een actionlistener om een card op Gui_panels te wijzige aanroep krijg ik de volgende fout melding:

code:

java.lang.NullPointerException
    at Taskbar$AddEcrListener.actionPerformed(Taskbar.java:124)
    at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1786)
    at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1839)
    ...

Ik krijg deze melding er totaal niet uit omdat ik hem helemaal niet thuis kan brengen. Ook op de diverse documententatie op de site van sun kom ik niet verder mee.

Ik gebruik de volgende methode's

taskbar

code:

private class AddEcrListener implements ActionListener {
    public void actionPerformed(ActionEvent e) {
      client.gui.addECR();
    }
  }

GUI_panels

code:

public void addECR() {

    if (addEcr != null)
     {
       cards.removeLayoutComponent(addEcr);
       remove(addEcr);
     }

     addEcr = new AddEcr(this);
     add("addEcr", addEcr);
     cards.show(this, "addEcr");

  }

Ik snap dat forum niet bedoeld is voor debugen, maar als iemand misschien weet waarom het fout gaat of welk object die nullpointer geef. Dan kan ik zelf proberen te zoeken of ik kan oplossen maar nu kan ik totaal niet plaatsen waarom niet werkt met een JMenubar en wel met een AWT menubar

Alvast bedankt!!

[Nick_S]

Vraagje, welke regel uit je voorbeeldcode is regel 124 uit je klasse Taskbar?

Ik gok zelf op onderstaande code, regel 3, waardoor het lijkt, dat je je variabele "client" of "gui" (is dit een public variabele? Foei!) geen waarde geeft in je constructor.

Maar voor de rest is mijn glazen bol kapot, dus je moet wat meer info geven, zeker wat betreft regelnummers (Ga nu niet heel je code hier pasten )

Als het hier niet mee lukt, verwijs ik je door naar een IDE, zoals Eclipse, waar goede debuggers in zitten, zodat je kan steppen door je code en kijken welke variabele nog op null instaat.

[ Voor 26% gewijzigd door Nick_S op 02-08-2006 09:45 ]

[Verwijderd]

Nick_S schreef op woensdag 02 augustus 2006 @ 09:42:
Vraagje, welke regel uit je voorbeeldcode is regel 124 uit je klasse Taskbar?

Ik gok zelf op onderstaande code, regel 3, waardoor het lijkt, dat je je variabele "client" of "gui" (is dit een public variabele? Foei!) geen waarde geeft in je constructor.

Maar voor de rest is mijn glazen bol kapot, dus je moet wat meer info geven, zeker wat betreft regelnummers (Ga nu niet heel je code hier pasten )

Als het hier niet mee lukt, verwijs ik je door naar een IDE, zoals Eclipse, waar goede debuggers in zitten, zodat je kan steppen door je code en kijken welke variabele nog op null instaat.

Die code regel 124 is de regel waarin dus via client.gui.setLogout(); wordt aangeroepen.

Ik heb nu met debugen het probleem opgelost door ook de gui mee te geven aan de taskbar.

Dus nu roep ik het niet meer aan via client die de public variable gui aanroept en daar de public methode setLogout aanroept.

Maar roep ik het aan die gui zelf deze geef ik mee in de constuctor en declareer ik in de classe taskbar als private variable.


gui was inderdaad eerst dus een public variable, maar hoezo die foei?

Ohja nee inderdaad ga niet mijn hele code posten want moet mijn probleempjes zelf oplossen daar leer je van en niet verwachten dat andere mijn brake code wel even debuggen

[Robtimus]

Verwijderd schreef op woensdag 02 augustus 2006 @ 10:38:
gui was inderdaad eerst dus een public variable, maar hoezo die foei?

Je wilt (vrijwel) nooit je variabelen public maken maar in plaats daarvan via getXXX en setXXX methods werken. Dit principe heet data encapsulation, en heeft veel voordelen (te lam om ze op te schrijven) en maar 1 nadeel: je moet ietsje meer typen.

Ohja nee inderdaad ga niet mijn hele code posten want moet mijn probleempjes zelf oplossen daar leer je van en niet verwachten dat andere mijn brake code wel even debuggen

Die stacktrace gaf je in ieder geval de precieze locatie waar het fout ging. De bovenste regel is altijd degene waar het fout gaat. Je moet dan net zover terug gaan totdat je je eerste eigen geschreven code hebt gevonden, en dan zit daar de fout (of mogelijk nog wat lager). In dit geval was dus of client zelf of client.gui null.

[Verwijderd]

Dit principe heet data encapsulation, en heeft veel voordelen (te lam om ze op te schrijven)

Zou je toch zo vriendelijk willen zijn om 't op te schrijven? Een collega-programmeur (en tegelijkertijd ook m'n baas en de eigenaar van het bedrijf waarvoor ik werk ) vertikt 't categorisch om netjes properties in 't leven te roepen wanneer de getter en setter alleen maar de bijbehorende private variabele benaderen. Dat worden bij hem gewoon public variabelen.

Het enige wat ik daartegen in kan brengen is "het is niet netjes OOP" (ja, en?) of "misschien wil je later in de setter wel iets meer doen" (dan maak ik er dan wel een property van.)...

[Nick_S]

Verwijderd schreef op woensdag 02 augustus 2006 @ 23:08:
[...]
Zou je toch zo vriendelijk willen zijn om 't op te schrijven? Een collega-programmeur (en tegelijkertijd ook m'n baas en de eigenaar van het bedrijf waarvoor ik werk ) vertikt 't categorisch om netjes properties in 't leven te roepen wanneer de getter en setter alleen maar de bijbehorende private variabele benaderen. Dat worden bij hem gewoon public variabelen.

Het enige wat ik daartegen in kan brengen is "het is niet netjes OOP" (ja, en?) of "misschien wil je later in de setter wel iets meer doen" (dan maak ik er dan wel een property van.)...

Vergelijk maar eens de volgende stukjes code:

code:

final PropertyClass propertyClass = ownerclass.getProperty();
propertyClass = null;

code:

ownerclass.property = null;

*Note PropertyClass is een fictieve klasse, waarvan property een instantie is.
Welke van de twee stukjes code kan voor veel problemen zorgen?

Om dit op te vangen zul je dus of getter/setters moeten gebruiken, of elke keer als je een property gebruikt moeten controleren op null.

Tweede vorm:

code:

public class OwnerClass {
    private final PropertyInterface property = new PropertyImplementatie();

    public PropertyInterface getProperty() {
        return property;
    }
}

In dit geval is het heel makkelijk om lokaal eens de implemenatie te vervangen (Puur JDBC tegenover Hibernate bijvoorbeeld) zonder dat de aanroepende klasse dit door hebben.

Omdat het wel een klein beetje een zoekvraag is, wil ik ook nog even een stukje c/p wat ik na 5 seconden google had gevonden.

quote: http://web.cs.mun.ca/~donald/bsc/node13.html

Data Encapsulation

Data encapsulation, sometimes referred to as data hiding, is the mechanism whereby the implementation details of a class are kept hidden from the user. The user can only perform a restricted set of operations on the hidden members of the class by executing special functions commonly called methods. The actions performed by the methods are determined by the designer of the class, who must be careful not to make the methods either overly flexible or too restrictive. This idea of hiding the details away from the user and providing a restricted, clearly defined interface is the underlying theme behind the concept of an abstract data type.

The advantage of using data encapsulation comes when the implementation of the class changes but the interface remains the same. For example, to create a stack class which can contain integers, the designer may choose to implement it with an array, which is hidden from the user of the class. The designer then writes the push() and pop() methods which puts integers into the array and removes them from the array respectively. These methods are made accessible to the user. Should an attempt be made by the user to access the array directly, a compile time error will result. Now, should the designer decide to change the stack's implementation to a linked list, the array can simply be replaced with a linked list and the push() and pop() methods rewritten so that they manipulate the linked list instead of the array. The code which the user has written to manipulate the stack is still valid because it was not given direct access to the array to begin with.

The concept of data encapsulation is supported in C++ through the use of the public, protected and private keywords which are placed in the declaration of the class. Anything in the class placed after the public keyword is accessible to all the users of the class; elements placed after the protected keyword are accessible only to the methods of the class or classes derived from that class; elements placed after the private keyword are accessible only to the methods of the class.

As a convention, calling a method of an object instantiated from a class is commonly referred to as sending a message to that object.

[Verwijderd]

Nick_S schreef op woensdag 02 augustus 2006 @ 23:19:
Omdat het wel een klein beetje een zoekvraag is, wil ik ook nog even een stukje c/p wat ik na 5 seconden google had gevonden.

't Is absoluut niet bedoeld als zoekvraag, ik weet wat de voordelen van encapsulation zijn, en na 5 seconden Googlen had ik 't ook wel kunnen vinden, maar niks nieuws bijgeleerd...
Uit jouw quote:

Data encapsulation, sometimes referred to as data hiding, is the mechanism whereby the implementation details of a class are kept hidden from the user.

In mijn voorbeeld:

vertikt 't categorisch om netjes properties in 't leven te roepen wanneer de getter en setter alleen maar de bijbehorende private variabele benaderen.

Daar wordt dus niks ge-hide.
99% van de properties die je in tegenkomt zijn in de orde van:

C#:

private int myVar;

public int MyVar
{
  get { return myVar; }
  set { myVar = value; }
}

of

Delphi:

private
  FMyVar: integer;
public
  property MyVar: integer read FMyVar write FMyVar;

Probeer dan maar 's iemand te overtuigen om dan geen public variabelen te gebruiken...

[Nick_S]

Zie dan mijn eerste voorbeeld. Nog een voordeel daar is, dat je met een breakpoint precies kan zien wie jouw code probeert te misbruiken door er null van te maken. Dat is zonder propertie functies niet mogelijk vziw. Het is lastig debuggen als je niet weet welk deel van de code een property per ongeluk op null zit door een rare assignment.