ich such' mir mal wieder nen Wolf für ein recht einfaches Problem: Ich habe 16 CheckBox-Komponenten auf einem Formular. Jetzt wollte ich in einer Schleife abfragen, ob diese "checked" sind und dann jeweils eine zugehörige Edit-Komponente manipulieren. Ich finde nur leider keinen Hinweis, wie ich die Komponenten indiziert manipuliere...

So in der Art hatte ich mir das gedacht:

for(i=0; i<=15; i++)
{
    if(CheckBox[i]->Checked==true)
        Edit[i]->Text= "blablubb";
    else
        Edit[i]->Text= "bliblobb";
}

Weiß da vielleicht jemand eine Möglichkeit?

ich habe jetzt schon selbst sehr viel dazu gefunden, zB. auch im Thread "Mehrere CheckBoxen und ListBox Problem?". Ich werde mich bemühen intensiver zu suchen, ich wusste nur in diesem Fall nicht so richtig wonach ich suchen soll... Sorry.

Also Danke nochmal

eine Suche nach ComponentCount (auch in der BCB-Hilfe) müßte hilfreiche Hinweise liefern.

Gruß Udo

Edit2->ComponentIndex= 1;

einen definierten Index innerhalb des Formulars gegeben und kann nun in einer Schleife zB. mit

dynamic_cast<TCheckBox*>(this->Components[i+17])->Checked= true;

in Abhängigkeit vom Wert des Schleifenzählers zugehörige Komponenten manipulieren.
(Kann man das so machen? )
Jetzt wollte ich auf das Auswählen einer von 16 CheckBoxes in einer gemeinsamen Methode reagieren (CheckBoxClick). Wie bekomme ich denn jetzt heraus, welche CheckBox das Ereignis ausgelöst hat? Ich will dann mit dem Wert (zB. 2 für "CheckBox2 hat das Ereignis ausgelöst") das zugehörige Edit2 verändern, bei CheckBox3 Edit3 verändern usw.
Ich hab's probiert mit:

TCheckBox *CheckBoxNachbildung=dynamic_cast<TCheckBox*>(Sender);
unsigned short j= CheckBoxNachbildung->ComponentIndex;

aber beim Zugriff auf das zugehörige Edit mit:

dynamic_cast<TEdit*>(this->Components[j+16])->Enabled= true, Text= "";

entsteht eine exception... Bekommt die CheckBoxNachbildung einen eigenen ComponentIndex oder gar keinen oder wie?

Braunstein schrieb:

Der ComponentIndex wird automatisch festgelegt wenn die Komponente dem Formular zugefügt wird. Den solltest du nicht manipulieren.

Solange es übersichtlich bleibt kann ich das doch theoretisch machen. Warum sollte ich nicht?

Braunstein schrieb:

Wenn du dir Nummern merken willst kannst du dafür die Eigenschaft Tag der Komponente nehmen. Gib also dem Edit und der Checkbox, die zusammengehören die gleiche Tag-Nummern und such die dann beim Aufruf heraus.

Das ist mir jetzt irgendwie zu einfach... Ich bin dummerweise immer davon ausgegangen, dass Tag bool ist, nicht int... Keine Ahnung warum; vielleicht weil es so klingt wie "Flag"
Danke für den Denkanstoss. Ab und an braucht man echt so einen Schubser!

Eine Frage zu einem scheinbar üblichen Verfahren:
Ist es nicht Verschwendung von Rechenzeit (und das spielt bei meinen Programmen auch eine kleine Rolle), wenn folgendes gemacht wird:
Eine for-Schleife mit der Anzahl der Komponenten auf dem Formular als Anzahl der Durchläufe. In der Schleife testen, ob die jeweilige Komponente vom gesuchten Typ ist (per cast und Namensvergleich). Wenn sie es ist, Komponente dynamisch upcasten (richtig?) und Tag überprüfen. Wenn Tag stimmt, gecastete Komponente manipulieren. ???
Ich finde das recht aufwendig, besonders wenn ich ein paar mehr Komponenten auf meinem Formular habe!?

