[Java Swing] repaint toplevel containers

[Nexopheus]

Ik heb het volgende "Rare" probleem.

Binnen een JFrame heb een aantal JPanels. Deze panels worden gebruikt binnen mijn implementatie van het mvc-pattern. Er is dus een controlpanel en er is een viewPanel (2 eingelijk).

Wanneer ik een update veroorzaak mbv het controlpanel (button click ) dan repaint het JFrame niet goed. De boel verschuift en de oude componenten worden niet "weggehaald". Wanneer ik het frame minimaliseer en daarna weer zichtbaar maak is het wel goed.

Is dit een bug, of doe ik iets niet goed?

ter illustratie:
voor:


na:

[Alarmnummer]

Ik zou voor een 3d systeem enorm oppassen met mvc ivm alle overhead die er is. En verder heb ik er zelf nog nooit problemen mee gehad. Je kan de Graphics van de JPanel opvragen en daar teken je 1 keer in de zoveel tijd op.

[Nexopheus]

Is niet een 3D systeem.
[moet een figuur in 2D laten roteren]

Ik gebruik ook het Graphics object van het JPanel

Java:

public void paintComponent(Graphics g){        
        g.setColor(color);
        if(transformedScreenMatrix != null){
            g.drawPolygon(transformedScreenMatrix[0],transformedScreenMatrix[1],transformedScreenMatrix[0].length);
        }else {
            g.drawString(" Draw a structure first! ",10,30);
        }
        
             
    }

[Alarmnummer]

Je moet wel de super ff aanroepen denk ik

En volgens mij moet je de paint overriden (en niet de paintComponent). Maar ik ben verder ook niet thuis in graphics.

[Nexopheus]

Je moet wel de super ff aanroepen denk ik

Gebeurt dan niet impliciet?

En volgens mij moet je de paint overriden (en niet de paintComponent). Maar ik ben verder ook niet thuis in graphics.

Geeft hetzelfde resultaat! [had ik al geprobeerd]

[Alarmnummer]

Nexopheus schreef op 26 February 2003 @ 14:22:
Gebeurt dan niet impliciet?

nope Althans niet met de paint.

[momania]

En een validate op je JFame helpt ook niets?

[Nexopheus]

Ik heb nu bij elk component

Java:

super();

toegevoegd, maar geeft nogsteeds ellende!

[Nexopheus]

De Panels hebben geen kennis van het JFrame, en dat wil ik ook graag zo houden.

[Alarmnummer]

momania schreef op 26 February 2003 @ 14:26:
En een validate op je JFame helpt ook niets?

Als je component klaar is met renderen, kan je er gewoon een repaint op aanroepen (als dat nodig is). Dan wordt automatisch die paint wel aangeroepen.

En verder vind ik het vreemd dat er oud spul blijft staan. Laat je code eens zien (dus met die paint en super)


en je moet super.paint(g) doen.

[ Voor 6% gewijzigd door Alarmnummer op 26-02-2003 14:41 ]

[YaPP]

Wat dacht je van

Java:

public void paintComponent(Graphics g) {
  super.paintComponent(g);

  // en nu de rest... :-p
}

Dat lijkt me iets handiger dan een super-contructor aanroepen
De eerste aanroep laat je 'super' (dus uiteindelijk je JPanel) zichtzelf tekenen, daarboven teken jij jezelf weer.. zo word het scherm gewist. e.d.

En natuurlijk gaat dat niet automatisch, omdat je zelf in je OOP code kan beslissen of je iets volledig wilt overschrijven, of een kleine aanpassing wilt maken, en daarvoor op een bepaald moment de super/base class aanroept.

Het aanroepen van een this(...) en super(...) gebruik je om een constructor aan te roepen, en die aanroepen mogen alleen op de eerste regel van je eigen contructor (super iig wel, this(..) weet ik niet zeker)

paint() moet je overriden met AWT, swing heeft daar al dingen instaan, en heeft zijn eigen paintComponent()


Een Java 2D/3D applicatie met een MVC design pattern kan best wel.. Sommige groepen bij mij op school hebben een 3D-draadmodel Java programma gemaakt in het 2e semester, en sommige proggies deden het echt erg goed...

Hoe implementeer je overgens het MVC pattern? Met de java.beans.PropertyChangeSupport class? :-/ of heb je je eigen aanpak?

[ Voor 2% gewijzigd door YaPP op 26-02-2003 14:43 . Reden: typoos ]

[Alarmnummer]

YaPP schreef op 26 February 2003 @ 14:41:
Wat dacht je van

Een Java 2D/3D applicatie met een MVC design pattern kan best wel.. Sommige groep hebben een 3D-draadmodel Java programma gemaakt in het 2e semester, en sommige dingen deden het echt erg goed...

Hoe implementeer je overgens het MVC pattern? Met de java.beans.PropertyChangeSupport class? :-/ of heb je je eigen aanpak?

Je moet dan wel oppassen dat niet iedere point een observable is

