Blackberry - Aktualisierung Siebwechsel Zeichnungs Reihenfolge des Managers seiner Feldelemente

Question

Szenario
In einem Bildschirm habe ich 2 Manager: 1) Menü-Manager an der Spitze und 2) Körper-Manager, die info Taste/Elemente. Der Menü-Manager führt benutzerdefinierte Zeichnung aus, so dass seine Menüelemente (LabelFields) ordnungsgemäß voneinander getrennt sind.

Kernthema - Manager-und Unterfeld Zeichnungsreihenfolge
Der Bildschirm zieht in Ordnung, außer, wenn der Benutzer Vorformen eine Aktion (eine Schaltfläche klickt), die in einem Element führt den Körper Manager withing hinzugefügt/entfernt. Sobald Feldelemente dem Körper hinzugefügt/entfernt werden, wird die Reihenfolge, in der das Menü gezeichnet wird, durcheinandergebracht.

Wenn der Körper-Manager hinzufügt oder entfernt ein Feld, anstelle des Menüs Manager selbst zeichnen und dann seine Unterelemente (Beschriftungsfelder), der Menümanager beginnt seine Unterelemente zu zeichnen und dann selbst; So malt man oben auf die Etikettenfelder und lässt sie aussehen, als wären sie verschwunden.

Kommentare
bereits versucht invalidate und andere Optionen - Ich habe versucht, ungültig zu nennen, invalidateAll, anzeigeAktualisieren ... nach dem Hinzufügen/Entfernen von Feldelementen aus Körper. Alles ohne Erfolg.

Entfernen von benutzerdefinierten Unterlayouts funktioniert - die einzige Möglichkeit, das Problem zu lösen, ist das Entfernen der benutzerdefinierten Unterlayoutlogik für Menümanager. Leider zeichnet das Menüsystem auf herkömmliche Weise und bietet nicht genügend Abstand.

Im Folgenden wird der sublayout Code für das Menü-Manager, bin ich etwas fehlt hier?

public void sublayout(int iWidth, int iHeight) 
{ 
    final int iNumFields = getFieldCount(); 
    int maxHeight = 0; 


    final int segmentWidth = iWidth/iNumFields; 
    final int segmentWidthHalf = segmentWidth/2; 

    for (int i = 0; i < iNumFields; i++) 
    { 
     final Item currentField = (Item)this.getField(i); 

     // 1. Use index to compute bounds of the field 
     final int xSegmentTrueCenter = segmentWidth * i + segmentWidthHalf; 

     // 2. center field inbetween bounds using field width (find fill width of text) 
     final int xFieldStart = xSegmentTrueCenter - currentField.getFont().getAdvance(currentField.getText())/2; 

     // set up position 
     setPositionChild(currentField, xFieldStart, getContentTop() + MenuAbstract.PADDING_VERTICAL); 

     // allow child to draw itself 
     layoutChild(currentField, iWidth, currentField.getHeight()); 


     // compute max height of the field 
     //int fieldheight = currentField.getHeight(); 
     maxHeight = currentField.getHeight() > maxHeight 
      ? currentField.getHeight() + 2 * MenuAbstract.PADDING_VERTICAL 
      : maxHeight; 
    } 
    this.setExtent(iWidth, maxHeight); 
} 

Schluss Fragen
Letztlich möchte ich das benutzerdefinierte Layout des Menü-Manager halten, während Feldelemente neu zu zeichnen zu dürfen. Hier sind meine letzten Fragen:

1. Haben Sie das schon einmal erlebt?

2. Warum beginnt der Menü-Manager in der falschen Reihenfolge zu zeichnen, wenn ein Feldelement zum Bildschirm hinzugefügt/entfernt wird?

3. Tut das native ManagerSlayout() etwas, das ich Zeichnungsreihenfolge nicht beibehalten soll?

Answer 1

Ich habe nicht das Verhalten, das Sie beschreiben gesehen, aber die folgende Zeile ist ein wenig beunruhigend:

// allow child to draw itself 
layoutChild(currentField, iWidth, currentField.getHeight()); 

getHeight() sollte einen vernünftigen Wert nicht zurück, bis das Feld SetExtent hatte genannt durch die layoutChild-Methode. Obwohl ich erwarte, dass es in allen Fällen Probleme verursachen würde - nicht sicher, warum das beim ersten Mal funktionieren würde. In Ihrer Logik denke ich, dass Sie einfach nur iHeight anstelle von currentField.getHeight() in dieser Zeile verwenden können. Das Feld wird nur so groß wie es sein muss - es wird nicht alles von iHeight verwenden, es sei denn, es ist so etwas wie ein VerticalFieldManager