_NewControl

← →
Марсианин © (2004-05-02 02:16) [0]

Изучаю исходник KOLStGrd и просто не понимаю. код-то работает, сам подобное писывал...

вот строка:
TStGrd = object(TControl) ............ Result := PStGrd(_NewControl(Sender,"TStGrd",i,false,nil));

_NewControl вызывает
Result := _NewWindowed( AParent, ControlClassName, Ctl3D ); .......

_NewWindowed вызывает:
New( Result, CreateParented( AParent ) ); .......

что это за конструкция такая? в хелпе Делфи5 про такое испльзование New не пишут

я так понимаю, что она выделяет и инициализирует память для обьекта типа указателя Result (который в данном случае PControl), с вызовом конструктора... в итоге должен получиться TControl. т.е. если тип Result:PControl, то New выделяет память для TControl и помещает указатель на него в Result.
но! мы создаем ТStGrd..

← →
SPeller © (2004-05-02 06:29) [1]

Всё так, потому что TStGrid наверняка не содержит полей, только методы. В этом случае StGrid занимает в памяти столько же места, сколько и TControl, поэтому какая разница каким конструктором выделять память?

← →
Gandalf © (2004-05-02 10:36) [2]

Именно по этой причине визуальный компонент не может именть своих полей - если наследуется от TControl.

← →
марсианин © (2004-05-02 11:06) [3]

и точно! не содержит! теперь понятно.. но почему бы тогда не определить у TControl одно маленкое поле скажем fUser:Pointer, куда наследующий программист, сможет поместить указатель на свою структуру данных? или я просто ее не заметил?
конечно, можно впихнуть ее в SetWindowLong(GWL_USERDATA). но это немного громозко

← →
Марсианин © (2004-05-02 11:43) [4]

торможу! уже есть такой CustomData: Pointer;

← →
Gandalf © (2004-05-02 14:13) [5]

Угадал.
Еще есть CustomObj - у него можно пепеопределить Destroy - для освобождения ресурсов - посколько TControl.Destroy тебе не подвластен.

← →
марсианин © (2004-05-02 15:36) [6]

теперь понятно, почему TStGrd написан именно так...

посколько TControl.Destroy тебе не подвластен.

кстати почему? он же виртуальный, его можно перекрыть.. или нельзя?

← →
SPeller © (2004-05-02 18:24) [7]

Именно перекрыть не получится. Но создать в наследнике одноименный виртуальный деструктор можно, тогда сначала вызовется твой, а потом предка.

← →
марсианин © (2004-05-03 09:57) [8]

ну как бы да. в потомке вместо override как в классах, в обьектах пишем virtual, иначе ошибка..
но ведет себя потомственный метод точь-в-точь как если бы он был override. и метод предка вызываем сами ч-з инхеритед.

Дело в том, что в классах можно и не поставить inherited, тогда деструктор предка не вызовется и получится утечка памяти, с очень плачевными последствиями если класс часто создаётся/уничтожается. Если же в объектах не поставить inherited, то ничего страшного не произойдёт, метод предка выполнится после метода наследника. Здесь inherited полезен в конструкторах и других методах, когда метод предка нужно выполнить в начале или где-нибудь в середине метода наследника.

> SPeller © (02.05.04 18:24) [7]

А? Правда чтоли? Господи, а я и незнал, всю жизь перекрываю, а оказывается это неправда...

+ [9]

Может таки пересмотришь свои взгляды? Путем чтения книг, справки и более внимательного изучения ООП применительно к Делфи.

Тихо... Без ругани и мата :)

Суть в специфики модеи наследования, создавая визуальные контролы, мы для наследования всех прелестей TControl - констуртора. Создаем не наш новый TMySuperButton=object(TControl) и TControl. Потому и деструктор не перекрываеться. Но память осбовождать надо... выход CustomData и CustomObj декструтор TControl CustomObj.Free вызывает - а нам это и надо, с невизуальными ситуация другая, чужой конструктор нам не нужен, мы за него не цепляемся потому работаем нормально.

Извиняюсь, действительно был неправ. Только, ув. тов. Palladin, повежливее надо быть, каждый может ошибаться. Действительно перекрывается полностью. Одно отличие — из метода предка не вызывается метод наследника.

_NewControl Найти похожие ветки