хитроback'й Delphi

[xrob]

иногда было бы неплохо чутка изменить стандартные компоненты...
при условии, конечно, что знаешь что делаешь =)
я знаю что делаю!
но!
ничего не меняется.
можно открыть любой стандартный pas - Forms, Grids, Classes и т.д.,
написать в них любую хрень, даже тупо русский текст без ничего
и преспокойненько скомпилировать рабочее приложение.
в обычной ситуации компилятор ругнется на каждую неправильно
написанную буковку, а здесь ему вообще по барабану.
но зато компилятор люто рвет и мечет по поводу не найденного *.dcu

посему можно сделать вывод что ему вобщем то класть на *.pas...
да и правильно в принципе, зачем нам pas, если есть dcu?

я в принципе эту проблему решил переносом нужных pas'ов в папку lib.
старые файлы я при этом "убиваю" - переименовываю, но с возможностью
восстановить исходное название, т.е. тупо *.0dcu

теперь при компиляции в lib'е компилится dcu для соответствующего pas'а,
и все нормально работает, мои изменения вступают в силу.
т.е. если я написал что у формы будет еще одно свойство - оно появляется.
так что проблема решена,
но все-таки интересно, почему так происходит?
почему стандартные компоненты не хотят реагировать на мои изменения?
защита от дурака? и почему для всего компилится dcu, а для некоторых - нет?
как он выбирает? от папок зависит?


p.s.
я так StringGrid уже переделал - научил сохранять таблицу в файл (разделение Tab),
загружать из файла, а так же сохранять в таблицу html - лично мне очень полезно!

//-- добавлено -----------------------------------------------------------------
что весьма забавно - Delphi гораздо хитрожопее, чем кажется на первый взгляд
если файл переименовать *0.dcu - он поймет что это за файл!

ковыряю TApplication, столкнулся с такой хренью:
unit [такой-то] был скомпилен под другой версией Forms.Application

оно думает меня это остановит, ага! )))

p.s. я решил проблему смайликов на форуме =)

[Аватар]

Мне кажется что менять исходники стандартных компонент не есть признак хорошего тона. Вдруг прийдется по каким-то причинам на другой комп с исходниками заявится, думаю совсем не понравится хозяину ваши модифицированные компоненты. Да и с переходом на другую версию дельфей с этими исходниками проблемы дополнительные будут. Не лучше ли на базе существующих сделать свои дочерние компоненты с дополнительными свойствами и методами? Нет особых проблем бросить наследованные компоненты в палитру и стандартным образом потом на форму их выбирать. С некоторыми компонентами я так и поступил, да и напрямую от TForm свои формы никогда не наследую. Разбил свои формы на сходные по функциональности группы и для каждой группы создал наследника от TForm c общими для группы дополнительными средствами. И этот наследник и используется дальше как родитель для форм приложения

[Пепел Феникса]

но все-таки интересно, почему так происходит?

у меня в Д6 исходники VCL находятся в отдельной папке, и эта папка только для исходников(для просмотра)
то есть uses она в ней не ищет. вот и причина почему не перекомпилирует.

[xrob]

Аватар, не соглашусь с вами по поводу хорошего тона,
ибо работа с компонентами - это тонкости разработки ПО,
и никого кроме меня не касаются.

а если придется заявиться на чужой комп, то почему сразу хозяину не понравятся мои модифицированные? может понравятся больше, чем стандартные! =)
я ведь их не просто так модифицирую.
и потом, если подумать, то я не изменяю стандартных компонентов,
я делаю их копии и изменяю их.
так что если приспичит - всегда есть возможность все восстановить

а уж версию делфи я врят-ли сменю. уж больно она мне нравится.
у меня Delphi 10 lite. минус в том что в ней нету 80% компонентов, которые есть например в делфи7,
но удобный интерфейс и возможность свернуть код процедуры (чего нету в делфи 7 )
лихо покрывают все недостатки. мне проще вручную портировать компоненты из д7 на д10lite,
чем работать в среде delphi 7.

Пепел Феникса, как я и предполагал - все дело в папке...

[Пепел Феникса]

ибо работа с компонентами - это тонкости разработки ПО,
и никого кроме меня не касаются.

