Case Не работает с Sender

[come-on]

А почитать про эти операторы? чтобы понять разницу

[Serge_Bliznykov]

Сообщение от come-on

А почитать про эти операторы? чтобы понять разницу

дык вроде бы читал.
Теперь хочу у знающих людей переспросить.

http://docwiki.embarcadero.com/RADSt...ass_References

Class Operators

Class methods operate on class references. Every class inherits two class methods from TObject, called ClassType and ClassParent. These methods return, respectively, a reference to the class of an object and to the immediate ancestor class of an object. Both methods return a value of type TClass (where TClass = class of TObject), which can be cast to a more specific type. Every class also inherits a method called InheritsFrom that tests whether the object where it is called descends from a specified class. These methods are used by the is and as operators, and it is seldom necessary to call them directly.

The is Operator
The is operator, which performs dynamic type checking, is used to verify the actual runtime class of an object. The expression:
object is class
returns True if object is an instance of the class denoted by class or one of its descendants, and False otherwise. (If object is nil, the result is False.) If the declared type of object is unrelated to class -- that is, if the types are distinct and one is not an ancestor of the other -- a compilation error results. For example:

 if ActiveControl is TEdit then TEdit(ActiveControl).SelectAll;

This statement casts the ActiveControl variable to the TEdit type. First it verifies that the object referenced by ActiveControl is an instance of TEdit or one of its descendants.

The as Operator
The as operator performs checked typecasts. The expression
object as class
returns a reference to the same object as object, but with the type given by class. At run time, object must be an instance of the class denoted by class or one of its descendants, or be nil; otherwise an exception is raised. If the declared type of object is unrelated to class - that is, if the types are distinct and one is not an ancestor of the other - a compilation error results. For example:

 with Sender as TButton do
  begin
   Caption := '&Ok';
   OnClick := OkClick;
  end;

The rules of operator precedence often require as typecasts to be enclosed in parentheses. For example:

 (Sender as TButton).Caption := '&Ok';

[come-on]

Ну так что тогда не понятно?
ас проверку делает, а зачем вам 2 проверки да еще и такие дорогие?

[Аватар]

http://www.transl-gunsmoker.ru/2010/...g-post_10.html

[Serge_Bliznykov]

Аватар, отдельное спасибо за ссылочку, имхо весьма полезно.

Теперь понятно, в чём здесь головная боль
кстати от GunSmoker'а, (по ссылке Аватара)
// выделение моё:

Вопросы производительности
В Win32 существуют небольшие накладные расходы на is- и as-проверки - потому что компилятору и RTL нужно пройтись по дереву наследования,
чтобы проверить соответствие класса.
В большинстве случаев это очень незначительная добавка, которую можно игнорировать.
Часто вам требуется сконвертировать объектную ссылку в конкретный тип, но вы хотите избежать исключения, поэтому вы пишете:

if Instance is TMyClass then
  MyObject := Instance as TMyClass;

Эта конструкция часто не нравится некоторым программистам Delphi - они указывают на то, что as повторно выполняет проверку, которая уже была сделана is.
В большинстве случаев это не имеет никакого значения, но если вы хотите, то можете переписать этот код так:

if Instance is TMyClass then
begin
  MyObject := TMyClass (Instance);

[come-on]

а можно и так

if Instance is TMyClass then
MyObject := Instance as TMyClass;
if MyObject = nil then
...

по всякому можно

[Serge_Bliznykov]

а можно и так

ну, так как раз нельзя!
(у Вас в коде нет начального присвоения MyObject, да и проверку на = nil лучше заменить на Assigned(MyObject)).


Но это всё уж не важно, дальше обсуждение можно уже и не продолжать, я понял, что конкретно имел в виду northener в пост #8

[come-on]

с чего это нельзя? начальные инициализации и т.п. просто опустим, можно еще операторными скобками , раз такое дело, не про то речь

[northener]

Сообщение от Serge_Bliznykov

Но это всё уж не важно, дальше обсуждение можно уже и не продолжать, я понял, что конкретно имел в виду northener в пост #8

Ну тогда ещё одно замечание. Я лично не вижу смысла в использовании оператора AS. Не, ну против его существования я не возражаю. Но вот где его использование необходимо или хотя бы желательно?
Если мы не знаем класс объекта, ссылка на который у нас имеется, то грамотнее всего выполнить проверку оператором IS, а потом уж выполнять некие действия в зависимости от результата проверки.
Если же мы точно знаем класс объекта, ссылку на который мы имеем (например у нас общий обработчик для нескольких кнопок), то зачем нам вообще нужна проверка класса? Ну разве что мы настолько невнимательны, что приписали этот обработчик какому-то компоненту другого класса. И на этапе отладки мы можем не сразу это увидеть.
Имхо тут бы лучше было бы делать проверку класса при прямом приведении типов, но только при включенной некоей опции компилятора.
P.S. Хотя это несбыточные мечты. Компилятором Дельфи уже давно никто особо не занимается.

[Sibedir]

Сообщение от northener

Я лично не вижу смысла в использовании оператора AS. Не, ну против его существования я не возражаю. Но вот где его использование необходимо или хотя бы желательно?

procedure GoodTest (F: TObject);
begin
  (F as TMyObject).DoSomfing;
end;

procedure BadTest (F: TObject);
begin
  if F is TMyObject then
    TMyObject(F).DoSomfing
  else
    raise EInvalidCast.Create('Invalid class typecast');
end;

AS = IS + Raise Error + Type Casts
Нужны по отдельности - пишем сами по отдельности. Нужны вместе и сразу - используем AS.

Не забывайте, что приложения иногда разрабатываются командно, на разных ЯП, разработка растянута во времени, код может попасть в библиотеку. Да мало-ли. Ваш код должен вести себя адекватно в любой ситуации.