Ошибка времени выполнения в ComExcelDocument_RU.findRange()

[gl00mie]

Цитата:

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

Тоже столкнулись с этой проблемой, идея сделать как в российском функционале, с макросами на try catch очень не понравилась, да и объем переписывания немалый

Если вы про методы класса ComExcelDocument_RU, то, по-моему, это ерунда, другое дело, что это на самом деле не спасает. И еще очень жаль, что для создания экземпляров этого класса не используется статический construct(), нашедший повсеместное распространение в AX 2009

Цитата:

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

Проблема возникала только на системах с Win7, XP + Office 2010 + dax 2009 работало без проблем

Попробуйте во время длительного экспорта/импорта попереключаться с окна Аксапты на окна других приложений и обратно или потыкать мышкой в окно Аксапты - все еще "работает без проблем"?

Цитата:

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

Когда искал причину, увидел что в других языках обращения к COM компилируются с атрибутом [STAThread] - однопоточное исполнение, ну и появилась мысль что многопоточность Win7 мешает жить.

Я, может, отстал от жизни, но вроде винды не умеют распараллеливать работу приложения на большее число потоков, чем предусмотрено самим приложением (за исключением, может, кода сервисных библиотек, которые могут создавать собственные дополнительные потоки).

Цитата:

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

Сейчас все протестировано в разных связках, в том числе и в 64-битной системе, все работает, и переписывать нужно только способ запуска класса

Попробуйте еще на терминальном сервере с несколькими одновременно работающими сессиями с Аксаптой - причем даже на w2k3 (который ведать не ведает про заморочки W7/W2K8) - узнаете много интересного

Цитата:

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

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

"Суха теория, мой друг, но древо жизни зеленеет..." Я лично для себя пришел к выводу, что надо все нафиг переписать на .NET, как рекомендовали тут. Объем модификаций вроде как ощутимый, но хочется реально решить проблему "враз и навсегда", а не шаманить с макросами try/catch. Семейство классов SysExcel* модифицируется на раз, с ComExcelDocument_RU все сложнее из-за того, что его экземпляры создаются напрямую через new(). Пока есть реализация на уровне proof of concept, о результатах тестирования непременно доложусь.