OnChange Events bei einer TRadioGroup

[Socke]

Hey,
Ich habe in meinem derzeitigen Projekt ein TRadioGroup-Objekt und möchte gerne mitbekommen, wenn ein anderer RadioButton ausgewählt wird. Leider hat die Klasse TRadioGroup kein OnChange-Event, über welches man das dann abfangen könnte. Deshalb habe ich mir gedacht, direkt das OnChange-Event der RadioButtons abzufangen.

Code: Alles auswählen

RgAdd: TRadioGroup; { meine RadioGroup}
procedure ModuleGroupChanged( Sender: TObject ); { mein EventHandler}
{...}
var
  i: Integer;
begin
{ Register ModuleGroup change callback }
  for i := 0 to RgAdd.ControlCount-1 do begin
    if RgAdd.Controls[i] is TRadioButton then begin
      TRadioButton(RgAdd.Controls[i]).OnChange := @ModuleGroupChanged;
    end;
  end;
end;

Das Ganze hab ich auch schon mit Components[Index]: TComponent ausprobiert (funktioniert ein bisschen anders), aber beides mal ist raus gekommen, dass mein EventHandler nur bei der ersten Änderung ausgelöst wird. Danach nicht mehr.

Hat jemand einen Lösungsvorschlag?
MfG Socke

[slai]

Hy Socke

Benutze doch einfach den OnClick event.

[Socke]

Benutze doch einfach den OnClick event.

Mit OnClikc assoziere ich eher ein Click als ein Change. Da ich das jetzt grade nicht ausprobieren kann/will: wird das OnClick bei dem TRadioGroup nur ausgelöst, wenn auf eine TRadioButton geklickt wird (und sich damit die Auswhal ändert) oder immer wenn irgendwo hin geklickt wird (also auch daneben)?
Bei letzterem häcke ich vielleicht die LCL

Edit:
Ok, habs grad doch getestet: OnClick wird bei TRadioGroup immer dann ausgelöst, wenn sich der ItemIndex ändert. Kurze Recherche in den Quellen förderte folgendes zu Tage:

Code: Alles auswählen

// for Delphi compatility: OnClick should be invoked, whenever ItemIndex
  // has changed

Ich würde das nicht Kompabilität sondern Bug nennen schöner wär ein OnClick, dass auch bei allen Klicks ausgelöst wird (derzeit nämlich nicht) und ein OnChange, welches die echte Änderung behandelt

[Euklid]

Ich würde das nicht Kompabilität sondern Bug nennen schöner wär ein OnClick, dass auch bei allen Klicks ausgelöst wird (derzeit nämlich nicht) und ein OnChange, welches die echte Änderung behandelt

Eine solche Regelung würde in meinen Augen auch mehr Sinn machen. Zumal wirkliche Delphi-Kompatibilität wird ja nur im Delphi-Mode gefordert.

Mich wundert aber ebenfalls, weshalb deine erste Lösung nur beim ersten OnChange-Ereignis funktioniert. Hast du rausgefunden, warum?

[Socke]

Eine solche Regelung würde in meinen Augen auch mehr Sinn machen. Zumal wirkliche Delphi-Kompatibilität wird ja nur im Delphi-Mode gefordert.

Mich wundert aber ebenfalls, weshalb deine erste Lösung nur beim ersten OnChange-Ereignis funktioniert. Hast du rausgefunden, warum?

Mittlerweile habe ich mit OnClick weiter gebaut, müsste das dann nochmal mit nem anderen Testprojekt überprüfen.

Ein Lösungsansatz wäre, zwei Events bereitzustellen: ein OnClick und ein OnChange. Das OnClick sollte im ObjFPC-mode auf alle Klicks reagieren und das OnChange auf ItemIndex-Änderungen; im Delphi-Mode könnte man das Delphiverhalten übernehmen. Das Problem dürfte darin bestehen, dass man (soviel ich weiß) nicht mitbekommt, ob das aktuell zu kompilierende Projekt im Delphi-Mode gebaut wird, da zum Einen der Delphi-Mode meistens immer nur pro Unit definiert wird (also nicht unit-übergreifend) und zweitens nur ein kleiner Teil der eigenen Unit (ExtCtrls) auf Delphi-Mode anders reagieren müsste (die Unit selbst würde dann aber in ObjFPC kompiliert = anderer Modus). Man kann also gar nicht überprüfen welches Verhalten gefordert wird.

