Сохранение отчета в PDF формате

[Игорь Столяров]

Кстати, поздравляю с переходом на 64 разрядную ОС

Спасибо. Тут как говорится:

[Губин Игорь]

Да проверил на нескольких разных компьютерах - везде одно и тоже ...

Похоже, что у вас очень шустрые пользователи или очень большие отчёты. У меня в программе сразу после генерации стоит открытие по shellexecute и никаких проблем не обнаружено.

[Игорь Столяров]

Сам удивлён. Поменялась только Windows 10 c x32 на x64, компьютер тот же (ну добавил SSD SAMSUNG), БД та же.
Поэтому зафиксировал здесь наличие непонятной (возможно локальной) проблемы и её решение.

[Губин Игорь]

Поэтому зафиксировал здесь наличие непонятной (возможно локальной) проблемы и её решение.

[kreator]

Видал это, костыли для обхода очередной проблемы в рантайме с11. В с6 все норм.

Похоже этим костылям понадобились свои костыли.
Ну не знаю. Мы используем remove() много где, никогда на баги не натыкались.

[Игорь Столяров]

Мы используем remove() много где, никогда на баги не натыкались

А багов и нет. Вопрос в скорости выпонения. Карл как раз на примере показал, что REMOVE() сильно тупит.
И если в "обычных" удалениях нескольких файлов это незаметно, то при закрытии отчёта с несколькими
сотнями страниц - выполняется массированое удаление сотен файлов с WMF страницами.
И возникает подвис на ощутимые секунды (по крайне мере я это прекрасно видел на традиционном HDD).

Возможно, современный комп у разработчика с SSD M2 позволяет не заморачиваться с такими "мелочами".
Но не все благостно делают программы для себя или для работы на современном дорогом оборудовании.

[finsoftrz]

Про баги Карл написал в начале своего эссе.

[Игорь Столяров]

REMOVE() in RTL has bugs and is very slow using ShFileOperation().

Про баги Карл упомянул, но не назвал их и не продемонстрировал.
И что есть "баг" ? Некоректная рализация REMOVE() в RTL C11, приводящая к замедлению удаления файлов ?

А вот проблема со скоростью удаления файлов REMOVE() была показана и решена.
Ошибок при работе REMOVE() я не видел (в отличии например от RUN()).

[finsoftrz]

Решена подстановкой очередного костыля в виде win api, вместо исправления проблемы в rtl по платной подписке.
Карл вроде бывший сотрудник SV. Сейчас несколько таких переместились на хаб и пытаются хоть как-то поддерживать продукт, не имея возможности напрямую участвовать в его разработке. Может, это хитрый план такой у RZ?

[Дед Пахом]

Карл вроде бывший сотрудник SV.

Уникальный персонаж, его спросишь "который час", а он в ответ 8 скриншотов, 3 графика и ссылку на свой гитхаб.

[Игорь Столяров]

Карл - энтузиаcт Clarion ! Старается помогать всем и при этом абсолютно бескорыстно.

[gopstop2007]

Код: Выделить всё

  !If Exists(wFile_) then Loc:OKSave = True.
  
   If Exists(wFile_) then Loc:OKSave = True
   else
      Loop 10 times
         ==================================
         Yield; Yield; Yield; Yield; Yield;
         ================================
         Win::Sleep(500)  ! Ждёмс 0.5 сек.
         If Exists(wFile_) then Loc:OKSave = True; Break.
      end
   end

А чем оправдана такое количество Yield?

[Игорь Столяров]

А чем оправдана такое количество Yield?

Эмпиристическим предположением, что Windows требуются ресурсы для записи PDF файла (завершения печати).
В принципе, и без Yield работает, здесь главное сделать паузу.

[kreator]

А багов и нет. Вопрос в скорости выпонения. Карл как раз на примере показал, что REMOVE() сильно тупит.
И если в "обычных" удалениях нескольких файлов это незаметно, то при закрытии отчёта с несколькими
сотнями страниц - выполняется массированое удаление сотен файлов с WMF страницами.

Нескольких сотен страниц у нас нет. Максимум пару сотен. Но всё равно не замечали проблем. А где Карл показал проблему? Текст по ссылке посмотрел, вроде ничего такого нет. Есть 50 временных файлов. На них (пятидесяти) тоже проблемы? Не то, чтобы я не верю, просто не замечал.

[Игорь Столяров]

Не то, чтобы я не верю, просто не замечал.

Так и не надо верить на слово. Лучше собрать предлагаемый Карлом тест и посмотреть.