Система бизнес-аналитики Stimulsoft | Форум

Здравствуйте,

Пожалуйста, используйте следующее свойство:
StiOptions.Viewer.Windows.ShowPageDesignButton

Спасибо.

Добрый день!

Да, так работает!
Как я понимаю, такая констукция с использованием статического поля "перекрывает" флаги в StiPreviewControl, что неочевидно. Получается, так стало с версии 2016.1.0.0, это не очень удобно, но раз работает, то так тоже устроит.

Однако, теперь возникла другая проблема, которой не было до 2016.1.0.0, а именно, все колонки, в частности (другие типы данных не проверял), DateTime теперь стали Nullable по-умолчанию, и соответственно, все наши отчёты (194 шт. с содержанием метода ToShortDateString()) выдают ошибку, т.к. мы используем такие конструкции:во всех отчётах.

Переделывать их на пока нет возможности. Получается, что вы полностью поменяли логику создания колонок таблиц поумолчанию. Что теперь с этим делать? Искать во всех отчётах по подстроку ".ToShortDateString()" и менять её на ".Value.ToShortDateString()"?

Возможно, есть есть какие-либо нюансы, однако, на данный момент мы остаёмся на 2015.2.0.0.

P.S. Проблема с Nullable колонками косвенно соотносится с топиком http://forumru.stimulsoft.com/viewtopic ... 801#p17801

Здравствуйте,

Мы меняли на правильное поведение. Но из-за возникающих проблем с уже созданными отчетами - данные изменения откатили.
Так же добавили опцию для использования:
StiOptions.Dictionary.UseNullableDateTime

Изменения будут доступны в сегодняшнем билде.

Спасибо.

Добрый день!

Мы меняли на правильное поведение.

Возможно, но только с точки зрения баз данных, т.к. например в C# DateTime != DateTime?, т.е. DateTime это не nullable DateTime и по умолчанию значение равно DateTime.MinValue (1/1/0001 12:00:00 AM).
В любом случае это слишком глобальное изменение, т.к. на протяжении последних 8 лет, что мы используем ваш продукт таких изменений не было, и логичнее было бы их применить, но как-то так, чтобы предыдущие изменения были deprecated, но работали.

Ещё, смотрите, какой момент. В наших отчётах, есть т.н. печатные формы, где connection и datasource мы создаём прямо в отчёте и "подтягиваем" колонки с помощью select'а (прописанного в source), и там, где надо указываем DateTime<Nullable>, но по умолчанию они не nullable. А есть обычные отчёты, которые мы по определённым причинам (огромное количество входящих значений + свой интерфейс выбора этих значений, т.к. StiForm недостаточно) выполняем из кода C#, передаём в отчёт уже готовый набор данных, т.е. в этом случае мы сами определяем набор колонок и их типы.
Это к тому что некое умолчание по сути есть только в случае автогенерации колонок, например, методом .Render() или .Show().

Ещё вопрос по флагу

StiOptions.Dictionary.UseNullableDateTime

. Получается, его нужно устанавливать вручную для каждого отчёта, где есть DateTime<Nullable>, но как это сделать, если у нас отчёты динамические, т.е. как определить когда его ставить, а когда нет? В моём понимании, придётся тогда в полученных выборках писать процедуру, котороая будет искать хотябы одно DateTime<Nullable> поле и устанавливать в этом случае флаг UseNullableDateTime в true, а если ни одного такого поля нет, то сбрасывать.

Здравствуйте,

К сожалению, нет простого решения для данной задачи.

Данная опция StiOptions.Dictionary.UseNullableDateTime статическая, включается сразу для всех отчетов.

Спасибо.

Добрый день!

Опишу здесь решение "полуавтоматического" перехода с версии 2015.2.0.0 на 2016.1.7.0.

Напомню, суть в том, что даты были обычные, стали Nullable. Да, в новой версии добавили флаг StiOptions.Dictionary.UseNullableDateTime, и выключив его можно было бы пока избежать всего нижеописанного. Однако, поразмыслив, мы пришли к выводу, что это неизбежно, т.к., в частности в Oracle всё равно используются DateTime<Nullable>.

Итак, суть метода. У нас есть база данных на Oracle. В таблице Reports хранятся все отчёты в виде Blob'ов, но это не меняет сути, если они у вас расположены в какой-нибудь директории (тогда надо просто делать рекурсивно):

1) Копируем все отчёты из рабочей базы данных из таблицы Reports в резервную базу данных в такую же таблицу;
2) Запускаем простую программу (см. вложение), которая делает следующее:
В цикле "пробегает" по всем blob'ам (отчётам .mrt по факту) и для каждого отчёта делает такие манипуляции:

На каждой страницы (StiPage) находим все компоненты типа StiText и StiBand и меняем в них текст ".ToShortDateString()" на ".Value.ToShortDateString()".

3) Сохраняем любым способом все blob'ы из таблицы Reports, чтобы поиском проверить содержат ли они строки .ToString("dd/MM/yy") и подобные, чтобы заменить их, соответственно на .Value.ToString("dd/MM/yy"). Но надо смотреть какие это поля, т.е. они должны быть DateTime<Nullable>;

4) Флаг StiOptions.Dictionary.UseNullableDateTime делаем равным True где-то в программе.

Собственно всё. Даллее, мы просто поменяли ссылки в проекте (References) на новые dll'ки, перекомпилировали проект, и заменили таблицу (уже изменённую) Reports в основной базе (скопировав из резервной, уже с изменениями).

Можно, сделать примерно так же, путём "прямого" парсинга .xml (mrt) файлов и поиска тех же строк, а так же замены строк, скажем, для изменения типа колонок с таких <value>ORD_DATE,System.DateTime</value> на <value>ORD_DATE,System.Nullable`1[System.DateTime]</value>. Однако, это менее "правильный" способ.

К тому же, я понимаю, что поля у вас могут быть не только или вообще не в StiText, а например, в колонках кросстаба или любых других компонентах.

То есть, как и говорил Алексей

нет простого решения для данной задачи.

Но суть именно такая.

P.S. Примитивный проект, что во вложении можно легко адаптировать к любому SQL провайдеру или написать рекурсивный поиск по директориям.

Зачем вообще всё это нужно? Очень просто, чтобы не править 196 отчётов вручную при переходе на новую версию отчётной системы.

Здравствуйте, Леонид

Большое спасибо за подробное описание решения проблемы с Nullable полями.

Дайте знать, если возникнут вопросы.
Спасибо.