void __fastcall TForm1::Button13Click(TObject *Sender)
{
int x=(StrToInt(Edit22->Text));

Editx->Visible=true;

}

So geht es ntürlich nicht aber ich denke daran sieht man am ehesten was ich meine. Also wäre echt super wenn mir jemand helfen könnte!

siehe BCB-FAQ hier im Forum, Abschnitt Komponenten benutzen.

(Wie oft hab ichd as wohl schon geschrieben?)

bis bald
akari

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;
      }
   }
}

http://www.marquardtnet.info/cecke/quickies.1/1_quicky_17.html

was ihm aber nicht gerade viel bringen wird..
da er einen Pointer auf das Edit bräuchte, was er aber nicht hat. da er ja im OnClick-Event des Buttons auf ein Edit zugreifen will.
und wenn man schon dynamic_cast benutzt sollte man auch den grossen vorteil von dynamic_cast ausnutzen und eine null abfrage machen.

BigNeal

da er einen Pointer auf das Edit bräuchte, was er aber nicht hat. da er ja im OnClick-Event des Buttons auf ein Edit zugreifen will.

Richtig, habe ich nicht gesehen

da er einen Pointer auf das Edit bräuchte, was er aber nicht hat. da er ja im OnClick-Event des Buttons auf ein Edit zugreifen will.

Richtig, habe ich nicht gesehen

genausowenig habt ihr wohl die Lösung gesehen ....

genausowenig habt ihr wohl die Lösung gesehen ....

du meinst die lösung die du gepostet hast?
vor der würde ich auf jeden fall abraten. sie ist sehr resourcenfeindlich und unflexibel.
da würde ich eher ein Array empfehlen.

mfg
BigNeal

sie ist sehr resourcenfeindlich und unflexibel.
da würde ich eher ein Array empfehlen.

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

Edit:
Zitate bitte auf das Notwendigste beschränken. Danke!

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

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

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.

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

Was ist umständlicher ?

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

-> DynamicArray

dann aber lieber std::vector

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.

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.

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 ...

@ 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

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.

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.