tedit.onchange schluckt ersten Wert bei Iteration

[DrUArn]

Hi,
ein Problem beim Iterieren bei Nutzung von onchange-Ereignis:

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    button1:tbutton;
    edit1:tedit;
    memo1:tmemo;// nur zur Darstellung
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
    procedure Edit1Change(Sender: TObject);
    procedure Button1Click(Sender: TObject);

  end;

procedure TForm1.Edit1Change(Sender: TObject);
begin
memo1.lines.Add(tedit(sender).text)
end;

procedure TForm1.Button1Click(Sender: TObject);
 var i:integer;
begin
    if tbutton(sender).tag =0 then
      for I := 1 to 3 do
         begin
//         memo1.lines.Add(inttostr(i));
         edit1.text:=inttostr(i)
         end
    else
      for I := 3 downto 1 do
       begin
//       memo1.lines.Add(inttostr(i));
       edit1.text:=inttostr(i);

       end;

memo1.lines.Add('_____');

if tbutton(sender).tag=0 then tbutton(sender).tag:=1 else tbutton(sender).tag:=0;
end;

Beim Betätigen des Tbutton wird der jeweils erste Wert der Iteration nicht bearbeitet in onchange - d.h. onchange wird gar nicht gerufen.
Verändert man Tag nicht, werden immer alle Werte bearbeitet.

Das direkte Eifügen mit "memo1.lines.Add(inttostr(i))" führt zum richtigen Ergebnis.

Auch wenn man zwei tbutton nutzt - einen für die "to"-, den anderen für die "downto"-Iteration passiert beim Wechseln zwischen diesen Buttons das Gleiche!

Woran liegt das ?


MfG Uwe

[mkinzler]

Der Wert wird zwar in den Edit geschrieben, aber er wird wieder überschrieben, bevor der Event ausgelöst wird.

[DrUArn]

Hi,

Zitat von mkinzler:

Der Wert wird zwar in den Edit geschrieben, aber er wird wieder überschrieben, bevor der Event ausgelöst wird.

Aber wie löst diese Änderung von Tag das Überschreiben aus? Ändere ich Tag nicht (bzw. wenn ich zwei Buttons benutze jeweils den einen nur drücke, dann kommt beim zweiten Drücken des gleichen Buttons das richtige Ergebnis).


MfG Uwe

[himitsu]

Nee, genau anders.

Da der Text im Edit nicht "verändert" wird, wird auch kein OnChange aufgerufen.

Delphi ist so intelligent und prüft, ob sich der Text wirklich ändert.

Zitat:

Delphi-Quellcode:

procedure TControl.SetText(const Value: TCaption);
begin
  if GetText <> Value then
    ...
end;

Tag ist ein reines Datenproperty, welches nur für den Programmierer da ist ... dort reagiert niemand auf eine Änderung, weil es der VCL vollkommen egal ist.

[DrUArn]

OK,

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
 var i:integer;
begin
    if tbutton(sender).tag =0 then
      for I := 1 to 3 do
         begin
         edit1.text:='9999';
//         memo1.lines.Add(inttostr(i));
         edit1.text:=inttostr(i)
         end
    else
      for I := 3 downto 1 do
       begin
       edit1.text:='9999';
//       memo1.lines.Add(inttostr(i));
       edit1.text:=inttostr(i);

       end;

memo1.lines.Add('_____');

if tbutton(sender).tag=0 then tbutton(sender).tag:=1 else tbutton(sender).tag:=0;
end;

So geht das dann erst einmal - kann man nun delphi zwingen diese Prüfung zu unterlassen?


oder so:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
 var i:integer;
     ereignis:tereignishprozedure// ???? fällt mir grad' nicht ein, welche var das sein müßte
begin
    if tbutton(sender).tag =0 then
      for I := 1 to 3 do
         begin
         ereignis:=edit1.onchange;
         edit1.onchange:=nil;  
         edit1.text:='9999';
         edit1.onchange:=ereignis;     
