Скачать: CL | DM;

Передача параметров в форму   Найти похожие ветки 

← →
Andrey Kononov ©   (2005-06-03 14:04) [0]

Доброго времени суток, господа!

Хочу создать что-то вроде генератора отчетов совмещенного с диалоговыми формами. Цель - создать некоторый модуль, в который можно настраивать, добавлять, изменять отчеты, которые используются в другой программе. Причем при проведении операций с отчетами основная программа не должна перекомпилироваться.
Ну и еще одна цель - облегчить жизнь себе любимому, сняв с себя програмирование отчетов.  :)

Отчеты храняться в базе данных, но это не важно.

Написал модуль для вывода отчетов (использую FastReport 3). Теперь стоит вопрос о создании диалогового модуля, который будет инициализировать запрос к данным отчета, и присваивать значения переменным в шаблоне отчета.

Отрабатывал вариант, когда инициализация выборки данных и переменных велась через DLL. Все работает, но неудобно (каждому отчету - своя DLL, да и создать или исправить отчет без программиста не удастся).

Сейчас смотрю в сторону скриптовых настроек вызова отчета.

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

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

Буду очень признателен.

---

← →
Суслик ©   (2005-06-03 14:10) [1]

> Причем при проведении операций с отчетами основная программа
> не должна перекомпилироваться.

Я бы посоветовал использовать plugin на основе runtime пакетов.
Материалы по этому есть на сайте www.delphikingdom.ru. Поищи там по словам runtime package.

---

← →
Andrey Kononov ©   (2005-06-03 14:23) [2]

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

---

← →
Суслик ©   (2005-06-03 14:45) [3]

>  [2] Andrey Kononov ©   (03.06.05 14:23)

ты можешь сделать так:
1. есть одно целевое приложение, которое при хорошем исходном проектировании не нужно будет перекомпилить.
2. есть набор плугинов. Если что-то меняется в плугине, то только он и должен быть перекомпилирован. Но никак не основная программа, о чем ты вроде и спрашивал в исходном вопросе.

---

← →
Andrey Kononov ©   (2005-06-03 15:06) [4]

Сорри. Наверное я не совсем правильно высказал мысль.

Мне бы хотелось, чтобы у меня был набор типовых диалогов, например, выбрать дату, выбрать интервал дат и т.д. Пусть их будет много (хотя вряд ли много понадобиться), но я сделаю их один раз.

Затем есть отчеты, например "Отчет по реализации". Допустим, он бывает двух видов "По магазину 1" и "По магазину 2". Шаблоны абсолютно идентичные. Лучше всего сделать один шаблон и в заголовок положить переменную, которую я заполняю из программы.

Теперь мой желаемый алгоритм.

1.  Вызываю диалог с диапазоном дат.
2.  Выбираю две даты.
3.  Во внутреннем обработчике читаю эти даты
4.  Заполняю массив параметров для запроса
      QueryParam[1] := StartDate;
      QueryParam[2] := StopDate;
5.  Заполняю массив параметров переменных для шаблона
      TemplateParam[1] := "По магазину 1";
7.  Передаю полученные два массива генератору отчетов.
6.  В генераторе отчетов загружаю текст запроса из базы данных.
8.  Подставляю все параметры, которые переданы в массиве QueryParam
9.  Загружаю шаблон
10. Подставляю все параметры, которые переданы в массиве TemplateParam
11. Формирую отчет и показываю его

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

Как видно, за управление построением отчета отвечают 4 и 5. Именно они связывают неизменяемую основную программу и неизменяемый генератор отчетов и позволяют менять формы отчетов и данные получаемые в них.

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

Мой вопрос как раз и состоит. Как написать блок вывода диалога, получить из него данные, заполнить две структуры и передать их другому модулю? Стоит писать свой интерпретатор скриптов и разрабатывать свой скрипт-язык (имея при этом все прелести разработки языков программирования) или есть доступные готовые решения?

---

← →
Andrey Kononov ©   (2005-06-03 15:10) [5]

>  2. есть набор плугинов. Если что-то меняется в плугине, то только он и должен быть перекомпилирован. Но никак не основная программа, о чем ты вроде и спрашивал в исходном вопросе.


В данном случае предполагается для каждого отчета иметь свой плагин для получения данных?

---

← →
Andrey Kononov ©   (2005-06-06 10:00) [6]

Пожалуйста, посоветуйте кто-нибудь что-нибудь...

---

← →
dmitry501 ©   (2005-06-06 10:10) [7]

Andrey Kononov ©   (06.06.05 10:00) [6]
Использовать внешний генератор отчетов, например Crystal Reports, который сам полностью сформирует отчет. В программе определять список файлов с отчетами и выводить их в меню "Отчеты".

---

← →
Andrey Kononov ©   (2005-06-06 10:12) [8]

А как передать в Crystal Reports параметры, если я их заранее не знаю? Можно в Crystal Reports выводить перед построением отчета диалоги для заполнения параметров?

---

