Объясните пожалуйста такую ситуацию. Например, в процедуре при создании формы procedure TForm.FormCreate(Sender: TObject) передаётся параметр Sender и если в процедуре я буду обращаться к нему как Sender мне обязательно приводить его к типу TForm, если я точно знаю, что инициатором этой процедуры является TForm? И почему, если необходимо приводить? И у Sender тип TObject, а не TForm? И вообще, если в какой либо процедуре параметром будет (Sender: TObject) его всегда необходимо приводить к типу того объекта который инициирует выполнение этой процедуру? Разъясните пожалуйста эту ситуацию.
Уважаемые авторы вопросов! Большая просьба сообщить о результатах решения проблемы на этой странице. Иначе, следящие за обсуждением, возможно имеющие аналогичные проблемы, не получают ясного представления об их решении. А авторы ответов не получают обратной связи. Что можно расценивать, как проявление неуважения к отвечающим от автора вопроса.
03-05-2008 11:39 | Комментарий к предыдущим ответам
Предлагаю еще один потенциально глюкоопасный вариант, но если Вы точно представляете, что творите, то можно:
procedure TForm1.TestButton(Sender:TObject);
var Button:TButton absolute Sender;
begin
ShowMessage(Button.Caption);
end;
Но если Вам передадут не TButton или nil, то будет что-то ... нехорошее.
14-04-2008 07:24 | Комментарий к предыдущим ответам
и пришел к выводу что практически 90% программеров не понимают как он работает, поэтому даже рекомендуется писать WHILE TRUE DO ... BREAK.
А Спольски утверждает, что есть программисты, у которых остутствует часть мозга, ответственная за понимание указателей. Неужели из этого следует вывод, что указатели - это плохо? :)
Сам склоняюсь к такому выводу: чрезмерное и необдуманное использование with - может иметь плохие последствия. А там, где его использование оправдано - оператор очень даже облегчает жизнь.
14-04-2008 06:45 | Комментарий к предыдущим ответам
Ну, не помню я у себя ошибок при работе с WITH... Только пока не копался сильно.
Так все-таки "не помню" или "не копался"? :)
На самом деле, при использовании with легко наступить на грабли, когда with задает идентификатор по умолчанию для тех выражений, которые прогаммист вовсе не имел ввиду. Ловится тяжело...
14-04-2008 06:26 | Комментарий к предыдущим ответам
Пополню список GOTO и WITH... UNTIL плохо ;)
Не то чтоб совсем плохо, но также как с WITH Кто-то умный проанализировал все случаи того же самого использования и пришел к выводу что практически 90% программеров не понимают как он работает, поэтому даже рекомендуется писать WHILE TRUE DO ... BREAK.
14-04-2008 06:18 | Комментарий к предыдущим ответам
>>> Так что ничем ситуация с with не отличается от goto, препроцессора и предохранителя на пистолете
Дык... На пистолете "Гюрза" нет флажка-предохранителя как на пистолете Макарова. Однако, почему-то спецлужбы предпочитают Гюрзу, а не ПМ :D
Ну, не помню я у себя ошибок при работе с WITH. А вот громоздкий нечитаемый код (например, при работе с Canvas) помню хорошо. Так что преимуществ явно больше, чем недостатков ;-)
Но я не про это... Я про догмы. Кто-то умный проанализировал все случаи того же самого использования GOTO и сделал выводы о том, что в большинстве случаев сложившаяся практика использования данного оператора является плохой. Подозреваю даже, что подробно объяснил, какие случаи являются плохими и почему. Но народ у нас простой ("Ты не выделывайся, ты пальцем покажи"): усекли до уровня простого понимания выводы и возвели в ранг догмы: GOTO -- ПЛОХО! Подозреваю, что то же самое и с WITH. Только пока не копался сильно.
Если это всё происходит внутри метода класса TForm1, правильнее вообще обращаться к свойствам через Self, причём указывать его явно вовсе не обязательно :)
Что касается переменной Form1, то надо чётко представлять себе, на что она ссылается, и обращаться через неё только тогда, когда вам нужен именно этот объект, а не какой-то другой.
Geo:
А с чем тут сражаться? То, что с with бывает удобнее писать, чем без него - факт. То, что статистически with даёт ошибок больше, чем преимущств, тоже факт. Так что ничем ситуация с with не отличается от goto, препроцессора и предохранителя на пистолете.
Закономерный вопрос, меня до сих пор иногда волнует. Скорее всего действительно для единообразия. А чтобы очень часто не делать приведение типов в обработчике такого события, имеет смысл делать так:
procedure Form1Create(Sender: TObject);
var
Form: TForm;
begin
Form := (Sender as TForm);
// Далее работаем с переменной Form, а не параметром Sender
end;
Кроме того, TObject прародитель всех объектов, значит априори совместим с любым из своих потомков, поэтому если параметр процедуры объявлен как TObject в нее можно перередать переменную любого класса. Но так-как у TObject естественно нет методов, реализованных у его потомков, то вызов в лоб, например, Sender.MyNewMetod, будет расценен компилятором как обращение к неописанному в классе TObject методу, со всеми вытекающими последствиями. А вот приведение (Sender as MyNewClass).MyNewMetod отработает правильно, т.к компилятор будет знать, что MyNewMetod нужно искать в экземпляре MyNewClass.
Ответы замечательные, но по-моему, автор из них вряд ли извлечет практическую пользу...
procedure TForm1.Button1Click(Sender: TObject);
begin
// Можно проверить, является ли Sender конкретным объектом
if Sender = Button1 then
ShowMessage('Обработчик вызван кнопкой Button1');
// Можно проверить, является ли Sender экземпляром конкретного класса
// Для доступа к свойствам класса требуется приведение типа
if Sender is TButton then
ShowMessage('Обработчик вызван кнопкой ' + (Sender as TButton).Caption);
// Для доступа к свойствам класса, унаследованным от TObject, приведение типа не обязательно
ShowMessage(Sender.ClassName);
end;
Добавлю к ответу Антона, что в общем случае в обработчки события в качестве параметра Sender может быть передан указатель на разные экземпляры разных классов. И может быть даже передан NIL. Поэтому использование типа TObject гарантирует, что мы сможем реализовать любой способ вызова, который нам может потребоваться.
Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter. Функция может не работать в некоторых версиях броузеров.
