TMS AdvEdit OnChange

[hhcm]

Hallo zusammen,

seit dem letzen TMS Update wurde das verhalten des TMS AdvEdit verändert.
Bisher war es so, dass OnChange aufgerufen wurde wenn man z.B FloatValue verändert hat. Das wurde jetzt entfernt.
Der TMS Support nennt es

Zitat:

It was an inconsistency discovered and we think the right thing to do is fix an inconsistency.

Für uns bedeutet das verdammt viel Arbeit. Da das ganze im Setter einer Propertys passiert, kann ich auch keine eigene Ableitung erstellen.
Hat jemand eine Idee wie man (ohne 20 Programme durchsuchen zu müssen) das ganze umgehen könnte?

[hoika]

Hallo,
wenn Die den Quellcode hast, ändere es doch wieder zurück.

[hhcm]

Jedes mal wenn TMS ein Update rausbringt? Nein Danke !!!

[Uwe Raabe]

Du willst also das Change-Event ausführen, wenn FloatValue etwas zugewiesen wird?

Ein möglicher Ansatz wäre ein Class Helper for TAdvEdit, der das FloatValue Property neu einführt und einen entsprechenden Setter implementiert. Du musst dann nur überall wo FloatValue zugewiesen wird den Class Helper im näheren Scope haben (also dessen Unit passend in die Uses-Clause platzieren).

[hhcm]

Zitat von Uwe Raabe:

Du willst also das Change-Event ausführen, wenn FloatValue etwas zugewiesen wird?

Ja, denn so war es vor dem Update. Es ist ja auch in einem normalen TEdit der Fall wenn ich .Text zuweise wird OnChange aufgerufen.

Zitat:

Ein möglicher Ansatz wäre ein Class Helper for TAdvEdit, der das FloatValue Property neu einführt und einen entsprechenden Setter implementiert. Du musst dann nur überall wo FloatValue zugewiesen wird den Class Helper im näheren Scope haben (also dessen Unit passend in die Uses-Clause platzieren).

Da wird mir wohl nichts anderes übrig bleiben. Ich könnte auch alles in .Value umbenennen, was wiederum .Text zuweist, da funktioniert das OnChange "noch". Es ist jetzt nicht das erste mal das TMS solche Änderungen bringt die eine komplette Anwendung lahm legen.

[himitsu]

PS: Das ist auch der Grund, warum sich viele Entwickler alle Komponenten nochmal ableiten, selbst wenn sie (noch) nichts geändert haben.

Später kann man dann Problemlos in dieser Ableitung rumfummeln und es ist überall drin.



Beim ClassHelper, wenn du eine Methode überdeckst, dann muß der Scope überall stimmen.
Besser dort die Methode/Property anders benennen, damit wird dann überall definitiv deine Überladung verwendet,
auch wenn man hier dann erstmal alle Stellen finden und ebenfalls anpassen muß, aber wenn der Helper fehlt, dann knallt der Compiler dort,
anstatt still und heimlich doch die Originalmethode aufzurufen.



ClassHelper oder Ableitung (egal ob gleicher ClassName oder ein Neuer) wären die einzigen wirklich praktikablen Lösungen.
Leider kann der TVirtualMethodInterceptor nur alle virtuellen Methoden überschreiben, anstatt nur eine Gewünschte (was dann schon etwas langsam wird), aber im Notfall gibt es auch andere Methoden eine Methode zu hooken.

PS: Nimm dir mal eine neue Form, mit einem Edit drauf und weise in einem Button-OnClick dessen .Text etwas zu.
Und nun pack diese Klasse vor deine TForm1-Implementation. (oder in eine Unit und diese als Letzte ins USES)

Delphi-Quellcode:

type
  TEdit = class(StdCtrls.TEdit)
    function GetText: TCaption;
    procedure SetText(const Value: TCaption);
  public
    property Text read GetText write SetText;  // überdecken, weil nicht Virtual die blöden Getter und Setter
  end;

{
//uses StrUtils;

function TEdit.GetText: TCaption;
begin
  Result := ReverseString(inherited Text);
end;

procedure TEdit.SetText(const Value: TCaption);
begin
  inherited Text := ReverseString(Value);
end;
}

Hier muß die neue Klasse für einen Bugfix nicht in der IDE registriert sein (DesignTimePackage) und auch nicht in allen Forms ersetzt werden, sondern der DFM-Loader ersetzt erst zur Laufzeit diese Komponente. (der verwendet zum Erstellen die Deklatation, bzw. den Typ der Komponenten, welche er in seiner Form-Deklaration findet)


In deinem Fall also den Setter von FloatValue überschreiben oder überdecken und dort dann OnChange aufrufen, bzw. die Methode ausführen, in der OnChange aufgerufen wird (z.B. beim TEdit siehe TCustomEdit.Change).



Eventuell könntest du dich auch an Events wie WM_SETTEXT hängen, auf eine Änderung readieren und OnChange aufrufen (aber du erwischst hier eventuell auch andere Stellen, wo bereits OnChange ausgelöst wird, womit das dann doppelt wäre)

[hoika]

Hallo,

Zitat:

Jedes mal wenn TMS ein Update rausbringt? Nein Danke !!!

Warum nicht?

Ich habe mir übrigens angewöhnt, nicht so häufig TMS-Updates anzutun ...

Meine 3 eigenen Patches im TAdvStringgrid friemele ich dann immer wieder rein.

[hhcm]

Zitat von hoika:

Warum nicht?

Ich versuche gerade den Witz darin zu finden, kann ihn aber nicht finden.

[hoika]

Hallo,
das ist kein Witz.
Immerhin kennst du ja die Fehler/Unzulänglichkeiten.

Wir haben sogar eine Update-Anweisung, die genau beschreibt,
wie unsere Patches eingespielt werden müssen.
Schade, aber ist leider so.

Wie oft macht ihr denn TMS-Updates?

[Uwe Raabe]

Zitat von hoika:

Immerhin kennst du ja die Fehler.

Streng genommen ist es ja wohl gar kein Fehler, sondern as designed. Halt nur anders als früher.