2 Лох:

Африка, дикие люди, однако... А вот интересно, что у Control'а есть ItemData, хотя оно нужно только для ComboBox'а и ListBox'а.

wara, я написал не Control, а Variant. У Variant'а тоже должны быть все мыслимые в мире свойства?

> Это я и сам знаю, я спрашивал : "Где смотреть?"

Вот у них и смотреть. Что значит где? В Object Browser'е у классов TextBox, CommandButton и т.д.

Никуда. Такой возможности нет.

wara, но ведь тот же вопрос спрашивается, если мы описываем нечто как Variant. Почему в случае с Variant'ом тебе это не мешает? Тоже надо быть телепатом. Не хочешь быть телепатом - описывай как TextBox и т.п.

Я не знаток, но я не понял. (Ух, как прозвучало... Надо записать.) Я не понял, в чем вопрос. По-моему, на нашем уровне все объяснимо.

1. TextBox и Form_Форма1 - это конкретные классы, у которых есть известно какие свойства и методы.

(Кстати, между ними есть разница: сисок контролов Form_Форма1 на этапе компиляции известен не полностью, поэтому я могу написать

Dim f As New Form_Форма1
f!MyTextBox = 1

и это пройдет компиляцию, даже если контрола по имени MyTextBox на этой форме нет. А вот

f.MyTextBox = 1

пройдет только при условии, что такой контрол либо свойство есть. Короче, я отвлекся.)

2. Супротив тому, Form, Control, Object и Variant - это не конкретные классы, а, как ты сам и сказал, только интерфейсы. Когда создается объект, он всегда будет не просто Form, Control, Object или Variant, а нечто конкретное. (Если на меня надавить, я уберу из этого списка Variant, но это ничего не изменит в ходе рассуждений.)

3. Теперь так. Если мы описываем переменную сразу как объект конкретного класса (1), то компайлер знает, чтО ему нужно проверять, ибо у него есть список свойств и методов этого класса. (Да и то вот список контролов формы может меняться динамически, поэтому синтаксис с ! на этапе компиляции не проверяется.) Ежели же мы ее описываем как некий интерфейс (2), то компайлер до момента позднего связывания не проверяет ничего, ибо отсутствие свойства в интерфейсе еще не означает, что этого свойства так и не будет у того объекта, на который во время исполнения сошлется наша переменная.

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

TextBox и Form_Форма1 - это непосредственно то, чем данный объект является. Называй хоть классом, хоть интерфейсом. (Кстати, у класса тоже есть свой интерфейс, сиречь список его свойств и методов, включая синтаксис обращения к ним.) По описанию TextBox и Form_Форма1, содержащемуся соответственно в компайлере и в файле mdb, компайлер однозначно и полностью видит весь интерфейс объекта и знает, что с этим объектом можно делать (кроме списка контролов формы, который на этапе компиляции не проверяется, если писать через !).

С другой стороны, Form, Control, Object и Variant - это всего лишь некие кусочки интерфейса объекта либо даже менее того. Объект, описанный как TextBox, поддерживает весь интерфейс Control'а и плюс что-то свое. Но объект, описанный как просто Control, - это нонсенс, его можно описать, но с ним ничего нельзя сделать, пока он не сослан на конкретный TextBox и т.п. А попытка описать что-то As New Object вообще обречена - строчка красится красным. Именно поэтому у таких переменных компайлер знает только то, что он ничего не знает, и оставляет проверку синтаксиса до момента связывания.

Мммммммм... Лох, ты меня ввел в задумчивость.

> > TextBox и Form_Форма1 - это непосредственно то, чем данный объект является
> Нет. Это только одна из граней объекта. В примере, данным Нуф-Нуфу Форма1 являлась еще и Class1.

Это не "еще и". Я провожу разницу между окончательным классом (или полным интерфейсом) и кусочками интерфейса. Если переменная описана как кусочек, то ошибок компиляции выдается меньше. Class1 - это кусочек Формы1.

> Dim frm1 As Form_Форма1' Метод есть, и компилятор об этом знает (если хочет) '
> Set frm1 = frm ' Объект тот же самый '
> Debug.Print frm1.Huy ' Но ошибка есть '

Это значит, что Implements вообще не работает. Правильно ли я тебя понял?

> По описанию TextBox компилятор однозначно и полностью видит только интерфейс TextBox. По описанию Control компилятор однозначно и полностью видит только интерфейс Control. Только для контрола то, что он (компилятор) не видит - он почему то отправляет в IDispatch, а для текстбокса - нет.

Потому что Control - это кусочек, требующий конкретизации. А TextBox - это окончательный интерфейс, который весь может быть проверен на этапе компиляции.

> > Form, Control, Object и Variant - это всего лишь некие кусочки интерфейса
> Это полноценные интерфейсы. Просто одна из граней объекта. Не единственная, ну так и TextBox тоже не один у объекта.

Что значит TextBox тоже не один?

> Любой объект можно описать как Public Not Createble (в VB), и его тоже нельзя будет создать через New.

OK.

> > Объект, описанный как TextBox, поддерживает весь интерфейс Control'а и плюс что-то свое
> Нет. Это было бы наследование, а его нихт.

Это не наследование, а просто интерфейс TextBox'а написан так, что он включает в себя интерфейс Control'а. Это было бы наследование, если бы Control включал полные описания всех своих свойств и методов, тогда как он включает только их шапки.

> Объект может поддерживать интерфейс TextBox, интерфейс Control и что угодно еще.

Но обрати внимание, что "интерфейс Control и что угодно еще" обязательно является подмножеством интерфейса TextBox.

> Методы в разных интерфейсах могут даже называться одинакого, ну и что с того? Ты ведь не скажешь, что ADO.Recordset - это DAO.Recordset плюс что-то свое? А методы у них одинакого называются многие.

Пример не принят, потому что DAO.Recordset - не просто интерфейс, а класс с описанными методами.

> Объект, описанный как TextBox - тоже нонсенс. Его тоже можно описать, но ничего с ним нельзя сделать, пока он не сослан на конкретный TextBox.

Но это ничего не меняет с точки зрения того, какими его свойствами и методами разрешено пользоваться.

> Или даже на некий объект, который может быть чем угодно, при условии что он еще и текстбокс.

Это как это? Ты можешь добавить к текстбоксу свои свойства и методы? Всё его "что угодно" - это только то, что входит в стандарт TextBox'а.

> Потому как надо "конкретный интерфейс" (Form_Форма1), "компилятор видит все методы этого интерфейса" (function huy()). Ну так и Form - конкретый интерфейс. И компилятор тоже видит все его методы.

Разница в том, что у интерфейса Form могут оказаться свойства и методы, неизвестные на этапе компиляции.

> но как интерфейсу удается сказать компилятору, что он ни хера не интерфейс, а так, херня какая-то?

Поскольку и Form, и Control - это интерфейсы, созданные не юзером, то компилятор просто знает, что именно эти интерфейсы таковы. Все интерфейсы, созданные юзером, считаются полными, потому что во время исполнения программы у них не могут возникать новые свойства и методы, за исключением изменений в коллекции Controls.

> Что нужно сделать, чтобы язык типа VB не найдя метод в библиотеке типов не ругался при компиляции?

Не факт, что это существует. Все юзерские интерфейсы с точки зрения этого свойства одинаковы.

Вот.