О проверках в классе ComExcelDocument_RU

[Владимир Максимов]

Не так давно мне пришлось перелопачивать классы-наследники от ComExcelDocument_RU. Это были классы, работающие с ActiveX-компонентом OWC-SpreadSheet. И это были именно наследники, поскольку многие методы одни-в-один применимы как к собственно Excel, так и к этим компонентам.

Однако с ними оказалась следующая проблема. Самый первый выпущенный ActiveX компонент относился к версии Office 2000. Т.е. к 9 версии (m_Application.version()). Так вот, в старших версиях из поставки Office XP (10 версия) и Office 2003 (11 версия) оказалось что:

Значение Borders.LineStyle принимают значение из другого нумератора. Проще говоря, имеют другие допустимые значения.

Горизонтальное и вертикальное выравнивание осуществляется другими методами. Вообще другими.

Может, есть еще какие отличия, но пока не всплыли.

С другой стороны, у нас установлена версия AXAPTA 2.5. По умолчанию, в ней не предусмотрена возможность экспорта отчетов в Excel. Однако ребята из Columbus-а сумели "прикрутить" механизм такого экспорта передрав его из 3.0 Для этого они сделали еще один класс наследник (правда, напрямую от ComOfficeDocument_RU, что лично мне кажется странным).

Хотя, согласен, проверки на факт существования ссылки в m_comApplication явно лишние. Лишние не потому, что такого не может быть (еще как может!), а потому, что эти проверки не выдают никаких сообщений об ошибках! Т.е. отчет просто не выполняется, а почему - непонятно.

Если бы подобных проверок не было, то программист получил бы исключение и быстро нашел место ошибки. Хотя, в классе-родителе, в большинстве случаев, такое сообщение все-таки есть! А это уже явная подсказка разработчику "где копать". Где он ошибся.

Насчет именования.

Как Вы себе представляете перекрытие имени переменной в классе-наследнике? Т.е. если в классе-родителе переменная была названа m_comDocument, то извольте именно так к ней и обращаться в классе-потомке или создавайте новую переменную. Но в этом случае необходимо будет перекрыть вообще все методы класса-родителя. И зачем в этом случае родитель?

Ах, да, Вы не видите зачем нужен класс-родитель. Ну, так опять же недавно я делал запись служебной информации в созданный файл. Т.е. кто и когда этот файл (отчет) создал. Так вот, и для Word, и для Excel это делается совершенно одинаковыми методами. Буквально. Т.е. это явно имеет смысл выделить в класс-родитель.

То же самое относится и к BookMark. Вы смотрели методы класса ComWordApplication()? Как ни странно, в нем есть методы FindRange и InsertValue.