Можно ли добавить метод к существующему интерфейсу dispinterface?
Как правило, метод не может быть добавлен к существующему COM-интерфейсу виртуальной таблицы или двойному COM-интерфейсу, поскольку может существовать производный интерфейс, поэтому расширение базового интерфейса нарушает его структуру.
Но можно ли добавить метод к существующему интерфейсу distpinterface? Будет ли это потенциально разрушительно для существующих пользователей?
Предположим, что для событий используется обычный интерфейс distpinterface, а также обычное использование библиотеки типов и внепроцессного COM-сервера.
Вы всегда можете реализовать IDispatch так, как хотите, он полностью динамичен. Минимум — это GetIDsOfNames->dispid и соответствующий Invoke(dispid), но если вы используете перекрестную квартиру (межпоточный, перекрестный процесс, перекрестный компьютер), вам понадобится tlb (который вы также можете реализовать из IDispatch), однако не все клиенты поддерживают это (например, VB/VBA/VBScript, .NET в основном поддерживают)
@RbMm, мне нужно расширить набор возможных событий, запускаемых COM-сервером, и мне нужно знать, можно ли отредактировать существующий dispinterface, чтобы добавить новый метод, или мне нужен новый dispinterface.
@RbMm, обычный EXE-сервер вне процесса. Клиенты разные. и я не контролирую их всех. dispinterface (не vtable, только диспетчеризация) используется для событий (которые запускаются на сервере и используются клиентами). Мне нужно добавить новое событие. Некоторым клиентам может потребоваться подписаться на новое событие, которое я добавляю, но некоторые продолжат использовать только старые события без перекомпиляции.
@RbMm, клиенты могут перекомпилировать, это вне моего контроля. И я спрашиваю о dispinterface, который не подразумевает записи в vtable.
Но можно ли добавить метод к существующему интерфейсу distpinterface? - да, просто новый уникальный ID/имя. Будет ли это потенциально разрушительно для существующих пользователей? - нет, они просто не будут использовать этот новый идентификатор/имя
Если я правильно понимаю, в вашем сценарии клиенты реализуют интерфейс dispinterface, а сервер вызывает Invoke к ним. Таким образом, у старых клиентов внезапно вызывалась реализация Invoke с DISPID, о существовании которого они не знали и не были готовы обработать. Теоретически это может привести к проблемам: клиентский код может сделать что-то вроде switch (dispid){ case DISPID_Event1: ... case DISPID_Event2: ... default: /* must be Event3 */ }, а затем новый Event4 будет ошибочно принят за Event3.
@IgorTandetnik, спасибо, это похоже на ответ.
Ответы 1
согласно комментарию Игоря Тандетника
Если я правильно понимаю, в вашем сценарии клиенты реализуют интерфейс dispinterface, а сервер вызывает для них Invoke. Таким образом, у старых клиентов внезапно вызывалась реализация Invoke с DISPID, о существовании которого они не знали и который не был готов обработать. Теоретически это может привести к проблемам -
клиентский код мог бы сделать что-то вроде
switch (dispid){
case DISPID_Event1: ...
case DISPID_Event2: ...
default: /* must be Event3 */
}
а затем новое событие Event4 будет ошибочно принято за Event3
что тебе действительно нужно сделать?