Bestimmtes Edit feld auswählen



  • loos schrieb:

    Selten so gelacht. 😃

    gut, lachen ist gesund

    loos schrieb:

    Absolut nicht resourcenfeindlich und unflexibel.
    Eher wohl die optimale Lösung.
    Dann nimm doch ein Array und du wirst sehen wie unflexibel das ist.

    ok, mal vergleichen:

    int Index = StrToIntDef(Edit->Text,-1);
    if(Index!=-1)
       EditArray[Index]->Visible = true;
    
    for(int i=0; i < Form1->ComponentCount; i++)
    {
       if (Form1->Components[i]->ClassNameIs("TEdit"))
       {
          if(dynamic_cast<TEdit*>(Form1->Components[i])->Name == "Edit"+Edit1->Text)
          {
             dynamic_cast<TEdit*>(Form1->Components[i])->Visible = true;
          }
       }
    }
    

    hmmm.. was denkst du ist weniger CPU-lastig? direkt die Komponente ansprechen oder alle Komponenten auf der Form durchlaufen und immer schön casten?
    was machst du wenn du plötzlich eine Komponete auf der Form hast, die nur von TEdit abgeleitet ist?

    BigNeal



  • Schon ein bissssschen "geschummelt", da der Code um das Array zu erstellen fehlt. Unabhängig von der CPU-Last, die beim Array wohl in jedem Fall günstiger ist.

    Wobei sich noch die Frage stellt einmalig durchnuddeln ok, aber wenn die funktion öfter kommt, ist das ein weiterer Grund für ein Array



  • Da stimme ich dir voll zu BigNeal.
    Mal abgesehen davon, kann man loos Code ein wenig vereinfachen.

    for(int i=0; i < Form1->ComponentCount; i++)
    {
       TEdit *edit = dynamic_cast<TEdit*>(Form1->Components[i]);
       if( edit != 0 && edit->Name == "Edit"+Edit1->Text)
             edit->Visible = true;
    }
    

    Die Array-Lösung ist aber trotzdem besser.



  • Bei einer Anzahl von 1000 Edits auf dem Formular magst du vielleicht recht haben. 😉
    Obwohl du da dann auch erstmal dein Array füllen must.
    Unflexibel ist deine Lösung aber wohl eher, wenn die Anzahl der TEdits flexibel ist. 😉



  • Wenn die TEdits zur Laufzeit erstellt werden, muß man das Array halt anpassen.



  • Braunstein schrieb:

    Wenn die TEdits zur Laufzeit erstellt werden, muß man das Array halt anpassen.

    Was ist umständlicher ?



  • loos schrieb:

    Bei einer Anzahl von 1000 Edits auf dem Formular magst du vielleicht recht haben. 😉
    Obwohl du da dann auch erstmal dein Array füllen must.

    1000 edits erzeugst du sowieso dynamisch, oder willst du die einzeln auf das formular klicken? 😉

    loos schrieb:

    Unflexibel ist deine Lösung aber wohl eher, wenn die Anzahl der TEdits flexibel ist. 😉

    -> DynamicArray

    mfg
    BigNeal



  • BigNeal schrieb:

    -> DynamicArray

    dann aber lieber std::vector



  • loos schrieb:

    Was ist umständlicher ?

    Was soll daran umständlich sein beim Hinzufügen oder Löschen eines Edits das Array anzupassen? Das kann man auch schön in einer Funktion kapseln.



  • Braunstein schrieb:

    BigNeal schrieb:

    -> DynamicArray

    dann aber lieber std::vector

    std::vector ist zwar besser aber trotzdem noch viel zu umständlich.
    Bei einer mal geschätzten Anzahl von vielleicht höchstens 20 Edits ist dieser Aufwand mit normaler Logik nicht mehr zu vertreten.



  • Braunstein schrieb:

    loos schrieb:

    Was ist umständlicher ?

    Was soll daran umständlich sein beim Hinzufügen oder Löschen eines Edits das Array anzupassen? Das kann man auch schön in einer Funktion kapseln.

    Das ist ein Aufwand. Mit Kanonen auf ... 😉



  • Hallo

    @ loos : Nicht wenn man mal an das Laufzeitverhalten denkt. In einem Array wird gezielt zugegriffen. Bei deiner Variante werden jedesmal alle Komponenten bis zum gefundenen durchlaufen. Stell dir das mal bei ein paar Aufrufen pro Sekunde und 200 Komponenten vor.
    Was ist also dagegen einzuwenden, gleich Laufzeit-Optimiert zu schreiben? Oder gehörtst du auch zu den Leuten, die nur bei den Quellcode-Zeilen optimieren wollen?

    bis bald
    akari



  • Zumal die Array Variante auch vom Quellcode her nicht viel größer sein sollte. Ich denke mit 2 Zeilen mehr ist man dabei. Man könnte auch eine std::map nehmen, da wird die Verwaltung und der Zugriff noch einfacher.



  • Stell dir das mal bei ein paar Aufrufen pro Sekunde und 200 Komponenten vor.

    200 Komponenten auf einer Form sind in der Tat schwer vorzustellen. 😉
    Und selbst wenn.
    Aufruf erfolgt nur durch OnButtonClick.

    Was ist also dagegen einzuwenden, gleich Laufzeit-Optimiert zu schreiben? Oder gehörtst du auch zu den Leuten, die nur bei den Quellcode-Zeilen optimieren wollen?

    Ich gehöre zu den Leuten die einschätzen können, welcher Aufwand für eine Lösung vertretbar ist. 😉



  • Ich denke mit 2 Zeilen mehr ist man dabei

    Lol.



  • Hallo

    200 Komponenten auf einer Form sind in der Tat schwer vorzustellen. 😉
    Und selbst wenn.
    Aufruf erfolgt nur durch OnButtonClick.

    Ich habe in meinem aktuellen Projekt eine Form mit einem Texteditor, der ein paar Dutzende Buttons für Formatierungen und sonderfunktionen bietet. Daneben noch ein paar Dutzende nichtvisueller Komponenten wie Actions, Verwaltungsobjekte... da kommen locker 200 Komponenten zusammen.
    Teilweise werden einige der Controls nach jeder kleinsten Änderung an Daten oder Form geupdatet, könnte also sehr häugif sein.
    Es wäre wirklich sehr lahm, um diese Controls zu finden jedesmal über dutzende Controls zu iterieren und einen AnsiString-Vergleich durchzuführen. Stattdessen wird einfach über ein Array in einem Durchgang das richtige ausgewählt.

    Ich gehöre zu den Leuten die einschätzen können, welcher Aufwand für eine Lösung vertretbar ist.

    Aber offenbar nicht zu den Leuten, die sich mit den Hintergründen vorhandener Funktionen oder langfristige Planung auskennen.

    bis bald
    akari



  • Aber offenbar nicht zu den Leuten, die sich mit den Hintergründen vorhandener Funktionen oder langfristige Planung auskennen.

    Schwachsinn.
    Du scheinst zu den Leuten zu gehören, die aus jeder Mücke einen Elefanten machen und so den Bezug zur Realität verlieren.
    Aber anscheinend bist du wohl noch nicht solange dabei ...

    Klink mich jetzt hier aus.
    Kannste weiter rumtrollen. 👎



  • Ok, mal für ne map

    // Typ der map
    std::map<AnsiString,TEdit*> editmap;
    // TEdit hinzufügen
    TEdit *editneu = new TEdit(this);
    // der ganze Rest zum Einfügen
    // und jetzt rein in die map
    editmap[editneu->Name] = editneu;
    
    // löschen aus der map
    editmap.erase(edittoerase->Name);
    

    Klar muß man die map erst füllen, aber das kann man durch einmaligen Aufruf über Components am Anfang machen. Bei Verwendung von vector alternativ mit push_back sowie find/erase. Hier braucht man noch einen sort-Aufruf.



  • loos schrieb:

    Aber anscheinend bist du wohl noch nicht solange dabei ...

    Da wäre ich mir nicht so sicher.

    loos schrieb:

    Kannste weiter rumtrollen.

    Das ist kein getrolle, sondern aus Erfahrung gewonnenes Wissen.

    Ich schließe mich akari und Braunstein an.
    Laut Borland ist die Verwendung der RTTI grundsätzlich mit einem 'performance-hit' verbunden.



  • Da wäre ich mir nicht so sicher.

    Bin ich mir aber. Da so eine Einstellung für die Praxis absolut ungeeignet ist.

    Ich schließe mich akari und Braunstein an.

    Wie war das ? Eine Krähe (geloggter) hackt der anderen ...

    Aber genug. Schon viel zuviel Zeit hier verschwendet.


Anmelden zum Antworten