[JAVA] Jdialog wil niet sluiten :-(

[Verwijderd]

Ik hoop dat ik deze vraag mag stellen, omdat je hier wel eens van die paranoïde moderators hebt die er gelijk maar van uit gaan dat je zelf nog helemaal niets geprobeerd hebt....

paranoide-modbreak: als je met iemand een probleem mee hebt mail hem dan of open een topic in Lieve Adjes, zoals je had kunnen lezen in die FAQ waar ik je de vorige keer naar verwees. Verder hier on-topic, of geen topic.

Aanshouw onderstaande code:

Java:

protected OrderScherm(int klantNummer, Containment opslag)
{
    this.opslag = opslag;

    // klantenFrame ophalen
    NiccrmFrame klantenFrame = this.opslag.getKlantenFrame();

    // ok, nu gaan we een modaldialog maken
    JDialog orderScherm = new JDialog(klantenFrame, true);
    // Orderscherm ophalen
    JPanel orderPanel   = this.getOrderScherm(klantNummer);
    // orderscherm toevoegen aan de JDialog
    orderScherm.getContentPane().add(orderPanel);
    // Gebruiker mag deze niet vergroten of verkleinen!
    orderScherm.setResizable(false);
    orderScherm.setTitle("NICCRM - Orderinvoer");
    // detecteer de grootte van de content en pas de schaling daar op aan
    orderScherm.pack();
    // tonen dat ding!
    orderScherm.show();
    // storen dat scherm
    this.opslag.setOrderScherm(orderScherm);
}

Het lukt me alleen niet om dit JDialog weer te sluiten.

Ik heb setvisible geprobeerd, gecombineerd met op null zetten en ik heb hide geprobeerd. Hij wil alleen niet weg.... Ook niet als ik gelijk hide aanroep onder de show.... Waarschijnlijk maak ik 1 of andere megabeginnersfout, maar ik kan het zo snel niet vinden in ieder geval.

[ Voor 11% gewijzigd door curry684 op 10-06-2003 19:23 ]

[JayVee]

Heb je orderScherm.dispose al gebruikt?
Verder is het handig als je de code in [code=java ] [ /code] zet, maakt het veel beter leesbaar. Suc6

[hobbit_be]

JDialog.dispose();

[Verwijderd]

Je wilt even uitkijken als je een modaal dialog maakt. Zodra je orderScherm.show() doet blijft die methode daar wachten tot er weer hide() is gedaan op het orderScherm (bijvoorbeeld bij het klikken op een OK-button). Die laatste regel in je stukje code wordt dan ook pas uitgevoerd na zo'n hide().

[ Voor 3% gewijzigd door Verwijderd op 10-06-2003 19:22 ]

[Verwijderd]

JayVee schreef op 10 juni 2003 @ 19:16:
Heb je orderScherm.dispose al gebruikt?
Verder is het handig als je de code in [code=java ] [ /code] zet, maakt het veel beter leesbaar. Suc6

Euh....
Dispose had ik ook al geprobeerd, maar vreemd genoeg werkt dat niet, zelfs niet als ik hem gelijk na de show aanroep (slaat nergens op, maar goed je probeert wat om dat ding weg te krijgen ) Hij geeft ook geen compilererror, hij vindt het allemaal wel ok eigenlijk.

[Verwijderd]

Verwijderd schreef op 10 June 2003 @ 19:22:
Je wilt even uitkijken als je een modaal dialog maakt. Zodra je orderScherm.show() doet blijft die methode daar wachten tot er weer hide() is gedaan op het orderScherm (bijvoorbeeld bij het klikken op een OK-button). Die laatste regel in je stukje code wordt dan ook pas uitgevoerd na zo'n hide().

Ok, dat is duidelijk en ook wel logisch eigenlijk. Nu heb ik inderdaad een button met daarop een actionlistener. In de actionperformed haal ik het orderscherm weer op uit mijn 'containment-klasse'. Toch zit er (vermoed ik) iets niet goed met mijn referenties, want ik krijg een java.lang.NullPointerException op dat moment.

Ter verduidelijking:

Java:

// uit de containment-klasse
// de setter roep ik aan in bovenstaande code uit mijn bericht
protected void setOrderScherm(JDialog orderScherm)
{
   this.orderScherm = orderScherm;
}

protected JDialog getOrderScherm()
{
  return this.orderScherm;
}

// uit de eventklasse
// ok, er is een selectie gemaakt in de pulldown...
public void actionPerformed(ActionEvent event)
{
  // op welke knop is geklikt?
  String action = event.getActionCommand();

  // ok, er wordt een order opgeslagen / gewijzigd
  if (action == "Opslaan")
  {
    this.saveOrderEvent();
  }
  // ok, het is een selectie uit de orderspulldown...
  else if (action == "comboBoxChanged")
  {
    this.orderSelectieEvent();
  }
}

  private void saveOrderEvent()
  {
    JPanel orderPaneel = this.opslag.getOrderPaneel();
    JDialog orderScherm = this.opslag.getOrderScherm();

    JLabel jlOrderNummer      = (JLabel) orderPaneel.getComponent(1);
    JLabel jlKlantNummer      = (JLabel) orderPaneel.getComponent(2);
    JTextField tfOmschrijving = (JTextField) orderPaneel.getComponent(8);
    JTextField tfOrderDatum   = (JTextField) orderPaneel.getComponent(10);
    JTextField tfUren         = (JTextField) orderPaneel.getComponent(12);
    JTextField tfKostPrijs    = (JTextField) orderPaneel.getComponent(14);
    JTextField tfProjectPrijs = (JTextField) orderPaneel.getComponent(16);
    JTextArea  taMemo         = (JTextArea)  orderPaneel.getComponent(18);

    String orderNummer  = jlOrderNummer.getText();
    String klantNummer  = jlKlantNummer.getText();
    String orderDatum   = tfOrderDatum.getText();
    String uren         = tfUren.getText();
    String kostPrijs    = tfKostPrijs.getText();
    String projectPrijs = tfProjectPrijs.getText();
    String memo         = taMemo.getText();
    String omschrijving = tfOmschrijving.getText();

    DateMethods datum = new DateMethods();
    String invoerDatum = datum.getHuidigeDatum();

    OrderTabel orderTabel = new OrderTabel();

    orderTabel.setInvoerDatum(invoerDatum);
    orderTabel.setKlantKlantNummer(klantNummer);
    orderTabel.setKostPrijs(kostPrijs);
    orderTabel.setMemo(memo);
    orderTabel.setOmschrijving(omschrijving);
    orderTabel.setProjectPrijs(projectPrijs);
    // status 0 is een order
    orderTabel.setStatusId("0");
    orderTabel.setUren(uren);

    // insertactie, nieuwe order
    if (orderNummer.length() == 0)
    {
      orderTabel.save();
    }
    // ok, een updateactie
    else
    {
      orderTabel.setOrderNummer(orderNummer);
      orderTabel.update();
    }
   // en hier ga ik STUKKENT! ;-) 
   orderScherm.dispose();
   }

[hobbit_be]

offtopic:
wat een pokkecode (no real offence ) (don't get me started on the use of the evil "this" overal en het nederenglish , en ik hoop dat de GUI gegenereert werd want getComponent met een nummer index is super gortig)

als je niets aan je oorspronkelijke code hebt veranderd (we hoeven heus niet te zien dat je 20 buttons hebt hoor) dan moet je de 'orderScherm' wel zetten VOORDAT je show() aanroept

[Feyd-Rautha]

Gebruik ook eens de method setVisible(true); in plaats van show(). De method show() is deprecated zoals dit ook in de API aangegeven is.

[Verwijderd]

hobbit_be schreef op 10 June 2003 @ 20:43:

offtopic:
wat een pokkecode (no real offence ) (don't get me started on the use of the evil "this" overal en het nederenglish , en ik hoop dat de GUI gegenereert werd want getComponent met een nummer index is super gortig)

als je niets aan je oorspronkelijke code hebt veranderd (we hoeven heus niet te zien dat je 20 buttons hebt hoor) dan moet je de 'orderScherm' wel zetten VOORDAT je show() aanroept

Helemaal eens dat de code verre van optimaal is, probleem is alleen dat ik het heel graag beter zou willen doen, ik baal d'r gewoon ook van dat bv. de klassen afhankelijk van elkaar zijn. Ik ben echter pas een relatief korte periode 'serieus' voor school JAVA aan het programmeren, ik krijg waardeloos les van docenten die het zelf ook niet weten (allemaal layout her en der in de klasses bv.) en het is een deeltijdopleiding dus minder uren dan bij voltijd. Praktisch gezien heb ik gewoon een opdracht die gewoon af moet op een bepaalde datum. Ik moet soms zo verrekte lang zoeken voor iets heel kleins. (Ik heb gelukkig wel beide Core-JAVA-boeken), tel daar het de moderators bij op en het plaatje is compleet... Ik tracht wel enige dingen gescheiden te houden, voor zo ver ik dat al kan in JAVA (geen inner classes voor events en zo, zelfde code voor insert en update, etc.).

Waarom mag ik this niet gebruiken?, ik heb een containmentklasse, waar ik layoutobjecten als klassevariabele in store en aangezien ik deze objecten ook beschouw als onderdeel van de klasse, vond ik het niet zo heel vreemd. this, gebruik ik alleen maar als ik het beschouw als onderdeel van de klasse.

hmmm, dat setten is nu ik de code terugzie het probleem, dat kan niet anders....

GUI genereren doe ik niet aan, alleen het probleem blijft dat ik alles zelf machtig moet maken naast een fulltime baan, zonder een goede docent (los van jullie dan )

p.s. Ik heb maar 1 button.....

[Verwijderd]

Feyd-Rautha schreef op 10 juni 2003 @ 20:45:
Gebruik ook eens de method setVisible(true); in plaats van show(). De method show() is deprecated zoals dit ook in de API aangegeven is.

Ehhh, ik twijfel toch een beetje daaraan, ik kan namelijk in de API niet vinden dat het deprecated is, daar komt bij dat de nieuwste CORE-JAVA (JDK 1.4-proof) het ook gebruiken. Nadere toelichting?

ok, dit heb ik net nog ontdekt....

Quote uit Core Java:
The JFrame class inherits the show method from the superclass Window. The Window class hass a superclass Component that also has a show method. The Component.show method is deprecated, and you are supposed to call setVisible(true) instead if you want to show a component. However the Window.show method is not deprecated. For Windows and frames it makes sense to call show, not setVisible, because show makes the window visible and brings it to the front.

[ Voor 38% gewijzigd door Verwijderd op 10-06-2003 21:33 ]

[hobbit_be]

Verwijderd schreef op 10 June 2003 @ 21:15:
[...]
Helemaal eens dat de code verre van optimaal is

twas ook echt niet persoonlijk hoor - iedereen hier (tenzij de echt geniale mensen) heeft ook een lange weg achter de rug. Ik zal in het vervold de 'offtopic' weghouden

Waarom mag ik this niet gebruiken?

we waren hier op GoT daar onlangs nog mee bezig: het heeft eigenlijk geen zin en het gebruik van dezelfde variablen als members en arguments (en het dus verplicht gebruik van this) leid vaak tot hele rottige probleempjes waar je heel eenvoudig kunt overzien. Meeste mensen met wat ervaring zullen hun member variables prefixen of hun arguments.

GUI genereren doe ik niet aan

dan stel ik voor je UI element gewoon als members te declaren ipv ze steeds te gaan 'opzoeken'. Zelf doe ik nog iets anders maar dat is een beetje te advanced om echt te helpen.

p.s. Ik heb maar 1 button

ik had het meer over de onnodige code die je gepost had - daar zijn die rotte paranoide moderators ( ) niet 'keen' op...

[ Voor 4% gewijzigd door curry684 op 10-06-2003 21:56 . Reden: niet schelden he ;) ]

[pgussow]

we waren hier op GoT daar onlangs nog mee bezig: het heeft eigenlijk geen zin en het gebruik van dezelfde variablen als members en arguments (en het dus verplicht gebruik van this) leid vaak tot hele rottige probleempjes waar je heel eenvoudig kunt overzien. Meeste mensen met wat ervaring zullen hun member variables prefixen of hun arguments.

Het is eigenlijk offtopic, maar goed: Ik ben het niet helemaal met je eens. In simpele setter-methods en simpele constructors gebruik ik zelf altijd this. Ik heb een ongeloofelijke hekel aan die m_, p_, etc prefixen. Prefixen moet je mijns inziens alleen doen volgens de Hongaarse notatie. Dus String met een 's' en een int met een 'i'.

Zelf doe ik nog iets anders maar dat is een beetje te advanced om echt te helpen.

Ik wil dan eigenlijk wel weten wat jij dan doet. Ik ben volledig met je eens dat dat opzoeken ontzettend lelijk is (en bovendien erg traag en foutgevoelig), dus ik hou het gewoon op definieren als private member... Maar als jij een stoerdere methode gebruikt, wil ik het weten

[hobbit_be]

pgussow schreef op 11 juni 2003 @ 14:31:
[...]
Het is eigenlijk offtopic, maar goed: Ik ben het niet helemaal met je eens. In simpele setter-methods en simpele constructors gebruik ik zelf altijd this. Ik heb

tja ieder zijn pleziertje he - hungarian notation is niet met access maar met type (dat ik dan weer liefst postfix-ed zie). Van alle programmeurs die ik ken (en dat zijn vaak betere dan mezelf, die werken in heel professionele env. is er geen 1 die 'this' gebruikt (tenzij ergens in een C++ ctor of dtor). Tis TE fout gevoelig. Tis maar een opmerking. Net zoals ik : ? evil vind of

code:

if (baana) {
}

ie die indentatie - maar das meer persoonlijk.

Ik wil dan eigenlijk wel weten wat jij dan doet.

Ik doe alles via pure XUL zodat ik niet echt aan Swing (geklooi) vast hang. Kun je lekker terwijl het programma draait en je in design mode zit (effe wat trager) gewoon de UI aanpassen. Is al enorm belangrijk gewezen. Ook het koppelen van UI element is volledig MVC (maar dan ook 100%). Waar er wel echt nood aan een private member is (bijvoorbeeld een Jeditorpae die goede HTML spuit) gebruiken we XUL + reflectie zodat we toch nog kunnen designen zonder aan de 'core' te komen.

Het voorval van de poster komt bij ons niet voor omdat we een volledig systeem hebben die van een 'virtuele' classe een perfecte UI bouwt en ook Persistant kan maken etc... Beetje overkill maar als je 80 verschillende forms hebt met 60RDB tabellen (we gebruiken trouwens GEEN SQL dat wordt allemaal leuk gegeneert on the fly (en cached)) is dit geen optie meer. Meeste grote progs werken zo ook (MM spul)