Solange es übersichtlich bleibt kann ich das doch theoretisch machen. Warum sollte ich nicht?

Weil diese Eigenschaft nicht dazu gedacht ist. Es ist nicht klar was deine Zuweisungen für Auswirkungen hat

BCB-Hilfe schrieb:

ComponentIndex wird intern für iterative Zuweisungsprozeduren verwendet.

Ist es nicht Verschwendung von Rechenzeit (und das spielt bei meinen Programmen auch eine kleine Rolle), wenn folgendes gemacht wird:
Eine for-Schleife mit der Anzahl der Komponenten auf dem Formular als Anzahl der Durchläufe. In der Schleife testen, ob die jeweilige Komponente vom gesuchten Typ ist (per cast und Namensvergleich). Wenn sie es ist, Komponente dynamisch upcasten (richtig?) und Tag überprüfen. Wenn Tag stimmt, gecastete Komponente manipulieren. ???
Ich finde das recht aufwendig, besonders wenn ich ein paar mehr Komponenten auf meinem Formular habe!?

Richtiug, deshalb rate ich auch davon ab. Solche Sammlungen von Komponenten sollten gleich in einem eigenen, passenden, eventuell dynamischen Array verwaltet werden. Dann muß man weder unnütz iterieren, noch unnütz casten.
Dieses Vorgehen wird in den genannten FAQ-Einträgen ja auch erklärt.

bis bald
akari

Braunstein schrieb:

Der ComponentIndex wird automatisch festgelegt wenn die Komponente dem Formular zugefügt wird. Den solltest du nicht manipulieren.

ich schrieb:

Solange es übersichtlich bleibt kann ich das doch theoretisch machen. Warum sollte ich nicht?

akari schrieb:

Weil diese Eigenschaft nicht dazu gedacht ist. Es ist nicht klar was deine Zuweisungen für Auswirkungen hat

BCB-Hilfe schrieb:

ComponentIndex wird intern für iterative Zuweisungsprozeduren verwendet.

Versteht mich bitte nicht falsch in meiner Unwissenheit - also: Wenn ComponentIndex nicht manipuliert werden darf, wäre er doch für uns Nutzer nicht manipulierbar (read only)!? Bei anderen Eigenschaften ist es doch auch so... Im Zitat aus der Hilfe steht nicht, dass ComponentIndex nicht manipuliert werden sollte.
Wenn ich selbst Indizes zuweise, was soll passieren, außer dass ich sie kenne? Ich stelle mir das so vor: BCB schaut nach den Komponenten und bereits vergebenen Indizies (ich habe sie gleich im Aufruf der Main-Form manipuliert) und vergibt dann an die verbleibenden Komponenten ohne Index freie Indizes. Was soll da schief gehen?
Tja, und was "iterative Zuweisungsprozeduren" sind, müsste ich mich erstmal schlau machen...

akari schrieb:

Solche Sammlungen von Komponenten sollten gleich in einem eigenen, passenden, eventuell dynamischen Array verwaltet werden. Dann muß man weder unnütz iterieren, noch unnütz casten.
Dieses Vorgehen wird in den genannten FAQ-Einträgen ja auch erklärt.

Okay, bin gewissermaßen schon wieder zu den FAQ unterwegs.

Wenn ich selbst Indizes zuweise, was soll passieren, außer dass ich sie kenne? Ich stelle mir das so vor: BCB schaut nach den Komponenten und bereits vergebenen Indizies (ich habe sie gleich im Aufruf der Main-Form manipuliert) und vergibt dann an die verbleibenden Komponenten ohne Index freie Indizes. Was soll da schief gehen?

Die Inidizes müsse ja fortlaufend sein (sonst kann man ja nicht darüber iterieren). Wenn du also einen bereits vergebenen Index zuweisen willst, ändert sich die ganze Anordnung. Du weißt aber nicht wie. D.h. nach mehreren Zuweisungen kann der erste von dir vergebene Index intern schon wieder geändert sein. Das kann also schief gehen.