hat noch wer Ideen?
Socke

[theo]

Der {$mode delphi} ist imho eine Sache für den Compiler-Level und wird meines Wissens nicht dafür verwendet, unterschiedliche Verhaltensweisen von Komponenten zu bestimmen (Chaos). Insofern ist es meiner Meinung nach schon richtig, Komponenten generell so wie mit Delphi funktionieren zu lassen.

[Socke]

Der {$mode delphi} ist imho eine Sache für den Compiler-Level und wird meines Wissens nicht dafür verwendet, unterschiedliche Verhaltensweisen von Komponenten zu bestimmen (Chaos). Insofern ist es meiner Meinung nach schon richtig, Komponenten generell so wie mit Delphi funktionieren zu lassen.

Bei ersterem stimme ich dir vollkommen zu, jedoch frage ich mich, wie weit diese Delphi-Kompabilität gehen muss.

Lazarus ist kein Open-Source-Borland-Delphi-Klon[...]

Wir könnten besser sein

[theo]

Bei ersterem stimme ich dir vollkommen zu, jedoch frage ich mich, wie weit diese Delphi-Kompabilität gehen muss.

Soweit wie möglich. Die Delphi-Kompatibilität halte ich für absolut wichtig.
Ohne diese lässt sich imho in der Object Pascal Nische keine Userbase aufbauen. Siehe msegui http://homepage.bluewin.ch/msegui/" onclick="window.open(this.href);return false;
Aber zusätzliche Properties und Features sind natürlich möglich.

Wir könnten besser sein

"Wir" sind Cross Platform tauglich

[Christian]

100% Ack @ Theo.
Es ist zwar etwas bitter die Leute von Delphi zu übernehmen die es programmieren nennen 5 Komponenten auf ein Form zu ziehen und zu verknüpfen aber es existiert soviel guter Delphi code da draussen das eine hohe Delphi Kompatibilität dem projekt wirklich zu groooßer popularitär verhelfen kann.

[Socke]

100% Ack @ Theo.
Es ist zwar etwas bitter die Leute von Delphi zu übernehmen die es programmieren nennen 5 Komponenten auf ein Form zu ziehen und zu verknüpfen aber es existiert soviel guter Delphi code da draussen das eine hohe Delphi Kompatibilität dem projekt wirklich zu groooßer popularitär verhelfen kann.

Es gibt ja noch den Unterschied zwischen Delphi und Delphi, also zwischen der Sprache und der VCL. In wiefern der FPC im Delphi-Mode mit Delphi-code klar kommt weiß ich nicht (nie wirklich getestet). Das Konvertieren von Delphi-Code nach FreePascal sollte sich von der Sprache her als nicht sehr schwierig darstellen (natürlich wird das umso aufwändiger, je komplexer das Projekt ist). Das Problem, das sich mir hier in den Weg stellt ist, dass die LCL ein vollwertiger Ersatz für die Delphi VCL sein soll/will (auch wenn ein paar Komponenten mehr/weiniger vorhanden sind). Mehr aber auch nicht.

Wenn wir Lazarus User in der Delphi-Community wildern möchten, müssen wir ganz klar einen Ersatz für die VCL bereitstellen. Und wenn dieser Ersatz mit der VCL nicht ]hunterprozentig Kompatibel ist, werden zumindest diejenigen, die alte Projekte mit Lazarus erstellen wollen, nicht lange bleiben.

Aber zusätzliche Properties und Features sind natürlich möglich.

In dem konkreten Fall des OnChange bei TRadioGroup dürfte das mehr oder weniger sinnlos sein. Auch wenn es die Kompabiliät zur VCL nicht ändert, ist es höchstens dazu geeignet Verwirrung zu verhindern (so wie in meinem Fall) oder im Gegenteil zu stiften. Delphi-User haben in ihren HIlfedateien folgendes stehen:

• Der Benutzer wählt durch Drücken einer Pfeiltaste ein Element in einem Gitter, einem Gliederungsdiagramm, einer Liste oder einem Kombinationsfeld aus.
• [...]
• Der Wert der Eigenschaft Checked eines Kontrollfeldes wird geändert.

