FONTAN: Delal jsem tiskovy vystupy radu let. WPF by bylo fajn, kdyby melo pripraveny nastroje pro tisk. Jenze ony pripraveny nejsou, takze takovy veci jako definovani velikosti okraju stranky, rozdelovani dokumentu na stranky, cislovani stranek (a vubec tisk paticek stranek vs. obsah stranek a jejich rozelovani), soucty hodnot za stranku atd.... to jsou funkcionality, ktery se daji naprogramovat ale stoji to hrozne moc prace.

A kdyz pouzijes nejaky pripraveny reportovaci nastroje, tak ty to maj zpravidla v sobe uz zabudovany a ty si vybiras jen jak to ma fungovat. Proste v narocnosti prace to je nebe a dudy.

Nevyhoda se muze zdat, ze ty kvalitnejsi nastroje jsou zpravidla placeny. Ale ve srovnani s mnozstvim casu, ktery stoji jejich naprogramovani, tak vychazi vyhodne pro tebe jako vyvojare ci jako sponzora/investora toho projektu.

TENCOKACISTROMY: (i) neco takoveho jsem potreboval slyset... (na cestu "primeho wpfka" me navedl jeden kolega z Anglie, kteremu jeden programator z Ukrajiny pise nejakou malou aplikaci a reporty tam resi pres "wpfko". jenze pak jsem zjistil, ze reporty kompletne malujou v kodu do flowdocument a zacal jsem se trochu strachovat, ze to mozna neni uplne idealni cesta....)

zkousim vyprodukovat nejaky "jednoduchy" system, jak ve wpf generovat na zaklade sablon "papirove" dopisy.

tj. idealni pripad by byl, ze bych mel obecne sablony pro "stranku" dopisu s (fixni) hlavickou, mistem pro adresu, hlavnim obsahem (v idealnim pripade uzivatelsky "formatovatelnym"), ktery by umel bindovat data a (fixni) patickou (i kdyz obcas by pata mela obsahovat (nejen) barcode)

zkousim
fixeddocument (inspirovan http://www.codeproject.com/KB/WPF/MailMergePrintWPF.aspx),
flowdocument,
kombinaci obeho, "ale vzdy se mi podari uspokojive jen "cast""
dalsi moznosti mam MS Reporting Service, Crystal Reports ci to rvat do Wordu (pri pouziti techle je jasny, ze wpf binding muzu zapomenout (coz bych mozna mel tak jako tak))

zkousim uplne nesmysly, nebo si proste mam pripustit, ze to nebude/neni tak jednoduchy?

RUTHAN: A komponentu hledas na ten levy panel a/nebo na tu plochu?

Ukladej si to do XML.

NECROMAN: Nuda? Vubec, jenom vomrd :D.

Ahoj,
snad jednoducha otazka, jaky komponenty ve Visual Studiu 2008, by bylo nejlepsi vyuzit tohle: Potreboval bych mit nejaky levy panel s kompomentama, a ty tahat na pravy panel ala platno, kde by komponenty budou rozmistovat a spojovat nejakyma primkama ci krivkama, abych tvoril
stromovou strukturu na platne. Hlavni obsah komponent by mela byt textova data, ktera budou pro kazdou komponentu dopredu definovana (jednotlive - povine a nepovine polozky).

Druha vec, kterou bych potreboval je nejaky vhodny zpusob, tak tady graficko textove informance ukladat do souboru a nacinat, pripadne exportovat do textovych dat, ktere bude nacitat jiny program.

ALCATOR: pouzivate aspon async a await rozsireni? Bez toho je to celkem nuda :)

ALCATOR: ani screenshoty nemozes? .)

ALCATOR: Proč ten (-1)? Naopak, gratulace! :)

Díky za odezvu :)

Zatim jen hypoteticky bych měl zájem o tvorbu aplikace pro jednoduchý náhledy na databázi. Konkrétně obdoba týhle aplikace na iOS: http://itunes.apple.com/us/app/deadline-mobile/id440242352?mt=8

Oni sice někdy v budoucnu tuhle aplikačku dělat chtěj, ale neni to teď priorita.

Funguje to tak, že se na serveru nahodí webová služba, která jednoduše vrací stringy na dotazy, který se pošlou na specifickej port.

Nic víc. :)

Dokázal byste někdo odhadnout čas a potažmo rozpočet na vývoj týhle aplikačky?

LOOCAS:
http://www.windowsphone.com/cs-CZ/search?q=martin+suchan

LOOCAS: jop, ale ne na market :)

LOOCAS: Ano

Vyvíjíte tu někdo aplikace pro Windows Phone?

ROTTWEILER: Ten datový tok je fakt malý, důležitější než bandwidth je latence. V principu ti stačí 1Mbit, ale jak je latence nad cca 100ms, tak to docela pocítíš.

ROTTWEILER: Nikdy jsem to nemeril. Si to vyzkousej.

ROTTWEILER: Zalezi jaky by byl setup systemu (verze) a jaka verze VSka.

Jinak da se toho spoustu vygooglovat ohledne tohoto.

TENCOKACISTROMY: Co se myslí silnou linku? 10 Mbit? 20 Mbit? víc?