Versteht mich bitte nicht falsch in meiner Unwissenheit - also: Wenn ComponentIndex nicht manipuliert werden darf, wäre er doch für uns Nutzer nicht manipulierbar (read only)!? Bei anderen Eigenschaften ist es doch auch so... Im Zitat aus der Hilfe steht nicht, dass ComponentIndex nicht manipuliert werden sollte.

Das stimmt grundsätzlich.

Wenn ich selbst Indizes zuweise, was soll passieren, außer dass ich sie kenne? Ich stelle mir das so vor: BCB schaut nach den Komponenten und bereits vergebenen Indizies (ich habe sie gleich im Aufruf der Main-Form manipuliert) und vergibt dann an die verbleibenden Komponenten ohne Index freie Indizes. Was soll da schief gehen?

Leider ist nicht klar ob es wirklich so ist. Es könnte genauso gut sein das du durch das Setzen des ComponentIndex intern die Verwaltungsstruktur durcheinander bringst, mit Auswirkungen die vielleicht erst unter gewissen Umständen sich bemerkbar machen.
/Edit : Und natürlich Braunsteins Einwand : Mit dem setzen von ComponentIndex kannst du maximal eine Reihe festmachen. Wenn du aber zwei oder mehr verschiedene Sammlungen von Arrays willst, wirst du dir dann selber die Indexe verschieben.

Tja, und was "iterative Zuweisungsprozeduren" sind, müsste ich mich erstmal schlau machen...

Ein Schleife die für alle Komponenten eine bestimmte Methode aufruft.

bis bald
akari

ich schrieb:

Tja, und was "iterative Zuweisungsprozeduren" sind, müsste ich mich erstmal schlau machen...

akari schrieb:

Eine Schleife die für alle Komponenten eine bestimmte Methode aufruft.

Danke. Super, sowas mache ich ja schon... Ich habe mir somit die Hände gewaschen und hinterher gelernt, dass es "Hygene" heißt

Hier jetzt mal meine, inzwischen fertiggestellte, Ereignisbehandlungsmethode /~routine:

void __fastcall TForm4::CheckBoxClick(TObject *Sender)
{
	unsigned short j= dynamic_cast<TCheckBox*>(Sender)->Tag;
	unsigned short k;

	for(k=0; k < (Form4->ComponentCount-1); )
	{
		if((this->Components[k]->ClassNameIs("TEdit")) && (dynamic_cast<TEdit*>(this->Components[k])->Tag==j))
		{
			TEdit *VirtualEdit= dynamic_cast<TEdit*>(this->Components[k]);

			if(!VirtualEdit->Enabled)
				VirtualEdit->Enabled= true;
			else
			{
				VirtualEdit->Enabled= false;
				VirtualEdit->Text= "0";
			}
			k= Form4->ComponentCount - 1;	// Schleifenabbruch herbeiführen
		}
        else	k++;
	}
}

Ist doch im Prinzip auch eine iterative Zuweisungsoperation?

Dazu noch eine Frage: Ist diese Version besser oder schlechter als die Obige?:

void __fastcall TForm4::CheckBoxClick(TObject *Sender)
{
	unsigned short j= dynamic_cast<TCheckBox*>(Sender)->Tag;
	unsigned short k;

	for(k=0; k < (Form4->ComponentCount-1); )
	{
		if((this->Components[k]->ClassNameIs("TEdit")) && (dynamic_cast<TEdit*>(this->Components[k])->Tag==j))
		{
			if(!dynamic_cast<TEdit*>(this->Components[k])->Enabled)
				dynamic_cast<TEdit*>(this->Components[k])->Enabled= true;
			else
			{
				dynamic_cast<TEdit*>(this->Components[k])->Enabled= false;
				dynamic_cast<TEdit*>(this->Components[k])->Text= "0";
			}
			k= Form4->ComponentCount - 1;	// Schleifenabbruch herbeiführen
		}
        else	k++;
	}
}

