Excel - проверить существование Range

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

Alexanderis.ua

А Вас не удивлят сама постановка вопроса в данной теме? Если с именованными ячейками все так замечательно, то зачем вообще проверять факт их существования?

[grishin]

Мы около трех лет назад написали машинку :
Опрашиваем шаблон Excel какие именованные ячейки есть.
Потом алгорим выводит в данные ячейки нужные значения
Имеем один универсальный алгоритм на любое количество отчетов.
Это дало возможность не программерам каждый раз следить за отчетами,
а самим пользователям корректировать шаблоны как им надо.
Они просто ставят оговоренные метки в нужное место шаблона.
Есть определенный алгоритм разделения меток шапки и табличной части.

Для тех кто будет это использовать хочу предупредить, что есть однако одна неприятность при удаление именованных ячеек в шаблоне.
Они не удаляются из списка ActiveWorkbook.Names и при опросе передаются в Axapta, но при выводе данных Axapta вываливается с ошибкой. На данный момент решили данную проблему созданием VBA макроса, обеспечивающего удаление "неправильных" именнованных ячеек из ActiveWorkbook.Names

[sukhanchik]

Цитата:

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

Имеем один универсальный алгоритм на любое количество отчетов.
Это дало возможность не программерам каждый раз следить за отчетами,
а самим пользователям корректировать шаблоны как им надо.
Они просто ставят оговоренные метки в нужное место шаблона.
Есть определенный алгоритм разделения меток шапки и табличной части.

Любая универсальность усложняет поддержку. Я тоже такую машинку писал - для Word/Excel. Также с разделением шапки и табличной части. Правда не заморачивался выковыриванием именованных ячеек, а просто полагался на корректность настроек машинки, ибо сложность решения ошибки с лихвой компенсировалась ее некритичностью.

Из плюсов такого подхода:

• Кажущаяся универсальность на этапе проектирования (=можно выбить бюджет)
• Возможность заполнения шаблона по принципу 80/20, т.е. легкое автоматическое заполнение 80% полей в шаблоне
• Возможность корректировки шаблона Word/Excel пользователем

Из минусов:

• Универсальности нет. Вот нет и все. Обработкой каждого отчета все равно занимается свой класс, несмотря на настройки. Настройки могут помочь в выводе информации, но не помогут в ее формировании. Конечно классы являются наследниками, иерархия, почти как наследники RunBase, но ... все же каждый класс индивидуален. Особенно это заметно, когда используется табличная часть, т.к. там используется цикл, уникальный для каждого отчета.
• Сложность настройки. В качестве источника данных для именованных диапазонов могут быть поля таблиц и дисплей-методы (у меня было так). Даже если не брать в расчет дисплей-методы - то какими же знаниями должны обладать пользователи, чтобы уметь выбрать правильное поле при создании настройки? Особенно учитывая тот факт, что даже в стандартном функционале поля именуются так - что пока не узнаешь, как они называются в АОТе - не поймешь, какое поле требуется выбирать. При этом пользователь обычно не видит, какое поле в терминах АОТа используется в обычной форме, хотя может и знать - что ему надо именно это поле. Про дисплей-методы вообще можно забыть - тут ориентация нулевая. Кстати - при настройке - каким образом облегчается жизнь настройщика? Или он должен знать все поля и методы на таблицах?
• Неуниверсальность настройки. Представьте себе - вам нужно вывести в одном случае фразу из БД (например, название региона) в именительном падеже, а в другом - в родительном. Это будет 2 источника данных? А настройщик не запутается? А если нужно вывести 3 суммы - без НДС, с НДС и НДС - тоже в именительном и родительном падеже? Без программирования (даже минимального) не обойтись. А если программировать - то зачем тогда себе усложнять жизнь настройками?
• Переносимость настройки. Программный код переносится легко через XPO. Легко - означает в один клик по проекту. А при импорте - можно сравнить - что поменялось. Плюс есть система контроля версий кода. Обладает ли этим утилита переноса данных? (Группа определений или еще какая?). А можно ли "оптом" переносить настройки ? Например, также легко, как модели в АХ 2012 или приложение в АХ 2009.
• Отладка настроек. В состоянии ли настройщик адекватно проанализировать - что у него не получается в настройке? Или должен постоянно звать программиста? Если должен звать - то см. пункт выше - зачем тогда себе усложнять жизнь настройками?
• При подготовке шаблона нужно уделять тщательное внимание именованию ячеек/закладок и следить за тем, чтобы их названия были понятны настройщику. Иначе все опять скатится до программиста.

Так что тут палка как говорится о двух концах...

[Alexanderis.ua]

Цитата:

Сообщение от Владимир Максимов

Alexanderis.ua

А Вас не удивлят сама постановка вопроса в данной теме? Если с именованными ячейками все так замечательно, то зачем вообще проверять факт их существования?

Зачем проверять наличие записи в таблице SQL если он такой замечательный?

Я не говорил, что все замечательно. Моя мысль проста - иногда использование именованых ячеек оправдано. Просто небольшая контра к Вашей категоричности с примером из жизни.

Вот еще один пример - оттуда же. С 16 декабря 2011 вид НН изменился. Добавились новые ячейки и перетасовался порядок. Старые НН нужно печатать в прошлом варианте.
Сделали 2 шаблона и на всякий случай проверяем наличие ячеек - чтобы не плодить кучу условий на печати - если ячейка есть, то напечатается.
Это к вопросу о "зачем вообще проверять".

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

Цитата:

Сообщение от Alexanderis.ua

Я не говорил, что все замечательно. Моя мысль проста - иногда использование именованых ячеек оправдано. Просто небольшая контра к Вашей категоричности с примером из жизни.

Лично я писал, что выгоды от использования именованных ячеек значительно меньше, чем кажется на первый взгляд. Крайне редки случаи, когда их использование действительно оправдано. Это одна из тех вещей, которая хороша для презетаций, но не очень-то удобна в реальной практике. Вроде древовидных справочников.

Цитата:

Сообщение от Alexanderis.ua

Вот еще один пример - оттуда же. С 16 декабря 2011 вид НН изменился. Добавились новые ячейки и перетасовался порядок. Старые НН нужно печатать в прошлом варианте.
Сделали 2 шаблона и на всякий случай проверяем наличие ячеек - чтобы не плодить кучу условий на печати - если ячейка есть, то напечатается.
Это к вопросу о "зачем вообще проверять".

Т.е. вместо того, чтобы сделать банальное

if ( <= ...)
{
   val1 = ...;
   Range1.Value(val1);
}
else
{
   val2 = ...;
   Range2.Value(val2);
}

Вы сделали

val1 = ...;
Range1.Value(val1);
val2 = ...;
Range2.Value(val2);

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

if ( <= ...)
{
   this.Method1();
}
else
{
   this.Method2();
}

Если при модификации нового шаблона Вы вынуждены постоянно "оглядываться" на заполнение старого шаблона, то такую конструкцию слишком тяжело сопровождать.

[Alexanderis.ua]

Цитата:

Сообщение от Владимир Максимов

Но с увеличением количества версий Вы сильно задумаетесь хотя бы об отдельных методах для заполнения каждого шаблона. В перспективе - иерархии классов.

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

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

DIXI