стандартные компоненты ой как касаются, вы вполне можете унаследоватся от TCustomEdit(к примеру) переделать его как вам надо и все в порядке.

[xrob]

"стандартные компоненты ой как касаются"
Пепел Феникса, а не затруднит ли вас объяснить чего и как они касаются?

нее, TEdit мне не надо... мне TApplication подкорректировать.

Пепел Феникса, вам задачка =)
надо сделать некий компонент, который бы реагировал на сообщения,
присылаемые приложению. не ему лично, а вообще приложению.

требования:
1. кидать на форму с помощью MyComponent.Create(Form1).
2. возможность создать несколько таких компонентов (все должны работать).
3. они могут не знать друг о друге.

какие будут идеи?
от чего будете наследоваться?

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

[Пепел Феникса]

к сожалению разработчики VCL не использовали принцип какой был применен в формах(там точно). то есть хранение указателя на метод, который выполняет действия, тогда там при необходимости выстраивается цепочка вызовов обработчиков.

из легальных методов это применение OnMessage, но это ограничит программиста, так как в итоге он не сможет ручками использовать это событие(а точнее сможет применив цепочку обработчиков, тогда не нарушится работа компонента)
но, в принципе если есть компонент который работает с этим событием, в ручном написании обработчика не особо есть смысл.

ваш же метод(судя по всему), будет работать только при измененном исходнике.

[xrob]

Пепел Феникса, я не очень понял что вы написали...

приведу более практичный пример:

допустим вы кидаете на форму две кнопки.
каждая из них должна будет изменять свое положение исходя из размеров формы.

такое можно реализовать так:
в событии OnResize формы пишем код, изменяющий положение кнопок.
аргументы
+ это "легально"
- дополнительный гемор с описанием поведения кнопок

или так:
при создании кнопки, Create(Form1), назначать Form1.OnResize процедуру,
описанную в классе кнопки, которая (процедура) будет выполняться
при соответствующем событии формы.
аргументы
+ это "легально"
- это не будет работать.

а не будет работать потому что Form1.OnResize можно присвоить только одну процедуру.
если присвоить второй раз - просто перезапишется старая.

так как быть в таком случае?
вы что-то писали про "цепочку вызовов обработчиков", что вы имели в виду?

[Пепел Феникса]

http://programmersforum.ru/showthread.php?t=165451
я же выкладывал там ссылку, на компонент перехватывающий события(сообщения точнее) родителя, компонент работал с пультом в отдельном потоке, и посылал сообщения форме, далее через переопределение обработчика он обрабатывыл свое сообщение.
такой же принцип у TCoolTrayIcon.(но кнопке не нужно все связанное с Application.HookMainForm, ибо у нее всегда будет родитель)

вы что-то писали про "цепочку вызовов обработчиков", что вы имели в виду?

назначаясь на событие, мы запоминаем что там было до нас, если было чтото(не nil) то вызываем это, после своей обработки.

[xrob]

дада, моя тема, спасибо за инфу. я пока не очень понял что там, но поколуплю на досуге.

"назначаясь на событие, мы запоминаем что там было до нас" идею понял, вот только что там было до нас?
а до нас там была опять таки единственная процедура...
так что такой вариант будет работать не более чем с двумя процедурами... а если их всего три?

а я хочу сделать вот что:
в TApplication помимо FOnMessage создать FOnMessages:array of TMessageEvent;
в который можно будет назначить неограниченное кол-во процедур.
и кроме вызова
if Assigned(FOnMessage) then FOnMessage(Msg, Handled);
пробегаться циклом по массиву
for i:=0 to Length(FOnMessages) do if Assigned(FOnMessages[i]) then FOnMessages[i](Msg, Handled);

плюс написать свою функцию для добавления процедуры в массив,
которая будет возвращать индекс процедуры в массиве.

объект назначивший таким образом процедуру будет запоминать этот индекс
на случай если понадобиться убрать его процедуру из массива.

что вы об этом думаете?


p.s.
перекинул все *.pas из vcl в lib.
в GraphicUtils оказались неизвестно где объявленные константы цвета и из-за этого не хотело компилиться.
пришлось убить все цвета в 0 (черный), больше проблем не было.
кто знает для чего используется GraphicUtils.pas ?