Und wenn, warum ist die Eine besser als die Andere?

dynamic_cast ist immer eine Laufzeit-Überprüfung. Damit sollte man es so wenig wie möglich aufrufen. Und wenn du dynamic_cast einsetzt, brauchst du auch kein ClassName mehr Also ungefähr so

void __fastcall TForm4::CheckBoxClick(TObject *Sender)
{
    unsigned short j= dynamic_cast<TCheckBox*>(Sender)->Tag;
    unsigned short k;

    for(k=0; k < (Form4->ComponentCount-1); k++)
    {
        TEdit *VirtualEdit= dynamic_cast<TEdit*>(this->Components[k]);
        if (VirtualEdit)
        {

            if(!VirtualEdit->Enabled)
                VirtualEdit->Enabled= true;
            else
            {
                VirtualEdit->Enabled= false;
                VirtualEdit->Text= "0";
            }
            break;    // Schleifenabbruch herbeiführen
        }
    }
}

Allerdings wäre es noch besser wenn du die Variante aus der FAQ nimmst die mit einem eigenen DynamicArray arbeitet.

bis bald
akari

...wenn du dynamic_cast einsetzt, brauchst du auch kein ClassName mehr...

Ahh, verstehe... Und zwar wegen:

BCB-Hilfe schrieb:

... Wenn die Umwandlung durchgeführt werden kann, so wandelt der Ausdruck dynamic_cast< T > (ptr) den Zeiger ptr in den gewünschten Typ um. Falls die Umwandlung eines Zeigertyps nicht möglich ist, hat der zurückgegebene Zeiger den Wert NULL. ...

stimmts?

Und die Sache mit dem Schleifenabbruch ist mir ja peinlich... War schon wieder zu einfach für mich!

Zur FAQ-Variante: wenn sich herausstellt dass ich noch Zeit habe, werde ich das machen!

Wikipedia schrieb:

... Ein wichtiger Faktor bei der Entwicklung eines Systems ist aus Wettbewerbsgründen die Zeit. So muss sich der Ingenieur in der Praxis häufig mit einer nichtidealen Lösung zufrieden geben, die aber dennoch als gut einstufbar ist. ...

Ahh, verstehe... Und zwar wegen:
stimmts?

Korrekt.

Mir ist da gerade noch etwas aufgefallen: Ist meine Lösung in diesem Fall nicht besser, weil dynamic_cast nur ausgeführt wird, wenn die Komponente ein TEdit ist? Mit der Lösung die akari angeboten hat, wird doch bei jeder Komponente ein dynamic_cast versucht... macht in meinem speziellen Fall einen maximalen Unterschied von 31 dynamic_casts (derzeit 48 Komponenten auf dem Formular, 17 davon TEdit). Hab ich was übersehen?

Du übersiehst zwei Sachen :
- Auch die Ermittlung des ClassName sowie der AnsiString-Vergleich mit "TEdit" braucht seine Verarbeitung.
- Wenn du schon auf ClassName vergleichst, brauchst du auch kein dynamic_cast sondern dann reicht ein static_cast ohne Überprüfung.

bis bald
akari

TCheckBox* check(dynamic_cast<TCheckBox*>(Sender));
if( !check) return;
unsigned short j= check->Tag;

Du übersiehst zwei Sachen :
- Auch die Ermittlung des ClassName sowie der AnsiString-Vergleich mit "TEdit" braucht seine Verarbeitung.

Ok, und was ist aufwendiger? Das oder dynamic_cast?

akari schrieb:

- Wenn du schon auf ClassName vergleichst, brauchst du auch kein dynamic_cast sondern dann reicht ein static_cast ohne Überprüfung.

Kannst du das bitte nochmal anders (und evtl ausführlicher) formulieren? Ich steh' schon wieder auf der Leitung!

Braunstein schrieb:

Wenn mans genau nimmt sollte auch bei der CheckBox-Umwandlung ein Test rein.

