Czy obiekt TTimer może być polem klasy Delphi?

Question

Zacząłem uczyć się Delphi dwa dni temu, ale utknąłem. Zepsułem się, ponieważ nic nie idzie po mojej myśli, więc postanowiłem napisać tutaj. Chciałem stworzyć klasę, która będzie miała pole z własnym obiektem TTimer i która wykona jakąś akcję w pewnym przedziale czasowym. Czy to możliwe? Załóżmy, że mamy taki kod:

Sth = class 
private 

public 
    clock:TTimer; 
    procedure clockTimer(Sender: TObject); 
    constructor Create(); 
end; 

constructor Sth.Create() 
begin 
    clock.interval:=1000; 
    clock.OnTimer := clockTimer; 
end; 

procedure Sth.clockTimer(Sender: TObject); 
begin 
    //some action on this Sth object at clock.interval time... 
end; 

Mój kod jest podobny, ale nie działa poprawnie. Kiedy wywołuję konstruktora program ulega awarii (naruszenie dostępu w linii: clock.interval: = 1000;). Nie wiem, co robi, ale myślę, że to nie problem. Czy możliwe jest stworzenie takiej klasy, jaką chcę?

Answer 1

Nie utworzyłeś stopera. Deklarowanie zmiennej nie wystarczy. Musisz utworzyć timer.

constructor Sth.Create() 
begin 
    clock := TTimer.Create(nil); 
    clock.interval:=1000; 
    clock.OnTimer := clockTimer; 
end; 

I ty też powinieneś to zniszczyć. Dodaj destruktora do klasy

destructor Destroy; override; 

i wdrożyć go jak ten

destructor Sth.Destroy; 
begin 
    clock.Free; 
    inherited; 
end; 

Chciałbym również, aby dokonać swojej dziedzinie clock posiadają widoczność. Nie jest dobrze eksponować wewnętrznych klas takiej klasy.

TMyClass = class 
private 
    FClock: TTimer; 
    procedure ClockTimer(Sender: TObject); 
public 
    constructor Create; 
    destructor Destroy; override; 
end; 
.... 
constructor TMyClass.Create 
begin 
    inherited; 
    FTimer := TTimer.Create(nil); 
    FTimer.Interval := 1000; 
    FTimer.OnTimer := ClockTimer; 
end; 

destructor TMyClass.Destroy; 
begin 
    FTimer.Free; 
    inherited; 
end; 

Zauważ, że zawarłem połączenia z odziedziczonym konstruktorem i destruktorem. Nie są one konieczne w tej klasie, ponieważ pochodzą bezpośrednio z TObject, a konstruktor i destruktor dla TObject jest pusty. Ale jeśli w pewnym momencie zmienisz dziedziczenie i sprawisz, że twoja klasa będzie pochodzić z innej klasy, będziesz musiał to zrobić. Tak więc, moim zdaniem, dobrą praktyką jest włączanie tych połączeń zawsze.