{"id":1109,"date":"2011-09-04T14:09:49","date_gmt":"2011-09-04T12:09:49","guid":{"rendered":"http:\/\/www.tutego.de\/blog\/javainsel\/2011\/09\/gastbeitrag-awt-schwergewichte-nach-vorne-bitte\/"},"modified":"2011-09-04T14:14:32","modified_gmt":"2011-09-04T12:14:32","slug":"gastbeitrag-awt-schwergewichte-nach-vorne-bitte","status":"publish","type":"post","link":"https:\/\/www.tutego.de\/blog\/javainsel\/2011\/09\/gastbeitrag-awt-schwergewichte-nach-vorne-bitte\/","title":{"rendered":"Gastbeitrag: AWT-Schwergewichte nach vorne, bitte!"},"content":{"rendered":"

Der Code hinter Container.add(Component comp) hat sich immer wieder gewandelt, und lange Zeit war es problematisch, AWT- und Swing-Komponenten zu mischen. Seit Java 7 stellt das AWT jedoch jede m\u00f6gliche Kombination von beliebigen Komponenten zuverl\u00e4ssig dar – den zus\u00e4tzlichen Rechenaufwand bekommt jeder zu sp\u00fcren, der etwa versucht, eine JScrollPane mit 50.000 JLabels zu best\u00fccken.<\/p>\n

<\/p>\n

<\/p>\n

Wenn ich im Folgenden von \u201eKomponenten\u201c rede, meine ich Instanzen von java.awt.Component, der Klasse, die direkt von Object abstammt und die Mutter aller GUI-Elemente ist, egal ob AWT wie schwergewichtig, heavy weight, HW – oder leichtgewichtiges Swing.<\/p>\n

Die z-Reihenfolge der Peers von Javas GUI-Komponenten ist folgenderma\u00dfen definiert:<\/p>\n

    \n
  1. Schwergewichtige Komponenten vor leichtgewichtigen<\/li>\n
  2. Kinder vor Eltern<\/li>\n
  3. Geschwister mit kleinerem Index weiter vorne<\/li>\n<\/ol>\n

    Beispiele:<\/p>\n

      \n
    1. Panel.add(JButton): Panel-Peer im Vordergrund<\/li>\n
    2. Panel.add(Button): Button-Peer im Vordergrund<\/li>\n
    3. Panel.add(Button1); Panel.add(Button2): Button1-Peer im Vordergrund. Nur sichtbar, wenn sich button1 und button2 \u00fcberlappen.<\/li>\n<\/ol>\n

      Die z-Reihenfolge der Komponenten innerhalb eines Containers (Regel 3) entspricht nichts anderem als der Reihenfolge derselben in der internen ArrayList, von der man eine Kopie \u00fcber getComponents() bekommt. Oft ist das zwar auch gleichzeitig die x-y-Reihenfolge, in der der Layoutmanager die Komponenten nebeneinander anordnet, aber grunds\u00e4tzlich k\u00f6nnen s\u00e4mtliche Komponenten unabh\u00e4ngig von ihrer z-Reihenfolge auf dem Bereich des Containers positioniert werden und sich dabei auch \u00fcberlappen.<\/p>\n

      Die Regeln 2 und 3 sind leicht zu realisieren, weil sich die daraus ergebende Sortierung direkt aus der Datenstruktur, welche die AWT-Komponenten bilden, ablesen l\u00e4sst. Kopfzerbrechen bereitet Punkt 1, denn leicht- und schwergewichtige Komponenten k\u00f6nnen in dieser Datenstruktur bunt gemischt vorkommen, und es gilt die Peers der schwergewichtigen Komponenten immer im Vordergrund darzustellen. Davon bekommt der Anwender nichts mit, denn \u00fcber Component.applyCompoundShape() bekommt jede schwergewichtige Komponente vorgeschrieben, welche Bereiche sie von sich aussparen muss, sodass leichtgewichtige Komponenten durchscheinen k\u00f6nnen und der Eindruck entsteht, die HW-Komponente bef\u00e4nde sich mitten unter den leichtgewichtigen. F\u00fcr den Anwender gen\u00fcgen also die Regeln 2 und 3; ihm wird vorget\u00e4uscht, Regel 1 existiere nicht.<\/p>\n

      Wir werden uns im Folgenden nicht damit befassen, den richtigen CompoundShape f\u00fcr eine HW-Komponente zu finden, sondern wir wollen lediglich nachvollziehen, wie der Peer einer HW-Komponente seinen Platz in der z-Reihenfolge findet.<\/p>\n

      Zu Zeiten von Java 6 wurde das Problem noch so gehandhabt, dass beim Hinzuf\u00fcgen einer Komponente ein mehrmaliges Aufrufen von getParent() den j\u00fcngsten schwergewichtigen direkten Vorfahren ermittelte. Von ihm aus wurden dann per Rekursion alle schwergewichtigen Nachkommen zusammengetragen und anhand dieser Liste stellte eine native Methode die Ordnung wieder her.<\/p>\n

      Seit Java 7 hat sich das ge\u00e4ndert. Um in jedem Fall den jeweils allern\u00e4chsten schwergewichtigen Vorfahren ausfindig zu machen, werden nunmehr nicht nur die direkten Vorfahren, sondern auch deren sowie die eigenen Geschwister \u00fcberpr\u00fcft. Doch der Reihe nach.<\/p>\n

      Ein Component c werde einem Container p (wie parent) hinzugef\u00fcgt, welcher schon viele weitere Components enth\u00e4lt und sich seinerseits in der ContentPane eines bereits sichtbar gemachten JFrames befindet:<\/p>\n

        1: p.add(c);<\/pre>\n
      Dabei wird nebst vielem anderen auch die Methode c.addNotify() aufgerufen – soweit ist noch alles beim Alten. Innerhalb von addNotify() hat sich der Code nun etwas ver\u00e4ndert:<\/p>\n
      Java 6: c.parent.peer.restack();
      \n  
      Java 7: c.updateZOrder();<\/p>\n
        1: public<\/span> abstract<\/span> class<\/span> Component\n<\/pre>\n
        2: {\n<\/pre>\n
        3:     void<\/span> updateZOrder() {\n<\/pre>\n
        4:         peer.setZOrder(getHWPeerAboveMe());\n<\/pre>\n
        5:     }\n<\/pre>\n
        6: }<\/pre>\n
      Component.getHWPeerAboveMe() liefert den Peer der n\u00e4chsth\u00f6heren schwergewichtigen Komponente. Das anschlie\u00dfende Ordnen ist gegen die Schnittstellenmethode ComponentPeer.setZOrder() programmiert, die man im sun.awt.NullComponentPeer oder dem sun.awt.windows.WComponentPeer implementiert findet.<\/p>\n
        1: public<\/span> abstract<\/span> class<\/span> WComponentPeer\n<\/pre>\n
        2: {\n<\/pre>\n
        3:     \/**\n<\/pre>\n
        4:      * Handle to native window\n<\/pre>\n
        5:      *\/<\/span>\n<\/pre>\n
        6:     protected<\/span> volatile<\/span> long<\/span> hwnd;\n<\/pre>\n
        7:     \/**\n<\/pre>\n
        8:      * Lowers this component at the bottom of the above component. If the above parameter\n<\/pre>\n
        9:      * is null then the method places this component at the top of the Z-order.\n<\/pre>\n
       10:      *\/<\/span>\n<\/pre>\n
       11:     public<\/span> void<\/span> setZOrder(ComponentPeer above) {\n<\/pre>\n
       12:         long<\/span> aboveHWND = (above != null<\/span>) ? ((WComponentPeer)above).getHWnd() : 0;\n<\/pre>\n
       13:         setZOrder(aboveHWND);\n<\/pre>\n
       14:     }\n<\/pre>\n
       15:     private<\/span> native<\/span> void<\/span> setZOrder(long<\/span> above);\n<\/pre>\n
       16: }\n<\/pre>\n
       17: public<\/span> class<\/span> NullComponentPeer\n<\/pre>\n
       18: {\n<\/pre>\n
       19:     public<\/span> void<\/span> setZOrder(ComponentPeer above)\n<\/pre>\n
       20:     {\n<\/pre>\n
       21:     }\n<\/pre>\n
       22: }<\/pre>\n
      Die Methode setZOrder() ist bei den NullComponentPeers, die von den Swing-Komponenten benutzt werden, als leerer Block implementiert – das Ergebnis der im Folgenden beschriebenen Sucherei wird also beim Hinzuf\u00fcgen einer leichtgewichtigen Komponente gar nicht verwendet. Trotzdem f\u00fchrt getHWPeerAboveMe() immer die vollst\u00e4ndige Suche durch.
      \n  
      Wir gehen jetzt von der Annahme aus, dass im Moment alles in Ordnung ist, dass also s\u00e4mtliche schwergewichtigen Peers vorne sind und alle leichtgewichtigen hinten. Wir m\u00fcssen nur den Peer der neu hinzukommenden Komponente c an der richtigen Stelle einordnen. Angenommen, c ist schwergewichtig. Sein Peer muss also "vorgezogen" werden in die Gruppe der HW-Peers – aber zwischen welche beiden? Um das herauszufinden, gibt es zwei M\u00f6glichkeiten:<\/p>\n
      a) Man hangelt sich anhand von Regel 2 und 3 von der neuen Komponente c nach hinten durch, bis man eine schwergewichtige Komponente findet. Vor<\/em> dem Peer dieser Komponente wird dann c.peer eingeordnet. Findet man keine schwergewichtige Komponente, so kommt c.peer hinter den hintersten HW-Peer und ist damit immer noch vor allen leichtgewichtigen.<\/p>\n
      b) Man hangelt sich anhand von Regel 2 und 3 von c nach vorne durch, bis man eine schwergewichtige Komponente findet und ordnet c.peer dann entsprechend hinter<\/em> dem Peer dieser Komponente ein oder ganz vorne, wenn c die einzige HW-Komponente ist.<\/p>\n
      In Java ist letzteres implementiert. Zun\u00e4chst wird ausfindig gemacht, welchen Index die Komponente c in p bekommen hat: p.getComponentZOrder(c), was in p.component.indexOf(c) resultiert. In unserem Beispiel wurde c einfach per p.add(c) eingef\u00fcgt und hat somit den Index p.getComponentCount()-1.<\/p>\n
      Mittels diesem Index i erreicht man nun die Komponente, die in der z-Reihenfolge die n\u00e4chste Komponente in Richtung Vordergrund ist: p.getComponent(i-1). Ist sie leichtgewichtig, wird p.getComponent(i-2) ausprobiert usw. bis zu p.getComponent(0), der vordersten Komponente des Containers p. Genauso wird dann noch mit jedem Vorfahren von p verfahren, bis man endlich auf eine schwergewichtige Komponente st\u00f6\u00dft oder aber auf ein Window, was bedeutet c.peer ist der einzige HW-Peer und kommt ganz nach vorne.<\/p>\n
        1: public<\/span> abstract<\/span> class<\/span> Component\n<\/pre>\n
        2: {\n<\/pre>\n
        3:     final<\/span> int<\/span> getSiblingIndexAbove()\n<\/pre>\n
        4:     {\n<\/pre>\n
        5:         Container parent = getParent();\n<\/pre>\n
        6:         if<\/span> (parent == null<\/span>) {\n<\/pre>\n
        7:             return<\/span> -1;\n<\/pre>\n
        8:         }\n<\/pre>\n
        9:         return<\/span> parent.getComponentZOrder(this<\/span>) - 1;\n<\/pre>\n
       10:     }\n<\/pre>\n
       11:     final<\/span> ComponentPeer getHWPeerAboveMe()\n<\/pre>\n
       12:     {\n<\/pre>\n
       13:         Container cont = getParent();\n<\/pre>\n
       14:         int<\/span> indexAbove = getSiblingIndexAbove();\n<\/pre>\n
       15:         while<\/span> (cont != null<\/span>) {\n<\/pre>\n
       16:             for<\/span> (int<\/span> i = indexAbove; i > -1; i--) {\n<\/pre>\n
       17:                 Component comp = cont.getComponent(i);\n<\/pre>\n
       18:                 if<\/span> (comp != null<\/span> && !comp.isLightweight()) {\n<\/pre>\n
       19:                     return<\/span> comp.getPeer();\n<\/pre>\n
       20:                 }\n<\/pre>\n
       21:             }\n<\/pre>\n
       22:             indexAbove = cont.getSiblingIndexAbove();\n<\/pre>\n
       23:             cont = cont.getParent();\n<\/pre>\n
       24:         }\n<\/pre>\n
       25:         return<\/span> null<\/span>;\n<\/pre>\n
       26:     }\n<\/pre>\n
       27: }<\/pre>\n
      Wer nun viele Komponenten hintereinander mit p.add(c) hinzuf\u00fcgt, verursacht einen quadratischen Anstieg dieser Suchvorg\u00e4nge, weil man so die neuen Komponenten immer hinten einf\u00fcgt und dann jedes Mal alle vorherigen abklappern muss.<\/p>\n
      Wenn man keine ma\u00dfgeschneiderten \u00dcberlappungen von Komponenten innerhalb eines Containers braucht, kann man die Suche abk\u00fcrzen, indem man auf p.add(c,0) umsteigt. Die hinzukommenden Kopiervorg\u00e4nge von p.component, der internen ArrayList vom Container p, fallen dabei nicht so sehr ins Gewicht.<\/p>\n
      Wer au\u00dferdem keine schwergewichtigen Komponenten in den Container p packen will, kann stattdessen folgendes Konstrukt einsetzen und umgeht damit s\u00e4mtliche der beschriebenen Vorg\u00e4nge f\u00fcr diesen Container.<\/p>\n
        1: p = new<\/span> Container()\n<\/pre>\n
        2: {\n<\/pre>\n
        3:     @Override\n<\/pre>\n
        4:     public<\/span> int<\/span> getComponentZOrder(Component comp) {\n<\/pre>\n
        5:         return<\/span> 0;\n<\/pre>\n
        6:     }\n<\/pre>\n
        7: };<\/pre>\n
       <\/p>\n
      Ein ausgezeichneter Beitrag von Daniel Frisch<\/strong>. Danke! Und an der Stelle noch einmal der Hinweis, das ich in dem Blog gerne Gastbeitr\u00e4ge poste.<\/p>\n","protected":false},"excerpt":{"rendered":"
      Der Code hinter Container.add(Component comp) hat sich immer wieder gewandelt, und lange Zeit war es problematisch, AWT- und Swing-Komponenten zu mischen. Seit Java 7 stellt das AWT jedoch jede m\u00f6gliche Kombination von beliebigen Komponenten zuverl\u00e4ssig dar – den zus\u00e4tzlichen Rechenaufwand bekommt jeder zu sp\u00fcren, der etwa versucht, eine JScrollPane mit 50.000 JLabels zu best\u00fccken.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","_links_to":"","_links_to_target":""},"categories":[64,10],"tags":[],"class_list":["post-1109","post","type-post","status-publish","format-standard","hentry","category-gastbeitrag","category-swing"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts\/1109","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/comments?post=1109"}],"version-history":[{"count":1,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts\/1109\/revisions"}],"predecessor-version":[{"id":1110,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts\/1109\/revisions\/1110"}],"wp:attachment":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/media?parent=1109"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/categories?post=1109"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/tags?post=1109"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}