Сравнение ObjPtr(Me) с ObjPtr(Me.Form) - сравнение тёплого с мягким, так как Me и Me.Form имеют разные типы: ИмяVBAПроекта.Form_XXX и Access.Form. Объект может реализовывать разные интерфейсы, и возвращать ссылки на разные интерфейсы (но при вызове членов этих разных интерфейсов код этих членов будет обращаться к внутренним данным одного объекта). Для иллюстрации покажу на обычных классах.
Класс BaseClass: Класс Class1: Тестовая процедура: Мораль: сравнивайте ссылки, приведённые к одному типу, причём не к Object.

adv,

"Тост должен быть короткий, как выстрел" (c) Ну, или как дуплет
Как настоящий тост не всегда обращён к кому-то лично, так и этот "тост" был обращён к аудитории, сравнивающей указатели разных типов.


Изопропил,

по спецификации COM - безусловно, и я хотел включить это в пример. Но пришлось бы либо вызывать IUnknown::QueryInterface() самому (а вызов функции по адресу в VBA удовольствие сильно ниже среднего), либо включать в проект библиотеку типов, содержащую описание IUnknown (что во многом предпочтительнее, учитывая наличие, например, отличной библиотеки OLELIB.TLB ).

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

Впрочем, к чему эти сложности? Есть же оператор Is.

ё,

Про физический смысл у ObjPtr.
ObjPtr() возвращает адрес блока памяти такой структуры: О размере данных экземпляра, их структуре и значениях мы формально не можем предполагать ничего, это личное дело (деталь реализации) компонента. Поле pVtbl содержит адрес таблицы виртуальных функций такой структуры: Таблица виртуальных функций может совместно использоваться разными экземплярами компонента (значения pVtbl у разных экземпляров компонентов могут быть равны). Первым параметром виртуальные функции принимают значение ObjPtr() (типизированный указатель, имеющий это значение, при реализации виртуальной функции методом класса в ООЯП известен как this, Self, Me...), чтобы код виртуальной функции мог добраться до данных экземпляра компонента. Вот таков физический смысл значения, возвращаемого ObjPtr(), если мы говорим о компоненте (объекте COM) вообще. Но нам же нужен не сферический коньмпонент в вакууме, а компонент, который что-то умеет делать. "Что-то делать" выражается в том, что компонент реализует некие интерфейсы (интерфейсы COM, COM-интерфейсы), а клиент создаёт экземпляр(-ы) компонента, и взаимодействует с ним(-и), используя эти интерфейсы. На логическом уровне интерфейс является связанной группой (набором) функций. На физическом – структурой в памяти, описанной выше, а именно указателем на таблицу виртуальных функций, плюс сама таблица. Т. е. указатель на интерфейс – это указатель на указатель на таблицу (массив адресов (указателей на)) виртуальных функций. Интерфейс может наследовать другому интерфейсу, в самом простом виде, добавляя свои методы к методам родительского интерфейса (на физическом уровне – добавляя адреса виртуальных функций-методов в таблицу виртуальных функций после адресов методов родительского интерфейса). Корневым интерфейсом для всех COM-интерфейсов является IUnknown, содержащий три метода: QueryInterface, AddRef, Release.

Теперь, быть может не совсем плавно, перейдём к вопросу – как это, результат ObjPtr() разный, а объект (экземпляр компонента) один? Или наоборот, запросили указатели на разные интерфейсы у экземпляра компонента, и получили одинаковые значения этих указателей? Если совсем кратко, такие особенности – детали реализации компонента, и не более, на которые нельзя (формально) закладываться. Теперь подробнее.

Пусть мы пишем компонент, который должен реализовать три интерфейса: IUnknown, IX и IY. IX наследует IUnknown и добавляет свой метод x(), IY наследует IX и добавляет свой метод y(). Таким образом, для IUnknown в таблице виртуальных функций должно быть 3 указателя: на QueryInterface(), AddRef(), Release(); для IX – 4: на QueryInterface(), AddRef(), Release(), x(); для IY – 5: на QueryInterface(), AddRef(), Release(), x(), y(). И тут возникает два соблазна (следовало бы взять в кавычки, так как человек редко кодирует эти вещи вручную, здесь речь скорее о компиляторе) на почве оптимизации. Соблазн первый – объединить таблицы виртуальных функций, т. е. иметь 1 массив из 5 элементов, а не 3 в общей сложности из 12-ти. Но это довольно безобидно, как говорилось, таблица виртуальных функций может использоваться совместно. Соблазн второй – объединить указатели на таблицу виртуальных функций, раз уж сами таблицы объединены. Таким образом, даже для такого простого случая взаимоотношений реализуемых компонентом интерфейсов, имеем два экстремальных варианта (а в компоненте могут быть реализованы и промежуточные, и "боковые"):
1) Для независимых таблиц виртуальных функций область памяти экземпляра может описываться структурой: 2) Для полностью оптимизированных таблиц и указателей на них: Теперь представим, что клиент запрашивает у экземпляра компонента вернуть указатели на интерфейсы IX и IY. Для первого варианта компонент вернёт указатели, соответственно, со значениями VarPtr(pVtblIX) и VarPtr(pVtblIY) (разные), для второго – VarPtr(pVtbl) (одинаковые).


Честно говоря, не уверен, что ответил на все заданные вопросы, но голова в настоящий момент уже не варит. Лучше задайте ещё раз.