[Nexopheus]

MVC: met observers

En nee, niet ieder point is een observer!

OK WERKT!!!!

Java:

super.paintComponent(g);

is inderdaad de oplossing!

[ Voor 42% gewijzigd door Nexopheus op 26-02-2003 14:45 ]

[momania]

YaPP schreef op 26 February 2003 @ 14:41:
Hoe implementeer je overgens het MVC pattern? Met de
java.beans.PropertyChangeSupport class? :-/ of heb je je eigen aanpak?

Hier heb je wel een simpel begin: http://www.javaworld.com/...-04-1998/jw-04-howto.html

De PropertyChangeSupport i.c.m. de PropertyChangeEvents heb ik zelf verders geen goede evraringen mee. Het is een beetje omslachtige manier van eventhandeling vind ik en bij grotere applicaties raak je het overzicht een beetje kwijt van je events en gaan er vaak dingen naast elkaar lopen waarvan je dat helemaal niet wilt.

[Alarmnummer]

check anders deze maar eens:

http://www.rint.rechten.rug.nl/images/peter/graphics.tar.gz

Oja.. is een 2d/3d engine voor school. 2d en 3d is verder detail gedrag en kan er mbv stratagies en parametrisatie aan toegevoegd worden. 1 en 4d ben ik verder maar niet aan begonnen Was/is een opdracht voor school, maar is nog niet klaar;)

[ Voor 60% gewijzigd door Alarmnummer op 26-02-2003 14:58 ]

[Nexopheus]

Hier mijn raamwerkje:
Model:

Java:

public class Model extends Observable{
    
    public void addView(Observer observer){
        if(obj!=null)this.addObserver(observer);
    }
    
    public synchronized void notifyView(){
        setChanged();
        notifyObservers(/*Info-object hier*/);
        clearChanged();
    }
}

View:

Java:

public class View extends Canvas implements Observer{
    public void update(Observable o, Object arg){
        //Doe wat met arg!
        repaint();
    }
}

Control:

Java:

public class Control { //extends Panel oid!
    
    //Widgets toevoegen!
    private Model m;
    public Control(Model m){
        this.m = m;
    }    
    
}

In applicatie:

Java:

view1 = new View();
view2 = new View();
model = new Model();
model.addView(view1);
model.addView(view2);
controller = new Controller(model);

[Nexopheus]

Alarmnummer schreef op 26 February 2003 @ 14:56:
check anders deze maar eens:

http://www.rint.rechten.rug.nl/images/peter/graphics.tar.gz

Oja.. is een 2d/3d engine voor school. 2d en 3d is verder detail gedrag en kan er mbv stratagies en parametrisatie aan toegevoegd worden. 1 en 4d ben ik verder maar niet aan begonnen Was/is een opdracht voor school

mmm, generics, erg leuk maar even geen tijd voor!

offtopic:
RUG? --> heb je ook de HIO gedaan in Gr?

[ Voor 7% gewijzigd door Nexopheus op 26-02-2003 15:00 ]

[YaPP]

momania schreef op 26 February 2003 @ 14:47:
[...]

Hier heb je wel een simpel begin: http://www.javaworld.com/...-04-1998/jw-04-howto.html

De PropertyChangeSupport i.c.m. de PropertyChangeEvents heb ik zelf verders geen goede evraringen mee. Het is een beetje omslachtige manier van eventhandeling vind ik en bij grotere applicaties raak je het overzicht een beetje kwijt van je events en gaan er vaak dingen naast elkaar lopen waarvan je dat helemaal niet wilt.

Nou... Dat bedoelde ik niet helemaal Ik heb zelf ook veel gewerkt met MVC, dus ik weet wel wat het is (in plaats van 'je' had er beter 'jij' kunnen staan) Maar ik heb altijd de PropertyChangeSupport gebruikt, en dat werkt volgens mij best, toegeven, echt 'vanzelfsprekend' is die API niet.

Maar, als je een stel links hebt naar alternatieven voor de PropertyChangeSupport class hoor ik het graag.

Wel enkele aandachtspunten voor goed MVC gebruik met de PropertyChangeSupport class:

• Maak gewoon een 'base' class waar ieder model-component van erft. Die class gebruikt intern een PropertyChangeSupport, en implementeerd alle addPropertyListener ,e.d. tot en met je eigen firePropertyChange methoden. (voor booleans, ints, e.d.)
• Stuur niet direct een string door als property-name, maar declareer ergens een aantal "public static final String CHANGED_???" constanten. Als je die overal gebruikt, kan je ineens de getPropertyName() waarde vergelijken met de == operator.
• Zorg voor een "admin/manager" class die alles beheerd (of igg een logisch gedeelte), en laat alles in je programma daarvan gebruik maken.

Met die aanpak heb ik nog nergens echt last van gehad, en MVC is wel een erg mooie manier van Gui-event/update handling.

[ Voor 4% gewijzigd door YaPP op 26-02-2003 15:02 ]

[YaPP]

