Передача параметров в форму

← →
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С. Там именно внутренний язык и есть то что вам нужно, и редактор отчетов именно такой- накидал компонентов и все. Но разработка чего-либо подобного я думаю займет довольно много времени...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У нас используется нужное тебе решение, правда в качестве генератора использован 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;
Есть конечно некоторое неудобство, что надо помнить все названия контролов и если их нехватает, создовать новые, что приведет к перекомпиляции программы. Но тут все зависит от предусмотрительности програмиста.

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