← →
dmitry501 ©   (2005-06-06 10:14) [9]

Andrey Kononov ©   (06.06.05 10:12) [8]
Можно.

---

← →
Andrey Kononov ©   (2005-06-06 10:27) [10]

Crystal Reports всем хорош, и стоимость у него хорошая. Может есть все-таки решение вопроса, который я задал? Я имею ввиду вопрос про скриптовую обработку.

---

← →
dmitry501 ©   (2005-06-06 10:35) [11]

Andrey Kononov ©   (06.06.05 10:27) [10]
Есть- можно посмотреть на 1С. Там именно внутренний язык и есть то что вам нужно, и редактор отчетов именно такой- накидал компонентов и все. Но разработка чего-либо подобного я думаю займет довольно много времени...

---

← →
evvcom ©   (2005-06-06 10:42) [12]

> Crystal Reports всем хорош, и стоимость у него хорошая.

Стоит хорошо среда разработки отчета, сам же движок (crpe или OLE-сервер) бесплатны. Причем через них же, по-моему, возможно создание файлов *.rpt, во всяком случае функций с названиями, говорящими об этом, предостаточно.

---

← →
Andrey Kononov ©   (2005-06-06 13:16) [13]

Я работал с Crystal Reports, правда со старой версией (не помню номер). Помниться имел массу проблем, глючил, весил много, у клиента надо отдельно ставить и т.д. Потом наткнулся на Fast Report, попробовал - все понравилось (глюки конечно есть, но мне они не мешают, да и думаю их исправят скоро, благо исходники есть). Поэтому передо мной не стоит проблема выбора генератора отчета. Передо мной стоит задача написать конфигуратор отчетов в большую систему, чтобы можно было дописывать отчеты, править их и т.д.

Пробовал много способов. В одних надо все равно иметь программиста, который будет заниматься не очень творческой работой, такой как написание DLL на формы ввода для каждого отчета (представляете сколько может быть путаницы потом в пачке DLL если ослабить контроль за их модернизациями). Да и удаленная поддержка проекта сильно усложняется. В других, например с использованием Crystal, все отчеты пишуться в другой системе. Для этого нужен спец по ней.

Больше мне по душе вариант, используемый, например, в 1С. Для отчета внутри программы строиться форма для ввода данных, строиться шаблон, строиться запрос на выборку данных (может на практике немного не так, но прошу извинить - я не специалист в 1С). Никаких сторонних средств нет. Отсюда - единый интерфейс, единая концепция программирования и т.д.

Сейчас у меня готов генератор отчетов. Все встраивается в основную программу, конфигурируется и т.д. Только отчеты я могу получить только те, в которых нет исходных параметров. Но такие отчеты мало кому нужны.

Дальше уперся необходимости форм для ввода параметров и передачи этих параметров генератору отчетов.

Даже не знаю как еще можно сформулировать свой вопрос...

Извините за длинные посты, просто хочу выразиться понятнее, чтобы не отнимать зря ваше время.

---

← →
Алексей Петухов   (2005-06-06 13:26) [14]

> Потом наткнулся на Fast Report, попробовал - все понравилось
>

Пользуй FastReport.
Он недорогой, лёгкий и функциональности Вам вполне хватит а нет - пользовательские функции ...

---

← →
Andrey Kononov ©   (2005-06-06 13:43) [15]

>Пользуй FastReport.
>Он недорогой, лёгкий и функциональности Вам вполне хватит а нет - пользовательские функции ...

Так им и пользуюсь. У меня же вопрос совсем про другое ...

---

← →
Erik1 ©   (2005-06-07 15:58) [16]

У нас используется нужное тебе решение, правда в качестве генератора использован QR, но это не существено.
 Для каждого отчета хранится:
ReportManager.AddReportGroup("EH", "Ehitus");

 ReportManager.AddReport("EH", "EH01", "EH01 - Majade aruanne",
   "KuupVahemik, Aadress1, Tanav, Aadress, Objekt, ObjAlaliik, Leping, ObjSeisund",
   TrEH1Majad, False);
Имена параметров в отчете и задаваемые переменые имеют одинаковые имена. Эти имена равны имени компонента + "fc". Так, что несостовляет труда найти и сделать:
S := Rep.VisibleControls;
while S <> "" do
begin
  SS := Trim(NextStr(S, ","));
  S := Trim(S);
  if SS = "" then
    Continue;
  if FindComponent("fc" + SS) = nil then
    Continue;
  Control := FindComponent("fc" + SS) as TFilterControl;
  Control.TabOrder := Order;
  Control.Visible := True;
  Control.Top := 1024;
  Control.Reset;
  Inc(Order);
end;
Думаю идея понятна, разумеется все контролы должны быть зарание созданы на диалоговой форме и Visable = False;
 Есть конечно некоторое неудобство, что надо помнить все названия контролов и если их нехватает, создовать новые, что приведет к перекомпиляции программы. Но тут все зависит от предусмотрительности програмиста.

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.51 MB
Время: 0.024 c