Na die sind ja mal flott 
Sunfreak's Tagebuch 2014
- Ersteller Sunfreak
- Erstellt am
panormal
0
Hi Michi,
Du hast Dir die Antwort auf dein Salpeterbeschaffungsproblem doch ein paar Threads weiter oben in der netter Vogelscheißegeschichte schon selbst gegeben - es muss ja kein reines Salpeter sein.
Gruß,
pan
PS: Was Dein Programm angeht, wozu XPath? Bitte, bitte speichere Daten die nach CSV oder DB schreien nicht in XML ;-) ..Wenn du auf Schwierigkeiten in diesem Bereich stoßen solltest, kannst Du mich gerne auch mal anschreiben - ich verdiene mein Geld damit.
Du hast Dir die Antwort auf dein Salpeterbeschaffungsproblem doch ein paar Threads weiter oben in der netter Vogelscheißegeschichte schon selbst gegeben - es muss ja kein reines Salpeter sein.
Wikipedia schrieb:
Gruß,
pan
PS: Was Dein Programm angeht, wozu XPath? Bitte, bitte speichere Daten die nach CSV oder DB schreien nicht in XML ;-) ..Wenn du auf Schwierigkeiten in diesem Bereich stoßen solltest, kannst Du mich gerne auch mal anschreiben - ich verdiene mein Geld damit.
@ Simone
Auch Post von Steve?
Oder die Dwarfs für die aktive Züchtung?
Grüßle, Michi
Auch Post von Steve?
Oder die Dwarfs für die aktive Züchtung?
Grüßle, Michi
panormal
0
Nichts, aber Dir reicht Zeilenweises einlesen einer CSV-Datei In einer Schleife. Dann einach ein "string[] result = line.Split(';')" Array erzeugen und auch noch ein whatever-Objekt. Das Array dann in das whatever Obejkt schreiben und dieses dann in Deine Liste "List<whatever>" adden - Feritg. XML ist langsam (OK, ist hier egal) und einfach nicht notwenig. Außerdem ist XML viel zu aufwenidig und statt XPath nimmt man eigentlich den XMLReader, welcher noch aufweniger zu nutzen ist.Wieso? Was ist so schlecht am XML?
Gruß,
pan
Gerd,
bei der Duisburger Post wundert mich nix mehr. Ich hätte das nicht mitbekommen, wenn er nicht den halben Briefkasten abgerissen hätte; so hat es sich zumindest angehört. Ist ja schon auch ein bisserl finster draußen, nich...
Da kann man den Briefkastenschlitz schon mal schwer finden.
Nicht Steve...Craig. Das sind 5 Dwarfs die noch nicht auf dem Markt sind.
Ich mach doch beim Dwarf Projekt mit, weißt Du doch!
LG
Simone
bei der Duisburger Post wundert mich nix mehr. Ich hätte das nicht mitbekommen, wenn er nicht den halben Briefkasten abgerissen hätte; so hat es sich zumindest angehört. Ist ja schon auch ein bisserl finster draußen, nich...
Da kann man den Briefkastenschlitz schon mal schwer finden. Nicht Steve...Craig. Das sind 5 Dwarfs die noch nicht auf dem Markt sind.
Ich mach doch beim Dwarf Projekt mit, weißt Du doch!
LG
Simone
Nabend pan!
Danke für Dein Output!
Ich hatte letztens Langeweile auf Arbeit, und wiegesagt ich bin aus der Übung mit Office, ich bin mit Office bis 2003 groß geworden. Jetzt saß ich da vor meiner Excel Mappe und mich weckte das Interesse die *.xlsx Datei mal im Editor zu öffnen (Hex-Editor hatte ich nicht). Und mich wunderte der PK-Header. Und das extrahieren und analysieren meiner Excel-Datei entwickelte sich zu 'nem tollen Abenteuer.
Das inspirierte mich für mein Programm das VDB-Format zu entwickeln. Als starke Anlehnung an Office Open XML und Open Document Formate. Sprich auf Basis von PKZIP und XML.
Was mich am CSV hat abkommen lassen, ich fands schon immer unhandlich, ist die Beschränkung auf Einzeiler. Gut, mehrzeilen Text kann man durch Ersetzen von Cr und Lf durch 'n anderes Zeichen erzielen. Aber irgendwie machts das immer noch nicht flexibler. Klar, die Simpelheit von CSV ist schon was Wert. Wie du ja schreibst. Einmal Split mit Cr/Lf und einmal Split mit ; und du hast die CSV schön aufgebröselt in Arrays.
Kurzum: Fühl mich so eingesperrt mit CSV. So kann ich meine XML mit mehr Daten füllen, ohne beim engen Schema von CSV bleiben zu müssen. Was ich ja heute schon mache. Zum Beispiel häufige Suchanfragen. So reicht z.B. der Buchstabe "T" um den Züchter "Tom Wagner" vorgeschlagen zu bekommen.
Ich werd jetzt auch bei dem eingeschlagenen Weg bleiben, hab da jetzt keine Lust da noch mal dran rumzuwursteln. Mit ein Grund war, dass ich auch Binärdaten (etwa JPEG's) einbetten will. Die Daten etwa mit Base64 kodieren wollt ich auch nicht, also mit 'n Grund für PKZIP.
Na-ja, ob der eingeschlagene Weg der richtige sein wird, wird sich zeigen. Insbesondere wenn die Datenbank dann mal mit 1.000+ Einträgen gefüllt ist. Aber ich hatte jetzt im Vorfeld niemand, der mich drauf aufmerksam machen konnte. Außerdem hab ich mit XML so auch noch nicht gearbeitet. Wollte das für mich neue einfach ausprobieren.
Aber noch ma zurück zu kommen, eine Frage an Dich, wenn XML bei größeren Datenmengen langsam ist: Wie macht man das dann mit Office XML und Open Document? Da kommen dann doch auch große Datenmengen zusammen? Excel Tabellen können mitunter ja auch riesig werden!?
Grüßle, Michi
Danke für Dein Output!
Ich hatte letztens Langeweile auf Arbeit, und wiegesagt ich bin aus der Übung mit Office, ich bin mit Office bis 2003 groß geworden. Jetzt saß ich da vor meiner Excel Mappe und mich weckte das Interesse die *.xlsx Datei mal im Editor zu öffnen (Hex-Editor hatte ich nicht). Und mich wunderte der PK-Header. Und das extrahieren und analysieren meiner Excel-Datei entwickelte sich zu 'nem tollen Abenteuer.
Das inspirierte mich für mein Programm das VDB-Format zu entwickeln. Als starke Anlehnung an Office Open XML und Open Document Formate. Sprich auf Basis von PKZIP und XML.
Was mich am CSV hat abkommen lassen, ich fands schon immer unhandlich, ist die Beschränkung auf Einzeiler. Gut, mehrzeilen Text kann man durch Ersetzen von Cr und Lf durch 'n anderes Zeichen erzielen. Aber irgendwie machts das immer noch nicht flexibler. Klar, die Simpelheit von CSV ist schon was Wert. Wie du ja schreibst. Einmal Split mit Cr/Lf und einmal Split mit ; und du hast die CSV schön aufgebröselt in Arrays.
Kurzum: Fühl mich so eingesperrt mit CSV. So kann ich meine XML mit mehr Daten füllen, ohne beim engen Schema von CSV bleiben zu müssen. Was ich ja heute schon mache. Zum Beispiel häufige Suchanfragen. So reicht z.B. der Buchstabe "T" um den Züchter "Tom Wagner" vorgeschlagen zu bekommen.
Ich werd jetzt auch bei dem eingeschlagenen Weg bleiben, hab da jetzt keine Lust da noch mal dran rumzuwursteln. Mit ein Grund war, dass ich auch Binärdaten (etwa JPEG's) einbetten will. Die Daten etwa mit Base64 kodieren wollt ich auch nicht, also mit 'n Grund für PKZIP.
Na-ja, ob der eingeschlagene Weg der richtige sein wird, wird sich zeigen. Insbesondere wenn die Datenbank dann mal mit 1.000+ Einträgen gefüllt ist. Aber ich hatte jetzt im Vorfeld niemand, der mich drauf aufmerksam machen konnte. Außerdem hab ich mit XML so auch noch nicht gearbeitet. Wollte das für mich neue einfach ausprobieren.
Aber noch ma zurück zu kommen, eine Frage an Dich, wenn XML bei größeren Datenmengen langsam ist: Wie macht man das dann mit Office XML und Open Document? Da kommen dann doch auch große Datenmengen zusammen? Excel Tabellen können mitunter ja auch riesig werden!?
Grüßle, Michi
Anhänge
Ich mach doch beim Dwarf Projekt mit, weißt Du doch!
Weis ich doch, schrieb ich doch auch...
Ist dieses Jahr die Anmeldung schon gelaufen für die Dwarfs? Schätze ja, gell?
Grüßle, Michi
panormal
0
An die Ribbon Bars und die Knöpfe die so groß sind, dass man die nicht mehr wahrnimmt habe ich mich auch noch nicht wirklich gewöhnt ; )
Benenn die .xlsx einfach mal in .zip um - dann wird Dir schlagartig einiges klarer ; )
Dann wird die klar sein, dass sich das Open Document Formal und z.B. .xlsx oder docx. sehr stark ähneln.
Da hast Du Recht und die genannte Vorgehensweise wäre auch die korrekte. Als Linuxuser möchte ich aber anmerken, dass es unter Windows CrLf, unter Mac LfCr und unter Linux nur Lf ist ; )
Ich nehme CSV wenn es ausreicht, Datenbank, wenn es mit wenigen Tabellen zu lösen ist und XML wenn die DB zu komplex würde. Wir speichern die Kundenfälle auf der Arbeit auch in XML weil es viele Daten gibt, welche in kein Tabellenschema passen.
XML Dateien sollten eigentlich Plaintext sein (also mit Editor lesbar). Bei XML ist BASE64 eigentlich der übliche Weg Binärdaten zu speichern. In einer DB hättest du da den "Blob". Mit Sqlite müsste im Falle einer DB-Lösung auch kein Serverdienst laufen (dies am Rande)
Über die Performance würde ich mir da auch mit XPath bei "nur" ein paar tausend Datensätzen keine Sorgen machen. Die Datei wird ja eh nur (hoffe ich) beim Programmstart gelesen und bei Änderung gespeichert. Der Rest ist ja als Liste von whatever-Objekten im Speicher. Einen Simultanzugriff von mehreren Clients auf eine Datei hast Du ja auch nicht (das wäre auch nicht ratsam
)Auch hier liegt das Geheimnis darin, dass der Rechenaufwand nur beim Laden/Speichern und nicht wärend des Editierens auftritt. Und das Laden einer großen Datei ist tatsächlich langsam. Leider interessiert Performance nicht mehr wirklich seitdem die Rechner so schnell sind. Hast Du mal ein altes Visual Studio mit VS 2010, 2012 oder 2013 verglichen? Damals war VS noch nativ geschrieben, jetzt ist alles WPF - mein großes C++ Projekt konnte ich damals auf einen alten Quad-Core in 90 Sekunden kompilieren. Mein dicker i7 mit doppeltet Leistung braucht unter VS2013 jetzt 5 Minuten. Ich habe mal einen Excel-Export geschrieben, welche kein installiertes Office voraussetzt (also die .xlsx komplett selbst erstellt): Hier wird viel mit Indexen auf z.B. Stringtables gearbeitet - das macht die Sache etwas was schneller beim laden und reduziert die Dateigröße. Wie Du scoin richtig sagtest sind das ja bloß viele XML Dateien welche dann gezippt werden.
Gruß,
pan
Pan, nach dem Beitrag "traue" ich mich fast gar nicht was zu schreiben...
Michi, ich denke die Liste ist dicht; Craig hat alle Samen rausgeschickt.
Aber Du kannst ja mal nachfragen...
LG
Simone
Michi, ich denke die Liste ist dicht; Craig hat alle Samen rausgeschickt.
Aber Du kannst ja mal nachfragen...
LG
Simone
Das ist einfach nur furchtbar! Wenn ich 'ne Aufgabenstellung bekomme, würde ich die normalerweise in anständigem Tempo lösen. Aber mit dem "neuen" Office bin ich nur mit suchen beschäftigt. Ich weis nicht, ich tue mich schwer.
Zuhause spare ich mir die Office-Lizenz und hab LibreOffice drauf, da komme ich eigentlich ohne Eingewöhnung klar mit.
Genau, das war das was ich gemacht habe, nachdem ich den PK-Header entdeckt hab, ich dachte "das wird doch wohl nicht 'ne ZIP-Datei sein?" und Tatsache! Geil!
Stimmt!
Jap, und das ist irgendwo doof...
Aber ich sprech jetzt mal von Windows, CrLf. Ich hab keine Ahnung ob und wie sich Programme auf Basis von .net Framework auf Linux oder Mac portieren lassen.
Würde aber die XML massig aufblähen, bei JPEG's, und wenns nur Thumbs mit 128x128 Pixel sind.
Dann bin ich ja beruhigt. Mir erschien halt XPath, nach kurzer Recherche, das ideale Instrument so 'ne Filterfunktion zu realisiere, wie etwa finde alle Sorten die Rot UND gestreift sind UND aus Kalifornien kommen. Oder wie macht man das anders?
So in etwa. Nur nicht beim Programmstart, sondern nach dem Auswählen der Datei im Öffnen-Dialog. Aber sinngemäß das gleiche. Und dann speichern jedes Mal wenn jemand auf die Diskette klickt. Mein Gott bin ich froh, dass bei Microsoft noch niemand auf die Idee gekommen ist, das nicht mehr zeitgemäße Disketten-Speichern-Symbol durch 'n USB-Stick-Symbol oder Speicherkarten-Symbol zu ersetzen. Sonst tät ich wirklich noch die Kriese kriegen!!!
Aber kurios ist ja schon: In der imageres.dll von Windows 7 ist 'n Symbol für 'n 5,25" Diskettenlaufwerk im Windows 7 Design enthalten. Vergleicht man dazu die shell32.dll von Windows XP findet sich zwar auch 'n 5,25"-Symbol, aber da hat man sich nicht *mehr* die Mühe gemacht eins im XP-Stil zu modellieren. Man hat einfach das alte aus Windows 98/ME/2K Zeiten hergenommen. Was sollte das also in Windows 7? Glaubt Microsoft an ein Comeback der 5,25" Diskette, oder wie!? *lach* Das nur am Rande...
Nein, ich bin von Windows XP und Visual Studio 2005 auf Windows 7 und Visual Studio 2013 Express umgestiegen. Aber es ist schon recht träge, das neue VS. Ich wollte nur mal kurz den Objektkatalog zum XMLReader aufrufen, quasi auf Deine Anmerkungen hin. Es scheiterte schon daran, dass F2 nun nimmer geht, es braucht irgend 'ne andere Tastenkombination, die ich schon wieder vergessen habe. Aber der Weg bis ich zum dem Ergebnis kam vom Start bis zum Suchergebnis nach XMLReader und die ganzen Funktionen & Co. das war wie 'n zäher Kaugummi. Seltsam nur, dass lt. Task-Manager weder die CPU, noch lt. LED meine Festplatten beansprucht wurden, keine Ahnung was VS so träge machte!?
@ Simone
Achso, ist ja nicht so wild. Hätte mich jetzt spontan aus 'ner Flause heraus entschieden dort mitzumachen. Aber so isses echt auch nicht schlimm.
Grüßle, Michi
Mein Programm ist fast fertig! Ich bin stolz wie Bolle! :?
Grüßle, Michi
Grüßle, Michi
panormal
0
Hi Michi,
ich sehe schon, und bist doch recht begabt. Kannst ja mal ein paar Screenshots von dem Programm einstellen.
Gruß,
pan
ich sehe schon, und bist doch recht begabt. Kannst ja mal ein paar Screenshots von dem Programm einstellen.
Beruflich komm ich an Microsoft nicht vorbei, daher nehme ich auch privat das Office-Paket - Lizenzgebühren können mir glücklicherweise egal sein; ich habe ein für mich kostenloses MSDN-Abo.
Da es ja im Endeffekt eine ZIP ist kannst Du Binärdateien ja auch einfach einzeln mit ins Archiv packen und dann auf den Namen verlinken. Das wäre sauber und Du kannst Das XML weiter mit einem Editor lesen.
Kurz gesagt: Der Windows Taskmanager ist für den Arsch ; )
Gruß,
pan
protour
0
Screenshots würden mich auch Interessieren, hab leider keine Ahnung vom Programmieren.
Ist das Programm nur für dich?
Oder stellst Du das für ein paar Beattester zur Verfügung?
Ist das Programm nur für dich?
Oder stellst Du das für ein paar Beattester zur Verfügung?
H
harzfeuer
Guest
Danke! Bei der richtigen Luxzahl aber nicht wirklich ein Problem. Die gehen voll ab.
Am meisten Criolla Sella, die haben sogar schon Blüten.
Lieben Gruß
Anett
Huhu Leute!
Habe die Programmierung an meinem Programm heute im Kern abgeschlossen. Die Eingabe der ersten 190 Sorten hat das Progrämmchen ohne Absturz überstanden.
Hier ein Screenshot von der Oberfläche:
Ich bin insofern zufrieden, ich hatte mehr Bugs im Praxistest erwartet, aber bisher hatte ich nur zwei Leichtsinnsfehler.
Hier ein paar Beispiele vom Filter:
Alle Sorten aus der Cherokee-Familie:
Oder alle Sorten, die von einem bestimmten Züchter stammen:
Dialog zum Erstellen/Bearbeiten von Sorten-Einträgen - hier Auswahl der Bezugsquelle. Hat man z.B. viele Sorten von der spendablen Hamlet, muss der Namen nicht jedes Mal neu eingegeben werden. Man kann ihn dann aus einer Liste wählen oder bekommt ihn vorgeschlagen (etwa wie wenn man in Google Suchbegriffe eingibt).
Allerdings ist das Tool in einer noch sehr frühzeitigen Phase. Es läuft zweckmäßig und das gut. Enthält aber nur wenig Features & Funktionen. Es tut für was ich es brauche, um für mich den Überblück zu schaffen. Es ist halt für mich maßgeschneidert, aber nicht für die breite Masse gedacht.
Sollte wirkliches Interesse an meinem Tool bestehen, könnte ich es mir schon vorstellen bereit zu stellen. Allerdings bräuchte es dazu weiteren Feinschliff, Anpassungen und so...
Dann wäre eine Funktion angedacht um die Reihenfolge der Spalten zu ändern, oder Spalten auszublenden. Beispielsweise kann der eine mit der wissenschaftlichen Bezeichnung nichts anpassen, für ihn wäre dann diese Spalte Platzverschwendung, also sollte man sie ausblenden könnte. Stattdessen fände er es nützlich, wenn die Fruchtfarbe gleich an zweiter Stelle, nach dem Sortennamen auftauchen würde, also sollte man die Anordnung der Spalten ändern können. Und so weiter...
Aber in die Richtung will ich zumindest für die nächsten Wochen wenig Erwartungen schüren. Es wird nur noch eine größere Änderung geben, und dass ist die Anbindung an Tatiana's Datenbankserver. Dann genügt die Eingabe des Sortennamens und die restlichen Daten holt das Programm dann automatisch von der TOMATObase. Wiegesagt das Programm soll in erster Linie zweckmäßig mich erleichtern. Dran aufhalten will ich mich zurzeit nicht. Deshalb vorerst auch kein public Release.
Grüßle, Michi
Habe die Programmierung an meinem Programm heute im Kern abgeschlossen. Die Eingabe der ersten 190 Sorten hat das Progrämmchen ohne Absturz überstanden.
Hier ein Screenshot von der Oberfläche:
Ich bin insofern zufrieden, ich hatte mehr Bugs im Praxistest erwartet, aber bisher hatte ich nur zwei Leichtsinnsfehler.
Hier ein paar Beispiele vom Filter:
Alle Sorten aus der Cherokee-Familie:
Oder alle Sorten, die von einem bestimmten Züchter stammen:
Dialog zum Erstellen/Bearbeiten von Sorten-Einträgen - hier Auswahl der Bezugsquelle. Hat man z.B. viele Sorten von der spendablen Hamlet, muss der Namen nicht jedes Mal neu eingegeben werden. Man kann ihn dann aus einer Liste wählen oder bekommt ihn vorgeschlagen (etwa wie wenn man in Google Suchbegriffe eingibt).
Allerdings ist das Tool in einer noch sehr frühzeitigen Phase. Es läuft zweckmäßig und das gut. Enthält aber nur wenig Features & Funktionen. Es tut für was ich es brauche, um für mich den Überblück zu schaffen. Es ist halt für mich maßgeschneidert, aber nicht für die breite Masse gedacht.
Sollte wirkliches Interesse an meinem Tool bestehen, könnte ich es mir schon vorstellen bereit zu stellen. Allerdings bräuchte es dazu weiteren Feinschliff, Anpassungen und so...
Dann wäre eine Funktion angedacht um die Reihenfolge der Spalten zu ändern, oder Spalten auszublenden. Beispielsweise kann der eine mit der wissenschaftlichen Bezeichnung nichts anpassen, für ihn wäre dann diese Spalte Platzverschwendung, also sollte man sie ausblenden könnte. Stattdessen fände er es nützlich, wenn die Fruchtfarbe gleich an zweiter Stelle, nach dem Sortennamen auftauchen würde, also sollte man die Anordnung der Spalten ändern können. Und so weiter...
Aber in die Richtung will ich zumindest für die nächsten Wochen wenig Erwartungen schüren. Es wird nur noch eine größere Änderung geben, und dass ist die Anbindung an Tatiana's Datenbankserver. Dann genügt die Eingabe des Sortennamens und die restlichen Daten holt das Programm dann automatisch von der TOMATObase. Wiegesagt das Programm soll in erster Linie zweckmäßig mich erleichtern. Dran aufhalten will ich mich zurzeit nicht. Deshalb vorerst auch kein public Release.
Grüßle, Michi
Was ist denn bitte Hamlet?
Das wird doch wohl nicht Deine Kreuzung sein???
LG
Simone
Das wird doch wohl nicht Deine Kreuzung sein???
LG
Simone
Ist die Frage ernst gemeint?
Oder hast du den Sidekick nicht verstanden!? :d
Doch, den musst du verstanden haben...
Grüßle, Michi
Oder hast du den Sidekick nicht verstanden!? :d
Doch, den musst du verstanden haben...
Grüßle, Michi