|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
Object Inspector. Потеря обработчиков событий компонентов фрейма
Создаем фрейм, содержащий контролы, которые имеют собственные обработчики событий. При помещении на форму таких фреймов нужно быть с ними очень осторожными в design-time. Достаточно случайно "войти" в процедуру обработки такого события для компонента фрейма, чтобы IDE автоматически сформировала обработчик этого события для формы, а не для фрейма. После этого, при удалении этого обработчика, обработчик "задетого" события во фрейме полностью игнорируется. "Камушек" кроется в том, что IDE при удалении обработчика из ObjectInspector не вытирает упоминание о нем из файла *.dfm, а просто присваивает ему там nil! Для иллюстрации "камня" приводится тестовый проект. На форме лежат два совершенно одинаковых фрейма, исходный код и OI показывают, что эти фреймы абсолютно идентичны, но(!) один из них отрабатывает нажатие на кнопку, а второй полностью его игнорирует. Источник беды виден в файле формы *.dfm (View as text) :
ТИПОВЫЕ РЕШЕНИЯ
Скачать тест StoneTest_26.zip (1.8K) КОММЕНТАРИЙ: Еще один метод борьбы заключается в правильном способе удаления ненужного обработчика. Ведь нам нужно вообще удалить нечаянно созданный обработчик события с формы, не так ли? Очистка события в OI только отключает процедуру от компонента, не удаляя ее из кода модуля. И правильно делает - она могла быть задействована где-то еще. Если действовать "по всем правилам искусства", как рекомендуют классики, то надо очистить тело процедуры обработчика от кода между begin и end, а затем просто сохранить файл (F2 в классической раскладке). IDE Delphi при сохранении файла очищает форму от пустых обработчиков, и делает это корректно (все в точности возвращается назад). Так что, может быть, это не глюк, а фича такая: "OnClick = nil" - способ отключить унаследованный от фрейма обработчик, не прибегая к коду. |
  |
токарные станки . Ищешь мишуру - мишура. . Лом титана - прием металлолома. . Ищете робот-пылесос - iclebo home. . |