[java] Ik zie het niet

[Xenon]

Wat is hier in godsnaam fout aan, ik zie het niet...
Als ik de TestPaintGraf12 run werkt ie, maar als ik op het kruisje klik bovenaan de frame krijg ik een vage foutmelding

code:

public class TestPaintGraf12{
    public static void main(String [] arg){
        PaintGraf12 f1 = new PaintGraf12();
        f1.bouwGui();
    }
}

code:

import java.awt.*;
import java.awt.event.*;

public class PaintGraf12 extends WindowAdapter{
    private Frame basicFrame;
    public PaintGraf12(){
    }
    public void bouwGui(){
    Frame basicFrame = new Frame();
    basicFrame.addWindowListener(this);
    basicFrame.setSize(500,500);
    basicFrame.setVisible(true);
    }
    public void windowClosing(WindowEvent e){
        basicFrame.setVisible(false);
        basicFrame.dispose();
        System.exit(0);
    }
}

:( :( :(

[D2k]

wat is dan die vage foutmelding?
ik heb mijn glazen bol niet bij me......

[Alarmnummer]

[Xenon]

code:

H:\Java\graphics>java TestVectorEx
windowhandler
Exception occurred during event dispatching:
java.lang.NullPointerException
      at VectorEx$windowHandler2.windowClosing(VectorEx.java:40)
      at java.awt.Window.processWindowEvent(Unknown Source)
      at java.awt.Window.processEvent(Unknown Source)
      at java.awt.Component.dispatchEventImpl(Unknown Source)
      at java.awt.Container.dispatchEventImpl(Unknown Source)
      at java.awt.Window.dispatchEventImpl(Unknown Source)
      at java.awt.Component.dispatchEvent(Unknown Source)
      at java.awt.EventQueue.dispatchEvent(Unknown Source)
      at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)

      at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
      at java.awt.EventDispatchThread.run(Unknown Source)

[Alarmnummer]

Je kan beter dit doen:

code:

public class TestFrame extends JFrame{

   public TestFrame(){
     setSize(500,500);
     
     setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
   }
}

public class Main{
   public static void main(String[] args){
     TestFrame testFrame = new TestFrame();
     testFrame.setVisible(true);
   }
}

[Alarmnummer]

Heb trouwens nog nooit zo`n constructie gezien dat een hulp class een hoofd class aanmaakt. Ik vind hem wel aardig

[Xenon]

Ik weet het al....

code:

Frame basicFrame = new Frame();

moest

code:

basicFrame = new Frame();

zijn....

[mbravenboer]

-hfl-xenon: Ik weet het al....

Je begrijpt ook waarom neem ik aan?

[Verwijderd]

Op vrijdag 22 februari 2002 11:50 schreef Alarmnummer het volgende:
Heb trouwens nog nooit zo`n constructie gezien dat een hulp class een hoofd class aanmaakt. Ik vind hem wel aardig

Mwoah, kan wel eens handig zijn als je diepe dirs hebt en niet veel wilt tiepen, hoewel het natuurlijk ook met een scripje kan

code:

include com.fladder.Chat.Server.*

public class StartServer
{
   public static void main(String args[])
   {
     new Daemon();
   }
}

[Alarmnummer]

Op vrijdag 22 februari 2002 13:15 schreef fladder het volgende:
Mwoah, kan wel eens handig zijn als je diepe dirs hebt en niet veel wilt tiepen

Uitzonderlijk slecht argument. Hierdoor krijg je snel spaghetti code.

[mbravenboer]

Ik gebruik altijd een aparte klasse voor een main.... Wat is daar mis mee . Persoonlijk vind ik het lelijk om een main in Frame klassen op te nemen omdat je dan als het ware al van te voren beslist wat je entry-point wordt. Een applicatie entry-point is iets heel anders dan een Frame imho .

Ik vind sowieso dat je nooit een Frame moet extenden, maar das een ander punt .

[Stephan Oudmaijer]

Op vrijdag 22 februari 2002 13:51 schreef mbravenboer het volgende:
Ik gebruik altijd een aparte klasse voor een main.... Wat is daar mis mee . Persoonlijk vind ik het lelijk om een main in Frame klassen op te nemen omdat je dan als het ware al van te voren beslist wat je entry-point wordt. Een applicatie entry-point is iets heel anders dan een Frame imho .

Ik vind sowieso dat je nooit een Frame moet extenden, maar das een ander punt .

mwa frame extenden is helemaal niets fout mee toch..

[Glimi]

Op vrijdag 22 februari 2002 15:27 schreef CK het volgende:
mwa frame extenden is helemaal niets fout mee toch..

Wel als je hem niet gaat extenden maar puur gaat gebruiken om te laten zien IMO

[Stephan Oudmaijer]

Op vrijdag 22 februari 2002 15:28 schreef Glimi het volgende:

[..]

Wel als je hem niet gaat extenden maar puur gaat gebruiken om te laten zien IMO

ik zie echt niet waar het probleem zit hoor.Ik zie alleen maar voordelen (toegang tot protected methods, minder code)

[mbravenboer]

CK: mwa frame extenden is helemaal niets fout mee toch..

Het extenden van een frame is typisch verkeerd gebruik van inheritance. Je wilt namelijk helemaal geen frame uitbreiden. Je wilt de content van een frame uitbreiden. De content van een frame is geen frame (zeker niet in Swing) maar een Panel .

Naast dit ietwat theoretische punt is er nog een groot praktische nadeel: als je een bepaalde dialoogvorm (Frame, Dialog, InternalFrame) extend zit je vast aan deze verschijningsvorm. Je kan dus nooit meer ipv een Frame een Dialog pakken. Dat is een heel vervelend probleem als je GUI onderdelen schrijft die in verschillende omgevingen gebruikt. Dit praktische bezwaar vloeit overigens voort uit het theoretische bezwaar .

[Alarmnummer]

Ik vind jouw argument dat je niet moet extenden van een frame of dialog omdat je dan vast zit aan een bepaalde verschijningsvorm heel aardig.

[TheOneLLama]

Op vrijdag 22 februari 2002 15:32 schreef mbravenboer het volgende:

[..]

Het extenden van een frame is typisch verkeerd gebruik van inheritance. Je wilt namelijk helemaal geen frame uitbreiden. Je wilt de content van een frame uitbreiden. De content van een frame is geen frame (zeker niet in Swing) maar een Panel .

Naast dit ietwat theoretische punt is er nog een groot praktische nadeel: als je een bepaalde dialoogvorm (Frame, Dialog, InternalFrame) extend zit je vast aan deze verschijningsvorm. Je kan dus nooit meer ipv een Frame een Dialog pakken. Dat is een heel vervelend probleem als je GUI onderdelen schrijft die in verschillende omgevingen gebruikt. Dit praktische bezwaar vloeit overigens voort uit het theoretische bezwaar .

Hm, ben het gedeeltelijk met je eens, je zou geen programma specifieke code moeten opnemen als je een Frame extend maar d'r zijn toch wel degelijk situaties waarin je een frame wel extend, bv om een Frame te maken met extra functionaliteit. Verder zou je inderdaad veel via content panes kunnen doen, maar in veel IDE's en dergelijke doen ze dat totaal niet. Komt dat nou omdat ze hun methode beter dan de jouwe vinden of omdat ze gewoon brak zijn?

Zelf programeer ik niet zoveel in Swing en AWT maar meer in J2ME waar je meer met Canvas, Screen, ComponentScreen ed te maken hebt, die hebben geen ContentPane. Wel laat ik vaak de event-handeling in de klasse die ik expand staan, maar dit omdat je niet veel hebt om tussen te switchen in j2me... deze slechte gewoonte neem ik echter wel vaak weer mee naar j2se

[mbravenboer]

TheOneLLama: maar d'r zijn toch wel degelijk situaties waarin je een frame wel extend, bv om een Frame te maken met extra functionaliteit.

Dat kan inderdaad, maar dan moet je het imho niet doen om dat Frame een inhoud te geven. Dit wordt helaas toch erg vaak gedaan...

maar in veel IDE's en dergelijke doen ze dat totaal niet. Komt dat nou omdat ze hun methode beter dan de jouwe vinden of omdat ze gewoon brak zijn?

Hoogstwaarschijnlijk het tweede . Gebrek aan innovatie en inzicht imho... Ik heb in ieder geval nog geen enkel argument tegen mijn bewerking gehoord en weet eigenlijk zeker dat ik elk argument onderuit kan harken .

Mijn idee is ontstaan omdat ik veel werk met zowel JInternalFrames als native dialogen of native frames. Ik kwam erachter dat je in de GUI zelf eigenlijk helemaal niet hoeft te weten in wat voor verschijningsvorm hij uiteindelijk geplaatst zal worden. Om maximaal hergebruik te bereiken ben ik de zaak gaan scheiden.

Je stuit daarbij echter toch op problemen omdat je toch vaak wel een referentie naar een window wilt hebben. Omdat JInternalFrames, JFrames en JDialogs geen zinvolle gemeenschappelijke parent hebben die een window representeert heb ik een WindowHandle geintroduceerd. Dit is een abstractie van wat voor vorm van Window dan ook. Daarom kan ik nu tranparant gebruik maken van alle windows .

Nadat ik deze praktische oplossing had gevonden ontdenkte ik eigenlijk pas dat het ook theoretisch goed te beredeneren is...

Zelf programeer ik niet zoveel in Swing en AWT maar meer in J2ME

Dat is inderdaad een hele andere wereld, waar je helaas onder andere requirements en omstandigheden moet werken .