//         memo1.lines.Add(inttostr(i));
         edit1.text:=inttostr(i)
         end
    else ....

       end;

memo1.lines.Add('_____');

if tbutton(sender).tag=0 then tbutton(sender).tag:=1 else tbutton(sender).tag:=0;
end;

... sieht sehr masochistisch aus.

oder

procedure TControl.SetText(const Value: TCaption);
begin
if GetText <> Value then
...
end;

überschreiben???


MfG Uwe

[himitsu]

Nee, wozu? (OK, aber wozu sich jetzt mit der WinAPI oder über Perform an das Edit wenden, nur um etwas Falsches zu machen )
OnChange gibt an, daß sich der Wert geändert hat und geändert hat er sich schließlich nicht.

Du kannst aber dein ChangeEreignis auch manuell aufrufen.

Delphi-Quellcode:

Edit1Change(nil);
oder 
if Assigned(Edit1.OnChange) then Edit1.OnChange(nil);

[DrUArn]

Zitat von himitsu:

Nee, wozu? (OK, aber wozu sich jetzt mit der WinAPI oder über Perform an das Edit wenden, nur um etwas Falsches zu machen )
OnChange gibt an, daß sich der Wert geändert hat und geändert hat er sich schließlich nicht.

Du kannst aber dein ChangeEreignis auch manuell aufrufen.

Delphi-Quellcode:

Edit1Change(nil);
oder 
if Assigned(Edit1.OnChange) then Edit1.OnChange(nil);

Ist korrekt, onchange nur bei geänderten Werten - heißt so und soll's auch tun!
Über direktes rufen muß ich erst mal nachdenken.

Erst mal Danke an alle Diskutanten

Uwe

[Sir Rufo]

Jetzt wäre es doch mal interessant zu wissen, was du eigentlich erreichen möchtest.

a) alle Änderungen vom Edit im Memo protokollieren - genau das macht der Code den du im OnChange Event defibiert hast

oder

b) Werte aus den beiden Schleifen im Memo speichern (und gleichzeitig die Anzeige im Edit - obwohl das so keinen Sinn macht, weil das niemand lesen kann, bei der Geschwindigkeit)

denn bei a) bist du schon mit deinem Ursprungscode fertig und bei b) musst du das OnChange Event für das Edit wegnehmen und innerhalb der Schleifen direkt in das Memo schreiben

oder gibt es gar noch c) ... ?

Es macht keinen Sinn irgendwie "heilenden" Code zu produzieren um ein angeblich "fehlerhaftes" Standardverhalten zu korrigieren. Denn hier haben wir keinen Bug, sondern einen falschen Ansatz

[Furtbichler]

Mal grundsätzlich: Wenn ich verhindern möchte, das z.B. OnChange aufgerufen wird, habe ich zwei Möglichkeiten:

1. Ich kann, wie schon gezeigt, die Events kurz abschnippeln, dann das tun, was ich tun will und wieder anbepseln
oder
2. Ich verwende ein privates Feld 'Silent' oder wie auch immer
2.1 Prüfe in jedem Event If Silent then exit; .
2.2 Setze vor dem, was ich machen will 'Silent := True' und hinterher wieder auf false.

Sinnvoll ist das z.B. beim erstmaligen Initialisieren von Eingabefeldern oder wenn ich kaskadierte oder schlimmer: rekursive aufrufende Events befürchten muss.

(1) verwende ich, wenn alle OnChange-Events auf ein zentrales Event zeigen. Dann habe ich eine Routine zum wegschnippeln und eine zum anbepseln. Die zum Anbepseln rufe ich im FormCreate auf.

(2) verwende ich, wenn die Events alle unterschiedlich sind. denn dann würde die Anbepsel-Routine schnell ziemlich lang und langweilig werden.

[himitsu]

@Furtbichler:
Ich glaub du hast das falsch verstanden.

Der TE beschwert sich nicht über zuviele ausgelöste Events, sondern über Zuwenige.