Nadpisywanie komponentów

0

Ostatnio często zdaza mi się, że muszę nadpisać komponent.
Wyczytałem, że tworzony komponent powinien dziedziczyć po klasie

TCustomNadpisywanyKomponent;

a nie po

TNadpisywanyKomponent;

w TNadpisywanyKomponent są w zasadzie same property.

zazwyczaj chciał bym, zeby mój komponent również miał te wszystkie property które ma Klasa TNadrzednyKomponent, więc po prostu kopiuje je wszystkie do mojej klasy dziedziczącej po TCustomNadpisywanyKomponent.

a Pytanie brzmi. czy można to zrobić jakoś bez kopiowania? tylko, ze by wskazać mojemu komponentowi, Ty weź i zrob takei property jak ma TNadpisywanyKomponent?

0

ta, dziedziczyć po TNadpisywanyKomponent a nie po TCustomNadpisywanyKomponent

0

Nie rozumiem w ogóle o co Ci chodzi... Zamiast wymyślać jakieś dziwne klasy podaj dokładne nazwy przykładowych klas do dziedziczenia i nazwy ich właściwości czy metod;

Poza tym komponentów się nie nadpisuje, tylko się po nich dziedziczy (czyli buduje nowe - rozszerzone - na podstawie innych) - nic nie jest nadpisywane (teoretycznie);

Podaj więc kod Twojego komponentu a coś więcej się napisze.

0

w zasadzie kod nie ma tu nic do rzeczy. Po prostu chciałem usystematyzować wiedzę. Przeczytałen na forum, że jeśli chce zrobić Swoj komponent który miałby dziedziczyć po TEdit. To, że lepiej by było dziedziczyć po TCustomEdit. No z tym, że wtedy musze skopiować wszystkie property z klasy TEdit. Więc, czy jest sens dziedziczenia po TCustomach?

1

Tak, bo masz zaimplementowaną jedynie podstawę kontrolki bez zbędnych pierdół (czyt. właściwości i zdarzeń), z których i tak nie skorzystasz; Więc jaki sens byłby dziedziczyć wszystko, skoro ani połowa tego nie jest Ci potrzebna?

Żeby dokładnie to stwierdzić - trzeaba by zobaczyć jak wygląda implementacja klasy np. TCustomEdit i TEdit i je porównać.

1
furious programming napisał(a):

Tak, bo masz zaimplementowaną jedynie podstawę kontrolki bez zbędnych pierdół (czyt. właściwości i zdarzeń), z których i tak nie skorzystasz; Więc jaki sens byłby dziedziczyć wszystko, skoro ani połowa tego nie jest Ci potrzebna?
Guzik prawda! Skąd Ty wiesz czy pytaczowi są potrzebne czy nie? Skoro ma taką potrzebę i "...zazwyczaj chciał bym, zeby mój komponent również miał te wszystkie property które ma Klasa ..." to znaczy, że pytaczowi są potrzebne. Głupotą jest dziedziczyć po TCustomControl tylko po to aby nie dziedziczyć po TControl i we własnej kontrolce robić kopiuj-wklej właściwości z TControl. Dziedziczenie po TCustomCustom ma sens jedynie wtedy, kiedy chcemy UKRYĆ (a właściwie nie udostępniać) właściwości publiczne klasy TControl

  • za TControl i TCustomControl wstawiamy odpowiednie kontrolki, np TEdit i TCustomEdit
0

Pytacz sam nie wie czy są mu potrzebne wszystkie^^, ale skoro ktoś mądry kiedyś je stworzył to mysli, ze warto by je w razie czego mieć:D

ok. Czyli podsumowując. Nie będzie problemu z dostępem to pól i metod zdefiniowanych w tCustomControl gdy moj komponent będzie dziedziczył po TControl?

a dziedzidzenie po TCustomControl umozliwia jedynie nie dodanie któregoś property do mojego komonentu.

0

jak sam zauważyłeś TXXX różni się praktycznie tylko jednym od TCustomXXX - udostępnia właściwości opublikowane (published). Z punktu widzenia programowania nie ma znaczenia po czym dziedziczysz. Jeśli chcesz dodać jedną (albo i sto) właściwość i jednocześnie mieć wszystkie właściwości bazowe to dziedzicz po TXXX. Jeśli chcesz czegoś nie pokazywać to dziedzicz po TCustomXXX i pokaż tylko to co chcesz.

Jeszcze taka uwaga - w nowych delphi jest coś takiego jak Helper - http://docwiki.embarcadero.com/RADStudio/XE4/en/Class_and_Record_Helpers

0

@abrakadaber - niejasno się wyraziłem, ale chodziło mi dokładnie o to, o czym napisałeś, tyle że użyłem innych (widać niezrozumiałych/złych) słów:

Furious Programming napisał(a)

bo masz zaimplementowaną jedynie podstawę kontrolki bez zbędnych pierdół (czyt. właściwości i zdarzeń)

co odpowiada Twoim słowom:

abrakadaber napisał(a)

Dziedziczenie po TCustomCustom ma sens jedynie wtedy, kiedy chcemy UKRYĆ (a właściwie nie udostępniać) właściwości publiczne klasy TControl

Chodziło mi o to, że udostępnione i widoczne są jedynie podstawowe właściwości i żadnych zdarzeń (dziedzicząc po Customach) - można to zobaczyć w inspektorze obiektów; No i tak jak piszesz - przepisywanie wszystkiego nie ma sensu;

Reszta oczywiście jest, tyle że niewidoczna i można ją dodać, ale ich obsługa jest już zaimplementowana.


Przykładowo mamy komponent zbudowany na podstawie TCheckBox, który udostępnia wszystkie właściwości i zdarzenia klasy TCheckBox; Ale jeśli dziedziczymy po TCustomCheckBox to mamy postawowe właściwości i żadnych zdarzeń; Aby je dodać wystarczy uzupełnić odpowiednią sekcję kl;asy;

Np. dodajemy właściwość Color:

type
  TFooCheckBox = class(TCustomCheckBox)
  {...}
  published
    property Color;
  end;

Po kompilacji mamy dostępną właściwość Color (do modyfikacji np. w inspektorze obiektów); Jej obsługa jest już zaimplementowana, więc po modyfikacji tej właściwości kontrolka przyjmie inny kolor.

1

Jeśli chcesz, by twoja kontrolka miała wszystkie property które ma oryginał,dziedziczysz po TNadpisywanyKomponent.
Jeśli chcesz jakieś właściwości ukryć, bo nie mają w twoim przypadku sensu, dziedziczysz po TCustomNadpisywanyKomponent i udostępniasz tylko te property, które trzeba.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.