Отчет состоит из 3х страниц. На каждой из них по несколько компонентов Rich Text. Все они не очень большие, за исключением одного. В этом одном компоненте Rich Text текст примерно на 4 страницы формата A4.
Переход на закладку "Код" в дизайнере в этом отчете занимает примерно 4-5 секунд. Работать с отчетом при таких задержках мягко говоря неудобно. Пробовал значения true/false для свойства "Full convert Expression" - особой разницы нет.
Насколько я понимаю, торможение возникает в момент генерации дизайнерского кода отчета, а она происходит каждый раз при переключении на закладку "Код". Все содержимое компонента Rich Text в формате rtf "переезжает" в код отчета в виде строкового литерала. Формат rtf дает увеличение размера литерала в несколько раз. Неудивительно что все это так тормозит.
Чтобы сделать работу в дизайнере более-менее приемлемой можно держать rtf-текст в отдельном doc-файле. Однако это как-то не очень удобно - каждый раз когда надо поправить шаблон, нужно копировать текст из всех больших rtf-полей в файл, а затем обратно.
Вопросы:
1. Может есть какой-то стандартный (или не очень стандартный) способ обхода этой проблемы ?
2. Стадии LoadFromString()+Compile() такого отчета (с большим Rich Text) на пользовательских компьютерах (как правило не ниже P4 с 2Gb RAM) занимают 15-20 секунд. Повторяю: - это только подготовка отчета, т.е. никакого запроса данных еще не происходит. Это только с одним "большим" RichText, где всего-то 4 страницы текста.
3. Не думаете ли Вы, что расположение дизайнерского кода вместе с пользовательским в одном файле не очень хорошая идея?
Есть же такая вещь как partial-классы. Куски кода можно было бы разделить и возможно удалось бы оптимизировать процедуру генерации дизайнерского кода. У меня в отчете 3 страницы, около 40 компонентов (20 бэндов, 8 из них Data, остальные просто Text) и даже при полном отсутствии RichText-компонентов переход на закладку "Код" происходит с задержкой примерно в 1 секунду (компьютер: Core2 Duo 6600, 2 GB, WD HDD в RAID 1).
ИМХО, пункты 2 и 3 наводят на мысль (меня по крайней мере), что с генерацией кода в дизайнере есть проблемы и есть что пооптимизировать.
Думал в версии 2008.2 будет проведена работа в этом направлении, а оказалось что все осталось по старому.
Будут ли изменения в будущей (ближайшей) версии в работе с кодом в свете вышеописанных проблем ?
Прокомментируйте, пожалуйста, пункты 1-3. Может я что-то не так делаю.
Медленная работа дизайнера, если в отчете есть большой Rich Text
Медленная работа дизайнера, если в отчете есть большой Rich Text
Здравствуйте,
Спасибо.
Пока нет.1. Может есть какой-то стандартный (или не очень стандартный) способ обхода этой проблемы ?
Да это так.2. Стадии LoadFromString()+Compile() такого отчета (с большим Rich Text) на пользовательских компьютерах (как правило не ниже P4 с 2Gb RAM) занимают 15-20 секунд. Повторяю: - это только подготовка отчета, т.е. никакого запроса данных еще не происходит. Это только с одним "большим" RichText, где всего-то 4 страницы текста.
До недавнего времени мы поддерживали обратную совместимость с .Net 1.1. И только с версии 2008.2 генератор отчетов доступен только для .Net 2 и выше.3. Не думаете ли Вы, что расположение дизайнерского кода вместе с пользовательским в одном файле не очень хорошая идея?
Есть же такая вещь как partial-классы. Куски кода можно было бы разделить и возможно удалось бы оптимизировать процедуру генерации дизайнерского кода.
Сам процесс по себе сложный. Вы можете посмотреть как происходит похожая операция в Visual Studio при сериализации формы в код.У меня в отчете 3 страницы, около 40 компонентов (20 бэндов, 8 из них Data, остальные просто Text) и даже при полном отсутствии RichText-компонентов переход на закладку "Код" происходит с задержкой примерно в 1 секунду (компьютер: Core2 Duo 6600, 2 GB, WD HDD в RAID 1).
ИМХО, пункты 2 и 3 наводят на мысль (меня по крайней мере), что с генерацией кода в дизайнере есть проблемы и есть что пооптимизировать.
По плану будет производится работы по улучшению в этом направлении в ноябре месяце. Движение будет в сторону использования ресурсов.Думал в версии 2008.2 будет проведена работа в этом направлении, а оказалось что все осталось по старому.
Будут ли изменения в будущей (ближайшей) версии в работе с кодом в свете вышеописанных проблем ?
Спасибо.