@shima
Häng Dich doch mal nicht an dem Button auf...
Es kann doch auch um andere Variablen oder Eigenschaften gehen, deren Werte "irgendwo" unerwartet verändert werden.
Ok, es gibt Klassen, Properties, Proceduren und Funktionen in die man nicht hineindebuggen kann; also kurz gesagt
Code, der nicht unter der eigenen vollständigen Kontrolle steht.
Dazu gehört z.B. die Windows
API,
ActiveX und Komponenten aus der
VCL.
Ja, man kann mit Debug-DCUs kompilieren aber es handelt sich doch um fremden Code.
Im Laufe der Jahre habe ich gelernt mit diesem "Fremdcode" umzugehen.
Falls nötig baue ich um diesen Fremdcode eine Schicht, die meistens aber nur hauchdünn ist.
Es ist wichtig zu erkennen, wann man die Schicht braucht und wann nicht.
Die Schicht kann manchmal auch nur eine Funktion sein, die ein Argument 1 zu 1 weiterleitet.
Delphi-Quellcode:
Beispiel
procedure TForm1.ShowError(const msg:string);
begin
ShowMessage(msg);
// oder
// Statusbar1.SimpleText := msg;
end;
Diese Schicht ist sehr dünn, aber ich kann einen Breakpoint setzen oder die Fehlermeldung auf eine andere Weise anzeigen.
Für den Zugriff auf Komponenten habe ich meistens keine Zwischenschicht.
Nur falls nötig oder falls ein Spareffekt (z.B. mehrere Buttons auf einen Rutsch dis/enablen) eintritt würde ich eine Procedure/Funktion als Zwischenschicht einführen.
Ganz anderst sieht das mit Handles und Zeigern der Windows
API aus.
Hier kapsele ich grundsätzlich immer mit einer Klasse, Procedure oder Funktion.
Stellt euch vor es gäbe die Klassen TFont, TCanvas, TPen und TBrush nicht.
Was wäre das für eine Qual irgendetwas zu zeichnen.
Ähnlich sieht das bei Zeigern und Strukturen aus der Windows
API aus.
Ich würde z.B. niemals die Windows
API-Funktion
GetComputerName() direkt in meiner Anwendung aufrufen.
Nein, dieser Aufrauf braucht eine kleine Zwischenschicht:
Delphi-Quellcode:
function GetLocalComputerName: string;
var
Count: DWORD;
begin
Count := MAX_COMPUTERNAME_LENGTH + 1;
SetLength(Result, Count);
if GetComputerName(PChar(Result), Count) then
StrResetLength(Result)
else
Result := '';
end;
Ich würde auch nie auf die Idee kommen meine Anwendung direkt mit WinSock-Funktionen (socket(),bind(),listen(),..) oder Funktionen für die serielle Schnittstelle reden zu lassen.
Hier braucht es unbedingt eine Klasse, die den Zugriff kapselt.
Automatisch habe ich dadurch Code auf den ich Breakpoints setzen kann.
Fazit: um Code, der nicht unter der eigenen Kontrolle steht sollte man (bei Bedarf) eine Zugriffsschicht legen.
Die dünnstmögliche Schicht ist die 1:1 Weiterleitung einer Funktion/Procedure