Aber die Ereignisbehandlung ist doch für CheckBoxClick; Sender ist doch immer ein TCheckBox-Element Wozu der Test

Ok, und was ist aufwendiger? Das oder dynamic_cast?

Gute Frage. Schwer zu sagen. Ich vermute die ClassName-Variante.

Kannst du das bitte nochmal anders (und evtl ausführlicher) formulieren? Ich steh' schon wieder auf der Leitung!

Du machst momentan erst die ClassName-Überprüfung und dann die dynamic_cast-Umwandlung mitsamt Überprüfung. Damit ist eine Überprüfung doppelt. Und darum reicht eigentlich ein dynamic_cast aus.
Du kannst natürlich auch die ClassName-Überprüfung machen und statt dem dynamic_cast einfach static_cast verwenden. Denn static_cast ist nur eine Umwandlung ohne Überprüfung, die man nehmen darf wenn man sich wirklich sicher ist. Dafür ist static_cast zur Laufzeit kostenlos.

Aber die Ereignisbehandlung ist doch für CheckBoxClick; Sender ist doch immer ein TCheckBox-Element

Braunstein meint genau das was ich oben gesagt habe : dynamic_cast brauchst du nur wenn du dir nicht sicher bist und ein Überprüfung braucht, ob die Umwandlung wirklich machbar ist. Das bedeutet aber auch das nach jedem sinnvollen dynamic_cast auch das Ergebnis von dynamic_cast überprüft werden sollte.

Wenn du dir zur Entwurfszeit sicher bist das es funktioniert dann reicht ein static_cast.

bis bald
akari

[Aber die Ereignisbehandlung ist doch für CheckBoxClick;

Die ist nur dafür gedacht. Ja. Wenn du sie aber mal versehentlich einem TEditClick zuweist knallt es. Dazu brauchst du nur mal im Objektinspektor falsch auswählen.

Braunstein schrieb:

Kolumbus schrieb:

[Aber die Ereignisbehandlung ist doch für CheckBoxClick;

Die ist nur dafür gedacht. Ja. Wenn du sie aber mal versehentlich einem TEditClick zuweist knallt es. Dazu brauchst du nur mal im Objektinspektor falsch auswählen.

Also nur wegen dieser Befürchtung würde ich kein dynamic_cast verwenden. Soviel Kontrolle hab ich schon über mein Projekt

bis bald
akari

Braunstein schrieb:

Mag sein. Ich finde es nur eine nützliche Angewohnheit, bei dynamic_cast grundsätzlich zu prüfen. Kann sein das das manchmal unnötig ist, aber auf keinen Fall fehlerhaft.

Genau

Wie du ja schon gesagt hast kann man ja sonst gleich static_cast nehmen.

Und genau das würde ich in diesem Fall auch machen.

bis bald
akari

void __fastcall TForm4::CheckBoxClick(TObject *Sender)
{
	unsigned short j= static_cast<TCheckBox*>(Sender)->Tag;

	for(unsigned short k= 0; k < (this->ComponentCount-1); k++)
	{
		if((this->Components[k]->ClassNameIs("TEdit")) && (static_cast<TEdit*>(this->Components[k])->Tag==j))
		{
			TEdit *VirtualEdit= static_cast<TEdit*>(this->Components[k]);

			if(!VirtualEdit->Enabled)
				VirtualEdit->Enabled= true;
			else
			{
				VirtualEdit->Enabled= false;
				VirtualEdit->Text= "0";
			}
			break;
		}
	}
}
//---------------------------------------------------------------------------

for(unsigned short k= 0; k < (ComponentCount-1); k++)
    {
        TEdit* VirtualEdit = dynamic_cast<TEdit*>(Components[k]);
        if(VirtualEdit && VirtualEdit->Tag==j)
        {

            if(!VirtualEdit->Enabled)
                VirtualEdit->Enabled= true;
            else
            {
                VirtualEdit->Enabled= false;
                VirtualEdit->Text= "0";
            }
            break;
        }
    }