d.h. er weiß nicht, ob OnClick wie gewohnt arbeitet, da ein OnChange vorhanden ist. Der Name indiziert bei OnClick einen Klick, dem aber auch etwas ganz anderes vorausgegangen sein kann. OnChange ist dagegen klar (Änderung).
Den zweiten Punkt habe ich direkt mit zitiert, da mir aufgefallen ist, dass TCheckBox und TRadioButton ein OnChange-Event besitzen. Jetzt weiß ich nicht (wie oben beschrieben) nicht, ob OnClick Delphi-mäßig funktioniert oder ein Klick ist. Das dürfte sich bei diesen beiden zwar mehr oder weniger erübrigen aber in der VCL von Delphi 7 sind diese beiden Ereignisse definitiv nicht vorhanden.

MfG Socke

[Christian]

Wenn wir Lazarus User in der Delphi-Community wildern möchten, müssen wir ganz klar einen Ersatz für die VCL bereitstellen. Und wenn dieser Ersatz mit der VCL nicht ]hunterprozentig Kompatibel ist, werden zumindest diejenigen, die alte Projekte mit Lazarus erstellen wollen, nicht lange bleiben.

Die Aussage versteh ich jetzt nicht was soll diese ganz oder gar nicht Mentalität ?
Ein Delphi Nutzer der mit ein paar handgriffen sein projekt konvertiert bekommt wird tausenmal dankbarere sein als einer der keien Chance hat und alles auf eine andere Sprache umheben muss. Delphi ist in meinen Augen schon tot. Viele werden jetzt aufschreien aber ein produkt das mittlerweile das 3. mal an die nächste Firma weitergereicht wurde und immer nur verschlimmbessert wird ist meiner Meinung nach einfach tot.

[Socke]

Ein Delphi Nutzer der mit ein paar handgriffen sein projekt konvertiert bekommt wird tausenmal dankbarere sein als einer der keien Chance hat und alles auf eine andere Sprache umheben muss.

Viel mehr wollte ich damit auch nicht ausdrücken...

Delphi ist in meinen Augen schon tot. Viele werden jetzt aufschreien aber ein produkt das mittlerweile das 3. mal an die nächste Firma weitergereicht wurde und immer nur verschlimmbessert wird ist meiner Meinung nach einfach tot.

Dazu kann ich weniger was sagen; die letzte Delphi-Version, die ich benutzt habe war Delphi 7 Personal (davor und danach keine andere). Ich würde eher sagen, dass die Sprache Delphi tot ist (oder meinst du nicht die IDE?). Mittlerweile wird ja auch in "Delphi" mit .NET gearbeitet

MfG Socke

[Christian]

Ich meine die IDE. Die Sprache ist ja mehr oder weniger Objekt Pascal.
Das jemand wirklich sinvoll mit Delphi .Net arbeitet wage ich zu bezweifeln, das ist von anfang an eine Totgeburt gewesen. Chrome oder c# sind wenn man schon unbedingt .net machen will dann doch schon eine ganze ecke komfortabler und vorallem aktueller.

[theo]

Das bringt einen ja auch nicht weiter.
Delphi wurde in den vergangenen 10 Jahren immer wieder totgesagt. Java ist auch tot. Alles ist tot.
Bringt doch nix, schon gar nicht für Lazarus.

Delphi litt unter einem Missmangement in den letzten Jahren. Das kann ja theoretisch jetzt besser werden, es dürfte aber nicht leicht sein, die Userbase wieder zu vergrössern.

Ich finde, die Lazarus Gemeinde sollte kein Interesse daran haben, Delphi totzusagen, damit schwindet doch nur die Userbase für Object Pascal. Also empfehlt und kauft Delphi! (Die Leute kommen dann schon zu Lazarus für Cross Platform)

[Socke]

Ich finde, die Lazarus Gemeinde sollte kein Interesse daran haben, Delphi totzusagen, damit schwindet doch nur die Userbase für Object Pascal. Also empfehlt und kauft Delphi! (Die Leute kommen dann schon zu Lazarus für Cross Platform)

Da stimme ich dir teilweise zu. Wenn wir selbst sagen, ObjectPascal (egal ob Delphi/ObjFPC) sei tot, bringen wir uns selbst um . Wäre es nicht besser, anstatt die Leute zum Kauf Von Delphi anzuregen, diese dazu ermuntern zuerst Lazarus auszuprobieren? Das vergrößert nicht indirekt sondern direkt die Lazarus Community. Vielleicht sollten wir sogar Delphi als Alternative für Lazarus darstellen; aber nur für Leute, die von FreePascal noch nichts gehört haben