Egyszerű de használható reporting tool .NET alá.

Ezért kellett volna az M$-nek egy ésszel megtervezett felületet csinálni rá. Ez az egész kézzel írjuk az xml fájlokat játék engem arra emlékeztet mint ha az emberek kézzel csinálnák a postscript fájlokat és nem CorelDraw vagy más rajzolóprogi segítségével. A kézzel írt postscript persze sokkal hatékonyabb (mivel maga is egy programnyelv) és többféle lehetőséget is biztosít mint a CorelDraw, valamiért ennek ellenére mégsem jellemző hogy a népek kézzel csesztetnék a ps fájlokat. Sőt, a CorelDraw-nak sincs külön postscript nézete a grafikus felület mellé. Persze nyilván a Corelesek a hülyék és a kézzel gányoljuk a UI definíciós fájlokat a jövő útja...

Vagy a másik lehetőség hogy ez az ökörség a html-php-gagyi világból keveredett át és a M$ szépen megy a többi birka után. Ráadásul ez még kényelmes is: nem kell mindenféle intuitív, könnyen használható user interfészt kitalálni a designerhez (sőt, még normális designert sem kell csinálni) a sok coder majd beírja kézzel az xml-t.

Azért valahol sajnálom hogy a Borlandból az lett ami. Amíg a Delphi komoly fenyegetést jelentett a .NET-nek addig szvsz a M$ nemigen engedett volna meg magának pár olyan dolgot mint Pl. a VS2k8-ban lévő WPF designer volt az SP1 előtt (sőt talán olyat sem mint az SP1 után). A .NET 2 és a VS2k5 nagyon ott volt a szeren a maga idejében. A 3.x és a VS2k8 esetén viszont folyamatos félkész állapotot érzek, akár a WPF designert nézem, akár a Linq to SQL-t, akár bármit.

Mélységesen egyet értek! Félóránként kell újraindítani a VS-t meló közben, emiatt aztán már nálam is kiborult a bili.

Itt meg itt. Ez a cuccot így, ebben a formában nem kellett volna RTM-ként ide adni.

Egyébként, ha lesz Report WPF-hez, akkor ott is jobban jársz, ha megírod az XAML-t. A Blendben a végletekig ki van dolgozva a klikkenplély adatkötés, de annyi az opció, az adatforrás annyi helyről és formában származhat, hogy egy sima kötés összekattintása még a leggyakorlottabb kéznek is 10x annyi időbe telik, mint oda írni hozzá kb 20 kerakter XAML-t. Normális XAML IntelliSense kéne inkább a VS-be, nem ez a hoki és körülményes klikkenplély.

Egyszer valami mindig lesz. A M$ bőszen dolgozik a 100 generációval későbbi dolgokon, közben a reporting services olyan amilyen, a WPF-ben nincs datagridview és az xml-ben kell kézzel turkálni ha databindinget akarsz, mint egy vacak java "RAD" rendszerben. A Visual Studio bugjairól (SP ide vagy oda) nem is szólva. Klassz lenne ha egyszer a jövő helyett picit a jelennel is foglalkoznának.

WPF-hez lesz XPS alapú report elvileg, legalábbis Summit-on azt mondták. Majd. Egyszer. Valamikor. A szokásos.

A szívás akkor van ha 800$ és még bugos is .

Mibe került volna a M$-nak normálisan megcsinálni a reporting servicest ?

Közben megnéztem két openszorszos cuccot, (Rdl Project és MyNeoReport), az előbbiből még lehet valami, az utóbbi elég harmatos. És megnéztem a FastReportot is, az viszont elég jónak tűnik.

Szerintem relatív, hogy sok vagy kevés.
Ha jobban belegondolunk, akkor max 2 heti, azaz 80 munkaóra ára (és szerintem most olcsóra vettem magunkat).
Ennyit simán lehet szopni egy bugos rs-el.

Közben én is rájöttem, hogy nyóccáz dolcsi azért nem kis píz.

Ennél azért kevésbé húzós árú cuccra gondoltam.

Nekem adtak egy licence-t ehhez, hogy elemezzem és mondjak valami véleményt róla: ComponentOne Reports. Van WinForms + WPF verzió is, és a kettő formátuma is ugyan az. Még élesben nem vetettem be, csak játszottam vele WPF alatt, de ez alapján elég jónak tűnik. Hamarosan elérkezik a reportolás része egy projektünknek, és akkor majd beszámolok róla a blogomon. Nyóccáz dolcsi amúgy ...

Ráadásul az egész elég lassú. Lemegy a nap mire egy nyomtatás elindul Pl. számla kiadásakor.

És még mindig nem oldották meg, hogy az oldalfejlécben is lehessen databindingolni.

Ha már a bug-oknál tartunk..
A direkt nyomi példány és egy pdf-ből készült példány margó méretei is eltérnek, amit az Ms is elismer.

>Bocsi, de minek az új név?
Mert nem tudom fejből az LC jelszavát. Nem az otthoni gép előtt ülök.

>Ez nem okoz gondot, annál inkább a Fejrész konstans mérete.
Ez mondjuk az egyik gáz. De nagyobb az hogy néha a számlán 2 oldalt nyom holott simán elférne egy lapon is. Aztán bugzik a print preview, normál nyomtatásnál jó, preview-nél az alapértelmezett nagyítással nem. Stb... Valamennyire sikerült kiismernem a dolgait, de van pár gondja amivel nem tudok mihez kezdeni. A fastreport elég jónak tűnik /és a delphis verzió elég elterjedt idehaza is/, de ahogy nézem most jött a .NET-es verzió, így sok tapasztalata senkinek nemigen lehet.

Bocsi, de minek az új név?
No mindegy.
Én is keresgéltem és végül, ha ló nincs.. maradtam a reporting services-nél.
.rdl-t tervezek, .rdlc-t futtatok, bizonyos megalkuvással.

Ez nem okoz gondot, annál inkább a Fejrész konstans mérete.
Egyszerűen átíródik a törzs területére a fejrész utsi sora, ha épp úgy sikerül.

Nekem a papné, én elég rég játszom a reporting servicessel (LC néven futok amikor épp nem itt vagyok bejelentkezve).

Kinek a pap, kinek a papné!

Sziasztok!

Azt szeretném megkérdezni kinek milyen tapasztalata van a fenti témakörben. Kellene valamilyen reporting tool amivel meg lehet csinálni szépre Pl. számlát, egyéb egyszerű jelentéseket és teljesíti a következő feltételeket:

- Print preview
- Run-time report testreszabhatóság
- Export xls-be
- Nem túl drága
- Esetleg forráskód is elérhető
- Normális designere van
- Nem kerül nehéz helyzetbe akkor sem ha Pl. egy mezőnek növekednie kell lefelé mert nem egy hanem két sorban fér csak el a tartalom.
- Nem kell mellé terrabyte-os méretű run-time, szerver, stb. illetve a run-time után ne kelljen fizetni.

Eddig a reporting servicessel próbálkoztam de voltak vele gondjaim (Pl. több lapra nyomtatott olyasmit is ami ráfért volna egy lapra is, stb).

A gugli alapján a fastreport .NET-es verziója tűnik szimpatikusnak, de ha van valakinek gyakorlati tapasztalata vele vagy más hasonló programmal, azt örömmel fogadnám.