Abfrage ob GUI Control noch vorhanden ist.

[stalkingwolf]

Hallo zusammen.

wir haben eine kleine Routine uns geschrieben, welche das gerade ausgewählte Feld z.b Tedit in einer anderen Farbe anzeigt und beim verlassen wieder zurück auf den Standardwert setzt.
Wir haben nun beim Umzug von Delphi 6 auf XE4 das Problem das uns das zurücksetzen der Farben eine Zugriffsverletzung ausgibt, wenn das Control nicht mehr vorhanden ist. Interessanterweise war das beim übersetzen Programm aus Delphi 6 egal. Am Quellcode hat sich nichts geändert.

Jetzt die banale Frage wie man eigentlich abfragt ob ein Objekt noch vorhanden ist.
Dazu nutzen wir ScreenActiveControlChange und merken uns mit Screen.ActiveControl das aktuelle Control.
Beim wechseln wird das letzte Control zurück gesetzt.

Ich habe nun probiert sender <> nil oder if assigned(sender)
Aber ich bekomme nicht raus ob das Control was ich mir gemerkt habe noch existiert.

Quellcode:

Code:

var originalColor : TColor;

.
.
.

procedure Tdm.EnterColor(Sender: TWinControl);
begin
    if (Sender <> nil) then begin
        if trim(sender.Name)= '' then exit;
        try
        if IsPublishedProp(Sender,'Color') then begin
            originalColor := GetOrdProp(Sender,'Color');
            SetOrdProp(Sender,'Color', focusColor);
        end;
        except
        end;
    end;
end;

procedure Tdm.ExitColor(Sender: TWinControl);
begin
    if (Sender <> nil) then begin
        if trim(sender.Name)= '' then exit;
        try
            if IsPublishedProp(Sender,'Color') then begin
                SetOrdProp(Sender,'Color',originalColor);
            end;
        except
        end;
    end;
end;

procedure Tdm.ScreenActiveControlChange(Sender: TObject);
var 
  previousActiveControl : TWinControl;
begin
  //Ausnahmen

    if not ((Screen.ActiveControl is TDBEdit)or
          (Screen.ActiveControl is TEdit)or
          (Screen.ActiveControl is TPageControl)or
          (Screen.ActiveControl is TTabsheet)or
//          (Screen.ActiveControl is TDBCheckBox)or
//          (Screen.ActiveControl is TCheckBox)or
//          (Screen.ActiveControl is TDBComboBox)or
//          (Screen.ActiveControl is TDBMemo)or
//          (Screen.ActiveControl is TMemo) or
//          (Screen.ActiveControl is TRadioGroup) or
//          (Screen.ActiveControl is TDBRadioGroup)or
          (Screen.ActiveControl is TComboBox) or
          (Screen.ActiveControl is TDBComboBox) or
          (Screen.ActiveControl is TEditalign)) then Exit;


    if Screen.ActiveControl = nil then begin
        lastFocused := nil;
        Exit;
    end;


    previousActiveControl := lastFocused;
    lastFocused := Screen.ActiveControl;

    ExitColor(previousActiveControl);
    EnterColor(lastFocused);
end;

.
.
.


Screen.OnActiveControlChange    := ScreenActiveControlChange;

[SneakyBagels]

Statt Assigned(Sender) probier doch mal Assigned(dein-gemerktes-control).
Aber wenn hier Assigned schon schief geht, dann liegt der Fehler vermutlich woanders.

[Jasocul]

Assigned macht auch nur eine Prüfung auf Nil.
Das Problem ist, dass ein Control, das zur Laufzeit entfernt wurde, nicht zwingend Nil ist.

Statt Control.Free, hilft FreeAndNil(control). Dann funktioniert auch die Prüfung mit Assigned.

[stalkingwolf]

in dem Fall mit unserem Passwortfenster generiere ich nur das Passwort Fenster mit Application.CreateForm(Tfpassword, fpassword);
und gebe danach mit fpassword.free; frei.
Um die Controls auf der Form kümmere ich mich gar nicht.
Ich habe nun in dem Passwordfenster bei FormDestroy FreeAndNil(edpasswort); eingefügt.
Dennoch geht er bei if (Sender <> nil) then begin durch und knallt bei if trim(sender.Name)= '' then exit;

[Jasocul]

Wenn ich das richtig sehe, ist das eine Routine im DataModul und das wird einem Event in "Screen" zugewiesen.

Man könnte natürlich mit einem Try..Except arbeiten, was meiner Meinung nach zwar der einfachste, aber "unschöne" Weg ist.
Ich würde aus dieser Routine eine Komponente machen und auf der jeweiligen Form platzieren. Alternativ wäre noch die Variante über einen ClassHelper für TForm denkbar.

[SneakyBagels]

Nur lößt das das Problem, dass <> nil durchrattert?