Zumal

(zum beispiel: 5/3 = 2,63/16 = 15)

mathematisch einfach falsch ist - auch wenn er vorher geschrieben hat, dass es um die Modulo Operation geht. '/' ist eine Division und kein Modulo. Dann hätte er entweder mathematisch "mod" oder programmiertechnisch '%' nehmen sollen.

Nun, offensichtlich möchtest du einfach nur das verknüpfte Programm starten. Daher ist Process.Start dennoch dein Freund - trotz "Das funzt auch nicht"...

Probier es einfach mal mit:

System.Diagnostics.Process.Start(@"c:\test.txt");

Dazu noch drei Tips:

Initialisiere die marken mit false -> Spart dir zwei else-Zweige
Nutze TryParse statt Parse beim Einlesen -> Erspart dir lästige Exceptions
In der Aufgabenstellung steht "Wenn Zahl x größer ist als 5", nicht größer oder gleich 5!

Edit: Hmm... sehe gerade, dass die Aufgabenstellung bzw. das Ergebnis eh nicht konsistent sind. Zahlen == 5 werden nicht berücksichtigt. Dann kannst du dir den letzten Tip wohl sparen - oder im Untericht mal anmerken. 😉

Gruß,
Thunder

Original von Thunderhawk
Nun habe ich die selben Zeilen in einem kleinen Testprojekt gegengecheckt -> da geht es.
Das Testprojekt auch in SourceSafe eingecheckt -> geht trotzdem noch!

An SourceSafe liegt es ja wohl nicht - oder nicht nur...

Noch irgendwelche Ideen oder Anregungen, wie man das Problem umgehen oder diesem auf den Grund gehen könnte? Ist ja doch äusserst kurios, dass double abhängig vom Projektkontext mal funktioniert (so genau das bei diesem Datentyp geht) und mal nicht.

Hallo Speedy,

Stichwort 'StreamWriter' mit überladenen Konstruktor (string Path, bool Append).
Schau dir eventuell auch noch die Encoding Klasse an, falls du Umlaute etc. drin hast.

Gruß,
Thunder

Hallo,

gleiches Problem - ähnliche Baustelle:

In einem größeren Projekt (dass auch unter SourceCode Verwaltung steht), liefern folgende Zeilen krumme Werte. Ausgangspunkt ist natürlich ein anderer, aber das nur am Rande.

decimal deci = 123.45678m;
double dRes = Convert.ToDouble(deci);
dRes = Math.Round(dRes, 3);

Nun habe ich die selben Zeilen in einem kleinen Testprojekt gegengecheckt -> da geht es.
Das Testprojekt auch in SourceSafe eingecheckt -> geht trotzdem noch!

So, nun die Fragen: Ist das einfach nur ein Bug, der in großen Projekten gerne mal auftritt oder kann das auch irgendwas mit irgendwo gesetzten Umgebungsvariablen (/Culture Einstellungen?) für Genauigkeit etc. pp zu tun haben?
Und was zum Geier kann man dagegen tun wenn alle bisher gefundenen und selbst entwickelten Workarounds absolut keinen Effekt haben, man aber aufgrund Datenmodell und diverser Berechnungen auf 'double' angewiesen ist?

Verzweifelte Grüße
Thunder

Schade eigentlich. Dann werde ich bei Gelegenheit mal da vorbeischauen. Danke.

Ich bügel die Fehler in soweit aus, dass nicht ein kompletter Import wegen eines kleinen fehlerhaften Attributs fehlschlagen muss. Da würde ich gerne selbst entscheiden, ob ich das nur protokollieren möchte oder abbrechen.

Ich könnte natürlich das Schema entsprechend anpassen (bzw. einfach die Referenzliste rauslassen) aber das ist ja nicht wirklich Sinn der Sache.

Hallo,

ich deserialisiere Xml-Dateien anhand eines gegebenen Schemas. Das funktioniert auch so weit ganz gut - allerdings nur mit korrekten Dateien.

Wenn irgendwelche inhaltlichen Fehler vorhanden sind, bricht die Deserialisierung ab bzw. schmeisst eine Exception.
Bsp: Fehler im XML-Dokument (55,42).
InnerException: Instanzvalisierungsfehler: 'AI' ist kein gültiger Wert für InnenschuzType.

Meine Frage ist jetzt: Gibt es eine Möglichkeit diese inhaltlichen Fehler quasi zu ignorieren und trotzdem mit der Deserialisierung (mein neues Lieblingswort) weiter zu machen? In der Praxis kommt es nunmal vor, dass ein paar Daten fehlerhaft sind...

Kann man den Serializer so steuern, dass er in einem solchen Fall Default-Werte setzt und nicht abbricht?

Lg

Es sei denn er hat nach wie vor das

if (OUTP != null)

bereits vor der Klammer stehen... 😉

Stichworte:
XmlDocument
SelectSingleNode
XPath

Wurde glaube ich schon einige Male besprochen.

Warum du jetzt aus der While-Schleife eine Do-While-Schleife gemacht hast erschließt sich mir nicht ganz. Diese sollte man nur einsetzen, wenn etwas auf jeden Fall einmal durchlaufen werden soll. Mit der vorher eingesetzten Schleife (kombinierte Zuweisung und Abbruchbedingung) hattest du eine If-Abfrage weniger.

Außerdem solltest du bei deiner "Contains"-If-Abfrage kein bitweises Und benutzen! & -> &&

Original von Andi123
Fehlermeldung:
StandardOut wurde nicht umgeleitet, oder der Prozess wurde noch nicht gestartet.

Das ist auch völlig richtig, der Prozess myProcess wurde noch nicht gestartet!
Du mischst hier zwei Möglichkeiten zur Prozesserstellung:

1. Prozess-Instanz erstellen, deren Startinfo einstellen und ausführen
2. Statisches Process.Start, das eine Prozess-Instanz zurückgibt

In deinem Fall die schnellste Lösung:
Einfach ein "my" vor Process.Start 😉

Original von Friedel
Oder schreib in den if-Block

test.Add(s);  

Dann hast du in der Liste test allerdings nicht alle Einträge aus der Liste myList, sondern nur die, die nicht mit "Admin", "svc", usw. anfangen.

Ich nehme mal an, daß er genau das haben möchte. Im Übrigen würde ich, wenn du bei den if-Abfragen bleiben möchtest, die Negierungen rausnehmen und odern

if(s.StartsWith("Admin") || s.StartsWith("*"))
     continue;
else
test.Add(s);

Dann springt er zumindest sofort raus, sobald er eins gefunden hat und geht nicht stumpf alle Abfragen durch.

Zu nochwas:
Kommt drauf an, was du noch damit vorhast... Am Besten das Ganze in eine Funktion packen und ArrayList als Rückgabetyp. Dann die neue ArrayList zurückgeben.