[C#] Microsoft Excel tabellen ansprechen, wie?

Arnd schrieb:
CR/LF == Carriage Return/Linefeed == Zeilenumbruch.

D.h. am einfachsten und schnellsten Shareware kaufen. Wenn Du programmieren willst, so ist das auch möglich :-).

Bis 30.04.07 hast Du noch 6 Monate Zeit. Bei 8h pro Woche, heisst das 1 Tag pro Woche. D.h. 24 Tage, das entspricht ca. 5 Wochen Fulltime. Davon ist mindestens die Hälfte mit Doku und anderen Sachen ausgefüllt. D.h programmieren musst Du das alles in 2-3 Wochen. Da Du aber anscheinend relativ wenig Erfahrung hast, halte ich das für nicht realisierbar.
Auf jeden Fall ist das zu wenig um sich in ein SDK einzuarbeiten oder einen relativ aufwendigen Parser für Textdateien zu schreiben. Vor allem wenn man das noch nicht gemacht hat.

D.h. so wenig wie möglich selber programmieren. Ist C# eigentlich auch eine Vorgabe? Vielleicht kannst Du das ja auch in Access machen. Dann würde sich das alles auf ein bisschen Oberfläche und eine SQL Abfrage reduzieren. Auf der Grundlage einer Textdatei die in eine Access Datenbank importiert wird. Und die Textdatei wird durch einen Shareware Konverter geliefert.

Wenn Du programmieren willst, würde ich auf jeden Fall mal mehr Stunden pro Woche einplanen. Am Anfang würde ich da auf jeden Fall mal sämtliche Wochenenden vorsehen.

Das schlimmste für ein Projekt ist, wenn man kurz vor Abgabe ist und feststellt das man nicht fertig wird.

MfG

Arnd

Ne einen Parser für PDF Files bei meinem Wissen würd ich mir selbst auch net empfehlen. Ich dacht ja zuerst das PDF Dateien lesen genauso einfach is wie normale .txt Files lesen. Da hab ich mich aber schön geirrt.

Scheinst dich ja recht gut mit Projektmanagement auszukennen, ich selber habe geplant 60% der Zeit in Planung und Dukumentation zu stecken. Tja aber zum glck sind da noch die Weinachtsferien. :D . Was das Projekt betrift bin ich optimistisch. Jetzt bleibt mir ja nur noch das Excel - Problem aber das is sicher net so schwer wie PDF.

HAt da wer vielleicht einen guten Link für mich. Aber bitte nicht den von myCsharp.com
 
pff shareware kaufen ... ich wünschte sowas hätt ich bei meiner abschlussarbeit machen können
 
Die 60% sind schon ok. Ich würde aber die Programmierung nicht erst am Schluss anfangen. Das geht nur gut wenn man Erfahrung hat und sich sicher ist das man alle anfallenden Probleme auch lösen kann.

In Deinem Fall ist es sicherer die Programmierung möglichst weit nach vorne zu ziehen um zu sehen ob das Problem auch so lösbar ist und dann die dazu passende Dokumentation zu erstellen. Das führt sicherer zum Ziel. Zumindest würde ich das parallel machen und nicht sequentiell.

Wenn Du dafür einen passenden Begriff brauchst um das Vorgehen zu rechtfertigen, wäre Rapid Prototyping vermutlich der passende Ansatz.

MfG

Arnd
 
ja erst programmieren und dann die dokumentation machen, macht vorallem bei kleinen problemen sinn UND in der schule. da die meistens viel mehr wert auf die doku als auf das programm legen.
 
He danke leute, das mit dem rapid Prototyping kommt mir bekannt vor. Auf jeden fall mach ich die ganze sache parallel. Wobei ich zuerst die ganze oberfläche designe und dan mit dem Code anfange.
 
Ich möchte das nicht als gute Lösung verstanden wissen. Erst programmieren und dann Doku ist konkret gesagt Pfusch.

Nur aus praktischen Erwägungen heraus und eben wenn es das erste grössere Projekt ist, darf man nicht vergessen, das man auch an Kleinigkeiten manchmal verzweifeln kann und dafür sehr sehr lange brauchen kann. Eben diese Zeit fehlt einem dann am Schluss wenn man stur nach der Theorie vorgeht.

Diese Stolperfallen gilt es vorab auszuschliessen. Wenn das alles geklärt ist und man selber das Gefühl und die Gewissheit hat, das alles so funktioniert wie man es sich vorgestellt hat. Dann sollte man anfangen die Doku zu perfektionieren.

Wenn man schon einige Projekte gemacht hat und entsprechende Erfahrungswerte hat, kann man es sich auch mal erlauben die Reihenfolge umzudrehen :-). Vorher ist da ein bisschen Fingerspitzengefühl angesagt.

Das musste noch raus :-).

MfG

Arnd
 
Zurück
Oben