Здравствуйте,
Решил начать создание компонента с изучения примера из книги "Учебник для начинающих по Delphi 7". Это распространенная электронная версия, там есть пример "фазенда" про label, в который можно вводить только цифры. Почему при создании компонента делфи хочет какой-то файл KEYHOLELib_TLB.dcu ?

И ещё вопрос: допустим, что я хочу как-то по-особому отрисовать контрол (или, например,как коллега из соседней темы, сделать кнопку треугольной=)), тогда как переопределить процедуру? Я понял так: если у контрола-предка есть событие OnPaint, OnMouseEnter и т.п., то мне нужно в своем компоненте сделать так:


Тогда как проще узнать параметры, передаваемые в процедуру? Лазить по всем предкам?

> label, в который можно вводить только цифры

может TEdit? Label - это статичная надпись. Не знаю, что это за библиотека - KEYHOLE, но, видимо ваша программа использует из неё компоненты, но сама библиотека была удалена либо не установлена должным образом. Чтобы удалить пакет из Делфи 7: Component / Installed Packages / <имя> / Remove

>  procedure OnPaint(.....); override;

OnXXX - обработчики событий, они являются полями-уазателями метдовом обработки, а не методами, поэтому их нельзя перекрывать. Нужно перекрывать соответствующие методы, например Paint, но не обработчик OnPaint, что, в общем, и невозможно

> Решил начать создание компонента с изучения примера из книги

Примите совет (о котором, если Вы ВСЕРЬЕЗ решили научиться ГРАМОТНО  писать компоненты, не пожалеете ТОЧНО).

Сделайте поиск и найдите в этом форуме ссылку на электронный вариант книги Конопки. Скачайте ее и начните с ЕЕ изучения и разборов примеров в НЕЙ.

Потом тысячу раз скажете нам с Рэем "спасибо". Ему - за книгу, мне - эа совет.
:о)

> ors_archangel ©   (08.01.07 22:34) [1]

Да, в том примере Edit. Это я собирался сделать из TLabel мегакнопку. Думаю, обводить её по бордеру при событии МаусЭнтер и т.п. (как в ХР) Я не пользуюсь темами в ХР, поэтому хотел бы сделать красивые кнопки, комбобоксы и т.п., доступные при классическом оформлении (как Вин98) =)

> например Paint, но не обработчик OnPaint

Т.е. если у предка есть OnXXX, то это значит что есть XXX, которую можно перекрыть?

> Юрий Зотов ©   (09.01.07 01:43) [2]

Thx!

> Т.е. если у предка есть OnXXX, то это значит что есть XXX,
>  которую можно перекрыть?

Не всё так просто :( Каждый раз нужно исследовать конкретно, но в  архитектуре Delphi ООП есть обработчики сообщений (событий) Windows: WM_XXX, EM_XXX и т.д., с которых чаще всего всё и начинается, исследования можно начинать от них. Например, когда OS считает, что окну нужно перерисоваться, то оно посылает ему сообщение WM_PAINT, соответственно, если компонент реагирует на это сообщение, то ты найдёшь одноимённый метод


- но его желательно не перекрывать, иначе ты нарушишь структуру обработки сообщений, и как следствие, тебе, скорее всего, придётся писать много дополнительного кода, не исключая WinAPI, лучше по возможности оставаться на уровне VCL

Я знаком с Винапи и знаю Ассемблер, в принципе не проблема сделать всё на Апятах (это быстро и иногда даже требует меньше кода, чем ООП компоненты) с использованием ООП, я так и задумывал создание кнопок и прочей лабуды, но не думал, что придется ещё и предков досконально исследовать. Во всяком случае, если использовать Апи - то всё понятно, а то вот так падает ООП-приложение где-то и думай что делать, а оказывается что-то где-то не так или не то перекрыто =(

У меня та же история, но всё-таки, мой тебе совет, лучше по возможности оставаться на уровне VCL, эффективность - это одно, а целостность и отказоустойчивоть - это другое, ведь не надо каждый раз исследовать всю VCL, она написана довольно, как говорят, красиво, т.е. это не сложно, тебе сложнее будет отказаться от "лёгких", но одноразовых решений с помощью WinAPI, WinAPI - чато единственный путь, но сначала нужно искать пути решения через VCL, хотя бы потому, чтобы не зря таскать с собой более 300 kb OOP чертовщины - заставим её работать на нас!
:)
ООП есть ООП, в нём всё более переплетено, чем в API, особенно в части расширения: приходится знать иеархию и общие принипы построения конкретной системы методов классов, когда в чистом функциональной парадигме мы довольно конкретно можем отделить любую функциональность, не исследуя зависимости между функциями - потому что каждая из них довольно самодостаточна, но в конечном итоге, особенно в обласи GUI - ООП выигрывает, потому в GUI действительно есть легко просматриваемая иеархия объектов и полиморфизм тоже помогает
:)