пропозиції роботи
Temat: Kontrolki do tworzenia raportów
Witam WszystkichMam pytanie jakich kontrolek używacie do tworzenia raportów kompatybilnych z Delphi XE.
Za wszelkie sugestie będę bardzo wdzięczny.
Pozdrawiam
- 1
- 2
Mam pytanie jakich kontrolek używacie do tworzenia raportów kompatybilnych z Delphi XE.
Za wszelkie sugestie będę bardzo wdzięczny.
Pozdrawiam
Przemysław
Osmański
projektant / opiekun
produktu /
programista
Temat: Kontrolki do tworzenia raportów
A czy jest jakaś alternatywa dla Fast Reporta? To standard i nie ma co silić na inny wybór.
konto usunięte
Temat: Kontrolki do tworzenia raportów
Ja używałem FastReport w Delphi, poza Delphi Stimulsoft.. I przyznam ze chyba nic lepszego niż FastReport jeszcze nie spotkałem.
konto usunięte
Temat: Kontrolki do tworzenia raportów
Opcjonalnie można jeszcze napisać własne komponenty, jeśli Fast Report czegoś nie obsługuje ale do tych zastosowań, gdzie ten pakiet świetnie się sprawdza jest to zbędne.
Przemysław
Osmański
projektant / opiekun
produktu /
programista
Temat: Kontrolki do tworzenia raportów
Własne komponenty? To droga do nikąd. W żadnym rozsądnym czasie i koszcie nie uzyska się nawet podobnej funkcjonalności.Chyba że się chce taki komponent dystrybuować, bo można się zastanowic.
konto usunięte
Temat: Kontrolki do tworzenia raportów
A jeśli potrzebne są funkcjonalności, których nie ma Fast Report? Chodzi mi o nietypowe zastosowania. A może lepiej to zlecić? Bo outsorcing jest chyba tańszy. Nie mówię tu o konieczności pisania kodu od początku, bo czasem wystaczy wydziedziczyć komponent, dodając pewne funkcjonalności. A to jak wiadomo o wiele mniej pracy.Dariusz Rorat edytował(a) ten post dnia 13.10.12 o godzinie 19:01
Robert W. Programista
Temat: Kontrolki do tworzenia raportów
Osobiście uważam, że Fastom nie brakuje nic. Bardzo dobry pakiet - komunikacja w obie strony (raporty - aplikacja i aplikacja - raporty), własne okna dialogowe, przeróżne grupowania / zagnieżdżenia / interakcja z użytkownikiem / eksporty do różnych formatów itp itd. I intuicyjność na najwyższym poziomie. Cóż - tylko brać i używać :)
Daniel
Grabowski
Interaktywne
planowanie produkcji
on-line z MES
Temat: Kontrolki do tworzenia raportów
Przemysław Osmański:Chociażby Report Builder Pro, który funkcjonalnie może jest i ciut lepszy od FR'a.
A czy jest jakaś alternatywa dla Fast Reporta?
http://www.digital-metaphors.com/
To standard i nie ma co silić na inny wybór.Z tym standardem to lekka przesada, imo. Fakt, że został dołączony do ostatniej wersji Delphi w wersji okrojonej nie czynie z niego jeszcze standardu. Aczkolwiek jest na dobrej drodze.
Żeby nie było - sam używam FR'a (i to od bardzo dawna) i pewnie będę dalej, bo faktycznie posiada spore możliwości :)
Przemysław
Osmański
projektant / opiekun
produktu /
programista
Temat: Kontrolki do tworzenia raportów
A czy jest jakaś alternatywa dla Fast Reporta?Chociażby Report Builder Pro, który funkcjonalnie może jest i ciut lepszy od FR'a.
http://www.digital-metaphors.com/
Nie, RB nie uważam za alternatywę, a napewno nie za lepszy od FRa. RB używałem przez długi czas, ale jego podejście do tworzenia/wywoływania raportów jest ciut dziwne. Jak dla mnie za bardzo zintegrowane z VCLem. A nie tego oczekuję od silnika raportowania. Z tego powodu (i jeszcze kilku innych) też przeszedłem na FRa.
Daniel
Grabowski
Interaktywne
planowanie produkcji
on-line z MES
Temat: Kontrolki do tworzenia raportów
Przemysław Osmański:No chyba nie bardziej niż QR - to to był dopiero przyspawany. Raporty robiło się w miarę, ale w IDE.
A czy jest jakaś alternatywa dla Fast Reporta?Chociażby Report Builder Pro, który funkcjonalnie może jest i ciut lepszy od FR'a.
http://www.digital-metaphors.com/
Nie, RB nie uważam za alternatywę, a napewno nie za lepszy od FRa. RB używałem przez długi czas, ale jego podejście do tworzenia/wywoływania raportów jest ciut dziwne. Jak dla mnie za bardzo zintegrowane z VCLem.
Poza nim - prawie niemożliwe.
A nie tego oczekuję od silnika raportowania. Z tego powodu (i jeszcze kilku innych) też przeszedłem na FRa.Ano nie tego się oczekuje...
W sumie o czym tu dyskutować - FR wygrał w tym głosowaniu :)
Przemysław
Osmański
projektant / opiekun
produktu /
programista
Temat: Kontrolki do tworzenia raportów
No to RB robi może raporty w edytorze, ale koniec końców składują się one w DFMie formatki na której jest ten raport położony w formie komponentów(!). Każdy label itp jest osobnym komponentem w definicji formy powiązany jedynie z raportem.Oczywiscie jest możliwość ładowania raportów w run time i nie martwienia się o to co to tam w środku robi. Plus jest taki, że wszystkim co jest na raporcie można "sterować" jak zwykłą kontrolką VCLa.
Tomasz
Andrzejewski
PROGRAMMING ENGINEER
(DELPHI, SQL)
Temat: Kontrolki do tworzenia raportów
a koniecznie musza to byc kontrolki? Ja robie to w taki sposob:a) reporytorium raportow
b) komunikacja reportviewer > plik raportu > podglad na ekranie.
Korzystam z rozwiazan devexpress reporting w C#.
Mam exe jako designer raportow oraz dll w C# z viewerem a komunikuje sie z c# i delphi za pomoca interface.
Dll w C# jest natywna dll windowsa a nie c# assembly.
Daniel
Grabowski
Interaktywne
planowanie produkcji
on-line z MES
Temat: Kontrolki do tworzenia raportów
Tomasz Andrzejewski:Czyli de-facto korzystasz z "kontrolek"...
a koniecznie musza to byc kontrolki? Ja robie to w taki sposob:
a) reporytorium raportow
b) komunikacja reportviewer > plik raportu > podglad na ekranie.
Korzystam z rozwiazan devexpress reporting w C#.A to nie są kontrolki?
OK są to komponenty - ale w Delphi jest dokładnie tak samo, tyle że z innym produktem, bo DevExpress nie posiada w swojej ofercie raportowania (Express Printing System to nie jest biblioteka do zarządzania raportami sensu -stricte) dla Delphi.
Mam exe jako designer raportow oraz dll w C# z viewerem aA gdzie jest silnik obliczająco-renrderujący raporty?
komunikuje sie z c# i delphi za pomoca interface.No fajnie, ale po co tak kombinować?
Dll w C# jest natywna dll windowsa a nie c# assembly.
Dlaczego nie skorzystać z natywnego rozwiązania dla Delphi, np. FastReport.
Druga sprawa, że takie rozwiązanie jest ciekawe, ale ograniczone - nie da rady (a przynajmniej nie da rady tego zrobić w prosty sposób) współdzielić tych samych źródeł danych (w sensie TDataSet) pomiędzy aplikacją a silnikiem raportującym.
A to często jest po prostu wygodne i logiczne...
Tomasz
Andrzejewski
PROGRAMMING ENGINEER
(DELPHI, SQL)
Temat: Kontrolki do tworzenia raportów
Nie chodzilo mi o takie ujecie. W moim rozwiazaniu nie ma kontrolek w delphi - korzystam z osadzonego obiektu exportowanego przez dll (ustawiam parenta na np Panel w Delphi).Viewerem raportow jest dll c# z osadzonym obiektem do podgladu i wydruku z devexpress.
Osobna aplikacja jest designer takich raportow. Podobne rozwiazanie jest w przypadku ReportBuildera MSSQL'owego czy np CrystalReports. Definicja datasetu jest po stronie plikow z raportem.
W platformie aplikacyjnej ktora napisalem wspoldzielenie zrodla danych nie odbywa sie na poziomie obiektu a na poziomie definicji.
Wspoldzielenie zrodla na poziomie kompatybilnosci binarnej mozliwe jest do zrealizowania przed ADORecordSet. A to juz troche meczace zwlasza jak sie uzywa np UniDac.Tomasz Andrzejewski edytował(a) ten post dnia 15.03.13 o godzinie 17:02
Daniel
Grabowski
Interaktywne
planowanie produkcji
on-line z MES
Temat: Kontrolki do tworzenia raportów
Tomasz Andrzejewski:Dokładnie rozumiem o co Ci chodziło, wierz mi na słowo ;-)
Nie chodzilo mi o takie ujecie.
W moim rozwiazaniu nie ma kontrolek w delphi - korzystam z osadzonego obiektu exportowanego przez dll (ustawiam parenta na np Panel w Delphi).Nic nie pisałem o kontrolkach Delphi.
Viewerem raportow jest dll c# z osadzonym obiektem do podgladu i wydruku z devexpress.Rozumiem jak to działa.
Osobna aplikacja jest designer takich raportow. Podobne rozwiazanie jest w przypadku ReportBuildera MSSQL'owego czy np CrystalReports. Definicja datasetu jest po stronie plikow z raportem.
Tylko nie rozumiem dlaczego to tak zrobiłeś?
Dlaczego używasz komponentu (biblioteki, kontrolki, whatever) raportującej, która nie wspiera Delphi w aplikacji napisanej w Delphi?
W platformie aplikacyjnej ktora napisalem wspoldzielenie zrodla danych nie odbywa sie na poziomie obiektu a na poziomie definicji.To też rozumiem i właśnie o tym pisałem - czasami przydaje się tez współdzielenie nie tylko definicji,a le danych - wprost.
Wspoldzielenie zrodla na poziomie kompatybilnosci binarnej mozliwe jest do zrealizowania przed ADORecordSet. A to juz troche meczace zwlasza jak sie uzywa np UniDac.No więc właśnie, pewnie są też i inne problemy - a więc dlaczego tak, wybacz moją ciekawość :)
Tomasz
Andrzejewski
PROGRAMMING ENGINEER
(DELPHI, SQL)
Temat: Kontrolki do tworzenia raportów
Platforma ktora napisalem integruje wiele rozwiazan i jezykow programowania.Delphi to tylko host. System jest oparty o komunikacje plugin'owa. Plugin moze byc napisany w dowolnym jezyku generujacym natywnego dll (nawet w C#).
Plugin raportujacy jest napisany w C# jako dll wlasnie ze wzgledu na kompatybilnosc.
Dowolny plugin moze zaladowac plugin viewera a rozwiazanie zapewnia elastycznosc niezaleznie od jezyka porgramowania jakiego uzywasz.
Daniel
Grabowski
Interaktywne
planowanie produkcji
on-line z MES
Temat: Kontrolki do tworzenia raportów
Tomasz Andrzejewski:OK.
Platforma ktora napisalem integruje wiele rozwiazan i jezykow programowania.
Delphi to tylko host. System jest oparty o komunikacje plugin'owa. Plugin moze byc napisany w dowolnym jezyku generujacym natywnego dll (nawet w C#).
Kiedyś rozważałem takie podejście (interoperacyjność na poziomie różnych języków), ale odpadło w przedbiegach.
I tak nikt nigdy (u mnie) nie napisał żadnego pluginu w innym języku, a więc po co...
Ale co ważniejsze, dla mnie, takie rozwiązanie jest zbyt nisko poziomowe i sprowadza pluginy do roli specjalizowanych usług.
Co dla mnie było nie d przyjęcia.
Ja chcę pracować na wysokim poziomie abstrakcji przesyłając obiekty biznesowe pomiędzy pluginami albo - pracując na tej samej instancji obiektu w różnych pluginach.
Dla mnie jest to ważniejsze, niż obsługa wielu języków programowania.
Co zresztą jedno nie wyklucza drugiego - ale u mnie plugin napisany np. w C++ nie da rady obsłużyć zdarzeń aplikacji (np. u mnie to tak wygląda Host.AppEvents.OnFormOpen).
Co ciekawe, istnieje takie rozwiązanie komercyjne (implementacja hosta i pluginów w rożnych językach, można integrować na naprawdę wysokim poziomie abstrakcji) i wygląda naprawdę ciekawie:
http://www.remobjects.com/hydra/
Ale tak jakoś, to tez nie to co chciałem uzyskać i w końcu nie używam :)
Plugin raportujacy jest napisany w C# jako dll wlasnie ze wzgledu na kompatybilnosc.Ale są problemy z przesyłaniem danych pomiędzy pluginem a raportem.
Dowolny plugin moze zaladowac plugin viewera a rozwiazanie
A jak z obsługą zdarzeń, pomiędzy raportem a pluginem?
Chociaż, jeśli plugin dostaje Intf do viewera, to nie powinno być problemów.
zapewnia elastycznosc niezaleznie od jezyka porgramowania jakiego uzywasz.Elastyczność jest wartością nie do przeceniania, ale nie taka - moim zdaniem :)
A elastyczność wg mnie, to np. wpływ na kształt i zachowanie aplikacji bez programowania i kompilowania w jakimkolwiek języku.
Aplikacja sterowana danymi, którą łatwo dostosować i zmodyfikować; mam tu na myśli np. automatyczne generowanie UI na podstawie danych i konfiguracji (nazwałeś to "definicją danych" - i to bardzo trafne określenie), globalne zarządzanie konfiguracją i zmiana UI i zachowania aplikacji w miejscu u klienta, włączając w to tworzenie nowych formatek, raportów i zestawień.
I coś takiego jest dla mnie najważniejsze.
Proszę wybaczyć przynudzanie, ale tak mnie jakoś poniosło...
Tomasz
Andrzejewski
PROGRAMMING ENGINEER
(DELPHI, SQL)
Temat: Kontrolki do tworzenia raportów
W rozwiazaniu o ktorym pisalem integracja jest na poziomie obiektu. Zarowno plugin jak i host maja referencje do obiektu interface'owego (plugin widzi hosta, host plugina).W taki sposob min. zrealizowany jest bypas do obslugi zdarzen onKey... (VK_LEFT, VK_RIGHT, VK_TAB. etc).
Wyglad aplikacji (definicje list, layoutu formularzy) jest sterowany przez interface z poziomu hosta.
Layouty zapisane sa w bazie (podobnie jak definicje menu, akcji, zrodla danych dla list, raportow, prawa etc.).
W praktyce wyglada to calkiem niezle i pozwala na integracje funkcjonalnosci niedostepnych z poziomu VCL (np dashboard devexpress ktore nie sa dostepne dla VCL, podobnie XtraReports).
Podstawa w moim przypadku do takiego podejscia jest fakt ze interface jest kompatybilne na poziomie binarnym w kazdym jezyku.
Minusem jest to co zauwazyles przy zmianie (dodawaniu) dodatkowej funkcjonalnosci wymagana jest rekompilacja pluginow. Ciagle mysle o zdalnej kompilacji zrodel (zaciaganie repozytorium dla konkretnego builda i kompilacja centralna - wymaga to jednak duzego rezimu wersjonowania i wspolnego konczenia wersji przez wszystkich programistow).
Temat zaczal sie tak niewinnie :) a wywiazala sie dyskusja o systemach pluginowych :)
Daniel
Grabowski
Interaktywne
planowanie produkcji
on-line z MES
Temat: Kontrolki do tworzenia raportów
Tomasz Andrzejewski:Oook, ale w jaki sposób Host widzi plugina?
W rozwiazaniu o ktorym pisalem integracja jest na poziomie obiektu. Zarowno plugin jak i host maja referencje do obiektu interface'owego (plugin widzi hosta, host plugina).
Jeśli przez interfejs, to musiałbym znać definicję interfejsu.
Nie jest to złe rozwiązanie, ale ma swoje wady...
Sam stosuję identyczne, ale tylko dla pluginów frameworka.
Natomiast wszystkie pluginy biznesowe (jak je nazywam; są to pluginy, które nie wnoszą nic do frameworka za to zawierają całą logikę biznesową, a więc formularze, raporty i logikę sensu stricte) nie są widoczne przez Host w skonkretyzowany sposób.
A więc Host nic nie wie o pluginie np. IInvoice (z pełnym dostępem do deklaracji typu, itd.), ale za to wie wszystko o pluginie 'IInvocie' - zapis jako string jest specjalnie :)
Z tym, że każdy plugin implementuje interfejs komunikacyjny pomiędzy hostem a pluginem i nie więcej.
Druga sprawa to architektura rozwiązania - ja szeroko stosuję IoC (inversion of control), a więc poszczególne pluginy podpinają się ze swoją funkcjonalnością od dołu, w ten sposób, że plugin do którego się podpinają nic o tym nie musi wiedzieć.
Natomiast samo wstrzyknięcie konkretnej funkcjonalności do konkretnego pluginu jest zgodne z paradygmatem DI (dependency injection) z tym że, korzystam z lokalnego kontenera DI na poziomie pluginu.
W taki sposob min. zrealizowany jest bypas do obslugi zdarzen onKey... (VK_LEFT, VK_RIGHT, VK_TAB. etc).Co to znaczy "jest sterowany"?
Wyglad aplikacji (definicje list, layoutu formularzy) jest sterowany przez interface z poziomu hosta.
A jak się tym zarządza i tworzy nową konfigurację?
Layouty zapisane sa w bazie (podobnie jak definicje menu, akcji, zrodla danych dla list, raportow, prawa etc.).Mam tak samo :)
W praktyce wyglada to calkiem niezle i pozwala na integracje funkcjonalnosci niedostepnych z poziomu VCL (np dashboard devexpress ktore nie sa dostepne dla VCL, podobnie XtraReports).Dashboard to jest faktycznie problem w VCL; chociaż może i niekoniecznie; po prostu wykorzystałbym do tego JS'a z publikacją danych za pomocą JSON'a - dziś to już trywialne :)
Natomiast co do raportów, to dalej mnie nei przekonuje korzystanie z XtraReports zamiast z FastReports :)
Podstawa w moim przypadku do takiego podejscia jest fakt ze interface jest kompatybilne na poziomie binarnym w kazdym jezyku.Czyli, odpowiedziałeś na moje pierwsze pytanie.
Minusem jest to co zauwazyles przy zmianie (dodawaniu) dodatkowej funkcjonalnosci wymagana jest rekompilacja pluginow.
Definicja pluginów jest stała i zmiana wymaga rekompliacji całego systemu.
Ja podszedłem w ciut inną stronę, ale tylko dlatego, ze miałem to zrealizowane podobnie jak Ty, ale nie podobał mi się ten pomysł. Był uciążliwy przy dużym systemie ze sporą dynamiką zmian dla różnych klientów.
Sam framework i Host to zestaw usług dostępnych dla każdego plugina - przez interfejsy.
Natomiast wszystkie pluginy to są biblioteki, które są ładowane do konkretnej konfiguracji aplikacji.
Sama aplikacja zaś, to konfiguracja i zestaw konkretnych pluginów.
Nie wszystkie funkcjonalności wymagają jakiegokolwiek pluginu - są całkowicie i często automatycznie generowane przez framework na podstawie metadanych. Takie funkcjonalności to formularze DataEntry, raporty i zestawienia (np. formularz z PivotTable i wykresami).
Innymi słowy - zwykłą aplikację bazodanową typu DataEntry generuję automatem na podstawie konfiguracji metadanych.
Nie ma tam ani jednej lini kodu, nie ma ani jednego pliku PAS/DFM nie ma ani jednego raportu.
Aplikacja pozwala na rejestrowanie danych, przeglądanie, analizowanie itd.
Całą logikę niestandardową trzeba (niestety) zaprogramować i podłączyć do konkretnego pluginu ;-)
Tak to wygląda (mniej więcej, trochę stare te screeny, ale nie będą).
Edytor metadanych
Formularz wygenerowany całkowicie automatycznie
Edycja w runtime formularza wygenerowanego autmatycznie
Itd.
Jest tego sporo, ale zapewniam że funkcjonalnie nie ma się do czego (za bardzo :D) przeczepić :)
Ciagle mysle o zdalnej kompilacji zrodel (zaciaganie repozytorium dla konkretnego builda i kompilacja centralna - wymaga to jednak duzego rezimu wersjonowania i wspolnego konczenia wersji przez wszystkich programistow).Eee... zabrzmiało jak byś nie czytał Fowlera i gdzieś pominął termin "ciągła integracja" ;-)
Jak Ci się nie chce walczyć z rozwiązaniami nie całkiem dedykowanymi do Delphi, to zawsze możesz zakupić to:
http://www.finalbuilder.com/finalbuilder-server.aspx
Temat zaczal sie tak niewinnie :) a wywiazala sie dyskusja o systemach pluginowych :)Gdybyś uczestniczył w dyskusjach na pl.comp.lang-delphi (znany jako wloochacz) to widziałbyś, ze ze mną tak zawsze ;-)
o proszę, jedna z wielu:
https://groups.google.com/forum/#!topic/pl.comp.lang.de...
Tomasz
Andrzejewski
PROGRAMMING ENGINEER
(DELPHI, SQL)
Temat: Kontrolki do tworzenia raportów
Widze ze mamy bardzo podobne rozwiazania i uzyte kontrolki :)U mnie logika biznesowa jest tylko w formularzach edycyjneych. Zestawienia i listy wymagaja napisania definicji sql (wiaze sie to z procesowaniem np statusu rekordu - inne akcje np dla faktury zaksiegowanej inne dla niezaksiegowanej).
Komunikacja miedzy plugin - host i w druga strone odbywa sie przez exporty z pluginu.
Plugin tworzy obiekt np TForm przez export np function CreateBox(var ABoxIndex: Integer): IUnknown;
Plugin ma definicje (tablice) wszystkich utworzonych obiektow. Przy komunikacji sprawdzam tylko czy jest zaimplementowana konkretna wersja interface. Plugin implementuje zawsze wersje nazwijmy ja IBase + jej ewentualne rozszerzenia (IBase ma funkcje Version(): Integer).
Ja siedze na innym forum :) w naogol teraz przewaznie w MSSQLTomasz Andrzejewski edytował(a) ten post dnia 19.03.13 o godzinie 20:28
- 1
- 2
Podobne tematy
Następna dyskusja:
