Win2008 и вызов методов COM-объектов

[AndyD]

Продолжение темы Новые счет-фактура и его друзья - Постановление от 26 декабря 2011 г. N 1137

Цитата:

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

Можно подробнее ?
Не понял вашу мысль.

Насчет ComDispFunction - я уже писал, что с помощью этого класса вызовы методов COM-классов происходят без ошибок. По-моему, при этом применяется раннее связывание

Насчет ООП - вспоните, что класс Com в аксапте это точно такой же класс, как и любой другой и что от него можно создавать наследников.
Так же вспоните, что у этого класса есть замечательный метод attach(), позволяющий подключить к созданному экземпляру класса уже существующий COM-класс
Еще вспомните про то, что можно перекрывать методы и создавать в них собственный код.


В общем, идея была такая - необходимо создать иерархию классов, наследующих от класса Com и соотвествующую иерархии вызываемых COM-объектов.
В метод new() классов иерархии передавать ссылку на созданный COM-объект и с помощью вызова метода attach() создавать привязку
Перекрыть вызываемые методы COM-объекта. Внутри этих методов делать вызов с помощью класса ComDispFunction
Если вызываемый метод возвращает ссылку на другой COM-объект, то возвращать ссылку на экземпляра класса иерархии, в вызов new() которого передавать COM-объект


В результате, для корректной работы, требется изменить вызов первоначального создания COM-объекта в Аксапте на создание соответствующей класса из иерархии с передачей в него COM-объекта
Для Excel это будет выглядеть примерно так

COM excel;
;

excel = new DEV_ExcelApplication(new Com('Excel.Application'));

И отследить прямое создание COM-объектов в коде. Такие как, например, в методе SysExcelCells.Item()

public SysExcelCell item(int _row, int _column)
{
    return SysExcelCell::construct(version,cells.item(_row,_column));
//    return SysExcelCell::construct(version,COM::createFromVariant(cells.item(_row,_column)));
}

Если не перекрывать какие-либо методы из вызываемого COM-объекта, то ничего страшного не случится. При вызове будет ипользоваться позднее связывание - с ненулевой вероятностью напороться на ошибку при вызове

Ну и в качестве иллюстрации - во вложении пример иерарихии из нескольких классов, реализующий вышеизложенный подход для Excel (в чисто иллюстративных целях).


Замечу, что с помощью подобной иерархии и небольших изменения в классе COMExcelDocument_RU делается выгрузка в Excel на терминальном сервере под 2008R2, на котором тусуется под сотню пользователей, а загрузка процессоров редко опускается ниже 70%, а зачастую составляет все сто

Кстати, ко всему прочему, вызовы методов еще и быстрее выполняются

[Logger]

Здорово.
Даже не верится.
Как-то слишком просто все получается.

Получается, что если аккуратно переписать обращения к COM-объекту, то можно спокойно жить с текущим ядром.

Получается что в MS про такое решение тоже не дотумкали, раз не предложили его для EVGL. По сути можно ведь создать просто фикс на X++, который поправит иерархию SysExcel и COMexcelDocument_RU и все станет красиво. Столько людей избавится от головной боли, а сотрудники MS от икоты

[AndyD]

Ну, я не со зла

[Pustik]

так и не понял причем тут EVGL)))

[Logger]

Цитата:

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

так и не понял причем тут EVGL)))

Читайте исходную тему, из которой AndyD создал текущую. В стартовом сообщении есть ссылка на неё.

Вот сообщение EVGL :
Новые счет-фактура и его друзья - Постановление от 26 декабря 2011 г. N 1137

[ZVV]

Интересная тема.
А может кто-то может выложить реальный рабочий образец COMExcelDocument_RU с данными изменениями?

[ZVV]

Почему-то у меня при попытке проиложить это к отчёту на ComExcelDocument_RU всё рушится при первой же попытке использовать перегруженный метод visible() (в методе initApplication()).

Не могу понять что не так.

Единственное изменение, которое внёс пока ComExcelDocument_RU:

#define.ExcelProgId("Excel.Application")
protected void newCom()
{
    //BP deviation documented
    //m_comApplication = new COM(#ExcelProgId);
     m_comApplication = new DEV_ExcelApplication(new COM(#ExcelProgId));
}

[ZVV]

Отбой, нашёл. В было пару мелких ошибок в проекте.

[AndyD]

Цитата:

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

Отбой, нашёл. В было пару мелких ошибок в проекте.

Да, прошу прощения

Для Visible надо инициализировать так

application_VisibleSet = this.createPropertyPut(#visible);

[ZVV]

Да, верно.

К слову, была ещё ошибка:

В методе DEV_ExcelRange.valueSet пропущено отрицание:

   if (range_ValueSet)
         range_ValueSet = this.createPropertyPut(#value);

Надо

if ( ! range_ValueSet)

А так вроде первичный тест прошёл успешно...

[Максимка]

Немного смущает метод new в DEV_Com. Вторая ветка условия не выполнится никогда:

public void new(anytype _interface) 
{
    COM         com;
    COMVariant  var;
    ;

    super();
    if (typeof(_interface) == Types::Class && classidget(_interface) == classnum(COM))
    {
        com = _interface;
        this.attach(com.interface());
        com = null;
    }
    else if (typeof(_interface) == Types::Class && classidget(_interface) == classnum(COM))
    {
        var = _interface;
        this.attach(com.iDispatch());
        var = null;
    }
    else if (typeof(_interface) == Types::Integer)
        this.attach(_interface);

    this.attachMethods();
}

Видимо там подразумевftnся условие для COMVariant, и тогда должно быть:

...
else if (typeof(_interface) == Types::Class && classidget(_interface) == classnum(COMVariant))
    {
        var = _interface;
        this.attach(var.iDispatch());
        var = null;
    }
...

[Максимка]

Вопрос автору. Имеет ли смысл создавать привязку всех методов COM объекта внутри функции attachMethods? Или же лучше создавать ее внутри каждого метода при первом вызове.

[AndyD]

По-моему, нет
Многие методы могут вообще не вызываться за время жизни объекта - зачем создавать привязку?

Изначально предполагал использовать привязку в этом методе для наиболее востребованных функций, но не думаю, что это как-то сильно увеличит производительность

[Максимка]

Спасибо, так и думал