Diskuze: Program nepracuje správně pro více souborů
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Zobrazeno 27 zpráv z 27.
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Ahoj,
nebylo by lepší data ukládat do jednoho souboru? Za použití nějakého
separátoru oddělovat jednotlivé nastavení. Třeba | (v názvu souboru být
obsažen nemůže).
Takže něco jako
C:\Users\David\Documents\Dropbox\Public\IMAG0159.jpg|261|178
položka = řádek.Split('|');
položka[0]//cesta
položka[1]//x
položka[2]//yPak se bude nastavení načítat jedním cyklem a ukládat taky. A nestane se ti, že by došlo k zápisu a vznikl problém kvůli nesesynchronizovaným souborům.
Znak "|" v názvu souboru být může. Vlastně se nedá spolehnout na žádný nepoužitelný znak.
Vhodným formátem by mohl být JSON (snad ho C# umí) nebo ukládání do databáze (to snad umí také).
XML je skvělý formát pro výměnu dat mezi procesy, které se vzájemně moc neznají. Pro ukládání vlastních pracovních dokumentů zas tak výhodný není.
Mě přijde XML formát naprosto univerzální a použitelný k čemukoli. Jediná nevýhoda je, že zabírá více místa kvůli tagům, ale to se projeví jen při větším množství dat. Bývá hojně používán např. na konfigurační soubory atd.
XML je univerzální formát, o tom není sporu. Zkus si však do něj uložit kousek binárních dat. Jde to, ale moc přehledné to není.
XML není serializační formát. Hodí se na zápis konfigurace, ale na její průběžnou aktualizaci už moc ne.
V XML se programuje například XSLT. To je také skvělý jazyk, který je vynikající na tvorbu výstupních šablon HTML. Přesto spousta vývojářů používá mnohem horší Smarty. Proč? Smarty vypadá jednodušeji.
Kromě syntaxe nevidím mezi JSON a XML rozdíl. Navíc XML má skvělou možnost validace přes XSD schémata, editovat jde přes DOM velmi dobře a dokonce nad tím můžu volat i SQL dotazy.
V jednom souboru je možné mít více dokumentů za sebou, ale XML to neumožňuje. Proto je možné do JSONu logovat, ale do XML to nejde. Možná ti to přijde jako banalita, ale využívám to docela často.
Validace přes DTD či XSD je nutná, pokud data pochází z různých zdrojů. Pokud spolu komunikují 2 komponenty jedné aplikace, je zpravidla zbytečná.
Zřejmě máš na mysli Xpath. Skvělá věc. Použil jsem to i na databázi sídel v ČR, abych si otestoval výkonnost. Pokud ta databáze není příliš velká, je to rychlejší než klasické databáze.
Editování XML přes DOM je asi nejvýkonnější editování vůbec. Slabinou je náročné parsování vstupního textového souboru a generování výstupního souboru s ošetřením na úplnost. Samotný DOM je velmi rychlý.
JSON je v tomto ohledu zjednodušený a pro spoustu aplikací vyhovující. Není tak dokonalý, ale je rychlejší.
V XML mohu mít určitě více dokumentů najednou, nevím, jeslti to formát JSON podporuje nějak nativně, ale v XML si je prostě obalím dalším elementem.
Ano, myslel jsem Xpath nebo LINQtoXML.
JSON je jednodušší, mnohdy efektivnější, navržený hlavně na serializaci objektů (již z názvu). IMHO je to zjednodušené XML a i bývá s XML čato srovnáván. Na druhou stranu XML je standardnější formát a troufám si říci, že toho umí více a existuje pro něj více nástrojů a nástaveb. Já mám XML raději, ale to je asi věc vkusu, jsou to rovnocenné formáty.
A jak přidáš další dokument do kolekce v XML? Musíš tu kolekci načíst, doplnit dokument a uložit. V JSONu jen připíšeš na konec, což se dá udělat jako atomická operace.
Ty formáty nejsou úplně rovnocenné, každý se hodí trochu na něco jiného. Nechci, aby to ode mne vyznělo tak, že JSON je lepší, než XML. Ceníky se lépe distribuují v XML, AJAXu zase lépe sluší JSON.
Někdy by to mohlo vadit, ale záleží na případě užití. Když s itemy pracuješ v paměti programu a pak po dokončení změny najednou uložíš, je to jedno. Když budeš potřebovat průběžně ukládat po jednom, tak to vadit bude, to je fakt.
Samozřejmě. Pokud budeš chtít strukturovaně logovat, tak načítání, modifikace a ukládání nepřichází v úvahu. Potřebuješ atomický zápis na konec.
Pokud však edituješ projekt, který je ve více záložkách a chceš ho ukládat do jednoho souboru, je to jedno. V tuto chvíli se projeví výhody XML před JSON. Proto OOo i MSO ukládají do XML. JSON by se sice také dal použít, ale utrpěla by přenositelnost.
Teď mě napadlo: Kdyby se každá změna průběžně ukládala na konec editovaného souboru jako žurnál, nebylo by nutné např. ve Wordu ukládat každých 10 minut celou rozdělanou práci. Některé editory to tak dělají.
Použil jsem čekání a tím jsem téměř všechny chyby eliminoval. A už vím kde přesně program selhává - při přeseunu Formu2 se zapíší změny - stačí přesouvat Formy2 trochu rychleji - více formů se dostane do fronty a dojde k chybě zápisu. Čekání zde nemohu udělat - frontu ještě zvětším - tak co s tím? Děkuji.
Tak tohle jsem nepochopil. Jak může mít rychlost programu vliv na funkci zápisu? Dosud jdi nanapsal, jakou chybu to vypisuje.
Žádnou - to není chyba v syntaxy,... Pokud se do fronty o zápis cpe více zápisů, tak dochází k chybám - tedy alespoň mě to zpomalení výrazně pomohlo - jak píšu jediný problěm je, že mezi různými formy to již použít nemohu.
Nemyslím syntaktickou, ale běhovou chybu. Pokud program něco nezapíše, vyhodí výjimku, ne? Pokud ji spolkneš, tak se nic nedozvíš.
Nejde o to, že něco nenapíše - on právěže něco napíše 2x, nebo zapíše kus z minula,... Teď jak jsem dal tu prodlevu, tak je to mnohem lepší - když jí dám výraznější, je to dokonce bez chyby - zatím nevím jestli ji tedy nechat tak velkou - 500 ms, každopádně řeším problém, jak zabránit těmto chybám, při vstupu více formů,...
No vida. Snad se konečně dozvíme, jakou chybu to napíše. Zavedení prodlev problém neřeší.
Moc se v tom programu nevyznám, ale proč někdy voláš funkci FileStream() s parametrem appdata a jindy s this.appdata?
Snažím se všude používat this - abych programoval již správně - tady máš aktuální verzi:
"Snažím se všude používat this" - To myslíš vážně? "this" není pro parádu. Jazyk C# neznám, ale předpokládám, že stejně jako u ostatních jazyků je "this" při označování lokálního objektu nezbytný.
Ve Form1.cs ho stále nemáš.
A proč tam máš ten prázdný blok catch? To se dělá?
Když nic nechci? 
Právě
proto, že není pro parádu, se ho snažím používat- tedy spíše jsem ho
začal používat,...
Když budeš dělat prázdné bloky catch, tak se o výjimkách nic nedozvíš a budeš se jen hloupě ptát v diskuzních fórech. A každý tě pošle do háje, protože prázdné bloky catch se zásadně nedělají.
Je rozdíl mezi "snažit používat" a "používat". Když "this" nepoužiješ, odkazuješ se na jinou proměnnou.
Akoráte proč bych používal prázdný catch blok, kdybych o té vyjímce nevěděl? Téměř není možné jiné řešení než přes try blok - tak co mi zbývá. Nebo snad existuje možnost zjištění, zdali selže předání dat? No a protože jsem se proti tomu již pojistil - deafaultní hodnota backimage je nastavena, tak pokud dojde k selhání, nepotřebuji nic dělat - tak co bych dával do catch?
Místo backimage - jen image - jedná se o picture box. Jde o to, že tvůj komentář postrádá logiku - první co udělám, když se vyskytne problém - zobrazím si vyjímku,...
Toto je první program, ve kterém používám this, jak se má. A všechny předchozí pracují jak mají, takže ono to zase tak důležité nebude,... Pokud nemám nikde v programu shodnou proměnnou, tak nedojde ke kolizi,...
Zobrazeno 27 zpráv z 27.