Der Debug Build Version 1.2.0.0 stürzt bei mir unter Windows 7 mit der Meldung "...funktioniert nicht mehr." ab.
Druckbare Version
Der Debug Build Version 1.2.0.0 stürzt bei mir unter Windows 7 mit der Meldung "...funktioniert nicht mehr." ab.
@ pdelvo
Wenn ich das recht sehe, dann ist das eine WPF-Anwendung. Die Frage, die sich mir nun stellt ist, welches Framework zu benutzt hast ?
Desweiteren kann ich dir gleich noch einen Tipp geben in Bezug auf "String-Combining" und zwar solltest du Strings nicht per "+" verbinden, sondern dazu ein "String.Format" benutzen. Denn, wenn du ein "+" benutzt, dann wird immer ein neuer String instanziert. Weiterhin solltest du du vllt bei dem Laden der Settings-Dateien erst einmal überprüfen, ob diese auch existiert. Dazu scheint mir nämlich die Abfrage zu fehlen. (siehe deine "LoadConfigFile()-Function"). Was beim Debuggen auch helfen kann ist, wenn du bei den "try-catch-Blöcken" bei der "catch-Abfrage" auch ne MessageBox mit dem Fehler ausgeben lässt. Dann kannste schnell kleine Fehler finden. Denn wenn ich mir den Code gerade so ansehe, dann fehlen diese. ;)
Ah ein Reflector User ;-)Zitat:
Zitat von Pat21
Es fehlt noch einiges nachdem ich ein wenig umgebaut habe. Habe die version doch etwas zu früh freigegeben, aber ich konnte wiedermal nicht warten :roll:
as zusammenketten mit "+" sollte schneller sein als das zusammenketten mithilfe von string.Format.
das stringa + stringb + string c wird zu einem string.Concat(new string[]{stringa, stringb, stringc}). Wenn du mir das nicht glaubst guck dir mal den IL Code an. der Reflector interpretiert das wieder zu " x + y", damits schöner aussieht.
Intern wird ein neuer Speicherblock mit der länge aller elemente allokiert und dann dort reinkopiert. string.format erstellt einen StringBuilder mit der startgröße formatstring.Length + (anzahl_strings * 8).
Dort wird also auf gut glück erstmal speicher allokiert, da er nicht weiß wie lang das ganze schlissendlich wird. Dann geht er char für char durch den formatstring und arbeitet das ab. Das sollte auf jedenfall langsamer sein.
Dazu kommt noch:
Und die 97% sind in dem Beispiel vollkommen übertrieben. Was interessiert es den Benutzer wenn ich vllt 1ms schneller war, aber das entwickeln von updates 3 mal länger brauchen, weil der Code unübersichtlich geworden ist?Zitat:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
(Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)
Zum Framework: Ich benutze das .net Framework 4.0. Bis vor kurzem habe ich aber noch alles nach 3.5 kompiliert. Aber ich finde, dass langsam das neue Framework weit genug verbreitet ist und ich endlich die neuen Funktionen benutzen kann. In dem Tool aber nur an einer kleinen Stelle: System.Tuple<T1, T2> gibt es ab 4.0.
Wenn du willst kannst du aber mal den Source Code haben. Ist so schon ein wenig besser zu lesen. Ich habs sogar schön kommentiert und der Reflector zeigt ja oftmals auch nicht genau das an, was ich eingetippt habe.
Jetzt mach ich erstmal wiede auf Bugsuche in den ganzen halbfertigen Funktionen.