Alarmnummer schreef op 26 February 2003 @ 14:56:
check anders deze maar eens:

http://www.rint.rechten.rug.nl/images/peter/graphics.tar.gz

(...)

eh... een paar vraagjes: (ik heb er ff heel snel doorheen gekeken)

Wat moet deze code voorstellen? Dat "List<P>" doet me erg denken aan C++, maar lijkt geen Java! (de JDK 1.3 van Sun kan het iig niet compileren)

Java:

public interface Model<P extends Point>{

    /**
     * Returns a List with all Points in this Model.
     */
    public List<P> getPointList();

    /**
     * Returns a List with all Visuals in this Model.
     */
    public List<Visual> getVisuals();
}

- Hoe moet ik het zaakje compileren? Ik heb niet veel ervaring met het werken in packages (omdat het mij in 'javac' veel problemen gaf), dus kan iemand me helpen. Welk programma gebruikt die XML-file in je 'root'?

---

Ik zag hier en daar ook nog een 'Observer' class in dit forum...
Ik zie dat de observer in JDK1.0 beschikbaar was.. Kan iemand uitleggen hoe dit zit? Waarom zijn de PropertyChangeSupport/PropertyChangeListener/PropertyChangeEvent (java.beans) classes uitgevonden? Om de Observer/Observable (java.util) te vervangen of is er iets anders mee?

[Nexopheus]

De < > tags in de code van Alarmnummer zijn "Generics", templates in Java. Zijn alleen beschikbaar als Early Access add-on (zie www.java.sun.com).

Geen idee overigens wat betreft de PropertyChangeSupport ed. Wellicht een hogere mate van abstractie?

Hier: http://developer.java.sun...ticles/releases/generics/

[ Voor 19% gewijzigd door Nexopheus op 26-02-2003 15:23 ]

[Alarmnummer]

YaPP schreef op 26 February 2003 @ 15:01:
• Maak gewoon een 'base' class waar ieder model-component van erft. Die class gebruikt intern een PropertyChangeSupport, en implementeerd alle addPropertyListener ,e.d. tot en met je eigen firePropertyChange methoden. (voor booleans, ints, e.d.)

ruikt meer naar codegeneratie Ik ben bezig met een generator voor domein objecten die automatisch propertychangesupport genereerd. Bespaard je dit soort lelijke kunstgrepen.

• Zorg voor een "admin/manager" class die alles beheerd (of igg een logisch gedeelte), en laat alles in je programma daarvan gebruik maken.
[/quote[
Met die aanpak heb ik nog nergens echt last van gehad, en MVC is wel een erg mooie manier van Gui-event/update handling.

Nog een punt van aandacht. De propertychangesupport van Sun sucks big time, omdat er geen mogelijkheid is om listeners mbv een weakReference toe te voegen, met als gevolg dat je een memory leak hebt.

Je moet dus altijd je listeners afmelden, en aangezien in java geen destructor structuur zit, moet je altijd weer op onhandige manieren dit gaan oplossen.

Ik heb zelf een oa een propertychangesupport gemaakt waar je listeners optioneel met een weakReference kan toevoegen. Daarnaast heb ik ook changeSupport voor list,set en map gemaakt. Ik zal het binnenkort op mijn site zetten (die krijg op dit moment grote opknap beurt)

[ Voor 7% gewijzigd door Alarmnummer op 26-02-2003 15:41 ]

[YaPP]

Alarmnummer schreef op 26 February 2003 @ 15:40:
[...]
ruikt meer naar codegeneratie Ik ben bezig met een generator voor domein objecten die automatisch propertychangesupport genereerd. Bespaard je dit soort lelijke kunstgrepen.

Nou maar 1 base class hoor? Een generator schrijven kost meer moeite (imo)

Alarmnummer schreef op 26 February 2003 @ 15:40:
Nog een punt van aandacht. De propertychangesupport van Sun sucks big time, omdat er geen mogelijkheid is om listeners mbv een weakReference toe te voegen, met als gevolg dat je een memory leak hebt.

OK, dat vind ik een HEEEL goed punt! Daar heb ik veel gedonder mee gehad in ons grote-eindproject vorig jaar.. Veel leraren letten alleen niet echt op tijdens een demo (dat is soms wel voordelig, tenzij je echt veel werk hebt gestoken in je programma

ik hoor het graag als je een stuk code hebt..!

[Alarmnummer]

Je wilt niet altijd van een baseclass extenden. Ok.. het is ook maar een convience class en geen verplichte class. En een generator schrijven kost wel wat tijd, maar domein objecten schrijven (iedere keer opnieuw) kost ook veel tijd en bijster interessant zijn ze niet. Verder kan je eenvoudig propertychangesupport erin genereren, ze layy maken etc. Maar tis voorlopig maar een experiment en op dit moment heeft mijn site even voorrang. Ik ben nu bezig om alles op te zetten in XML/XSLT en mijn projecten mbv een ANT script eenvoudig kan updaten.