Profil von Knuddlbaer
myCSharp.de - Member Mitglied seitSchnellaktionen
Profil-FunktionenMit spy schon geprüft welche Meldungen insgesamt geworfen werden wenn die Taste gedrückt wird ?
Schau mal ob Dich das hier weiterbringt:
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/e5f0c371-b900-41d8-9a5b-1052739f2521/ (Deserialize - unable to find an Assembly .....)
Btw.: "Unbekannt" und deserialisieren passt nicht.
- die Exception erfolgt definitiv nicht erst beim Ausführen der potentiell kritischen Zeile "testList_.curDivTime = testList_.curDivTime - testList[i-1].curDivTime;" sondern bereits beim Aufruf der DLL-Funktion
Und woher weißt Du das ?
Ein Motor funktioniert so, dass er <bla blubb>. Das würden IMHO die meisten so auffassen, das erläutert wird wie ein Motor funktionert. Man erklärt ja nicht, wie er im speziellen zusammengebaut ist sondern erläutert die grundlegende Funktionalität. Das lässt sich IMHO auch auf
tryparse funktioniert so:
public static bool TryParseInt64(string wert, out long variable) { try { variable = Convert.ToInt64(wert); } catch{return false;} return true;}
übertragen. Das kann man durchaus so verstehen, dass hier behauptet wird, TryParse verwendet einen Try Catch block.
Vielleicht liegt mein Fehler ja daran, das ich nicht weiß was einzelne User hier schreiben oder mir der Postzähler vollkommen egal sind, aber ich finde es Notwendig zu so etwas ergänzend Hinweise zu liefern. Es wird ausreichend Leser geben, die aufgrund des oben zitierten Posts glauben, dass TryParse mittels try catch implementiert sind.
Wer sich so schwammig ausdrückt muss einfach damit Rechnen das es auch ein Kommentar dazu gibt. Wer das nicht will soll ich vorher klar ausdrücken.
kannst du im konkreten Fall davon ausgehen, dass JAck30lena genau weiß und wusste, dass bei TryParse intern keine Exception auftritt. Dazu hat er an anderen Stellen schon viel zu oft geschrieben, dass man TryParse statt try { Parse } catch {} verwenden soll, um Exceptions zu vermeiden.
Ein Forum dient zum Informationsaustausch und zum erlernen von Tatsachen. Besteht die Gefahr das etwas falsch interpretiert wird, ist eine Korrektur oder Hinweise i.d.R. erwünscht. In diesem Forum fühlen sich gleich alle angegriffen und rechtfertigen sich mit Argumenten die völlig Irrelevant sind. Es ist doch vollkommen egal was Jack weiß oder was Du glaubst zu wissen was Jack weiß oder was andere User anhand des Postzählers oder Bekanntschaft glauben was Jack sagen wollte.
IMHO ist viel entscheidender, dass eine Aussage im Raum steht, die so interpretiert werden kann, dass TryParse mit try catch implementiert ist. Was um Himmelswillen spricht dann dagegen dies zu korrigieren - und für alle die es so interpretieren wie ich es getan habe (ja, ich kenne die Posts von Jack nicht und Postzähler sind mir vollkommen egal) der wichtige Hinweis kommt, das dem nicht so ist.
Zur Qualität der Beiträge möge jeder für sich die Frage beantworten, wie der Verlauf der Diskussion gewesen wäre, wenn jemand mit nur 5 Postpunkten geschrieben hätte, dass ein TryCatch so funktioniert: <Code mit einem try catch Block um Parse>
Das rausreden anhand von Goldwaage kennen wir in diesem Forum schon. (Das schöne bei mehrdeutigen Aussagen).
mir ist klar, das es nicht exakt so implementiert ist wie ich beschrieb. daher habe cih geschrieben das es so ++funktioniert ++und nicht das es so implementiert ist.
Nein, es funktioniert so nicht.
Als out-Argument übergebene Variablen müssen zwar nicht initialisiert werden, bevor sie übergeben werden, aber die aufrufende Methode muss einen Wert zuweisen, bevor die Methode einen Wert zurückgibt.
tryparse funktioniert so:
public static bool TryParseInt64(string wert, out long variable) { try { variable = Convert.ToInt64(wert); } catch{return false;} return true; }
Nö, tuts nicht. Stell den Debugger mal auf das Fangen von Ausnahmen der ersten Chance ein und vergleiche das TryParse des Fameworks mit Deiner Varianten. (Abgesehen davon, das sich Deine Variante nicht übersetzen lässt.)
Spätestens wenn man den Quellcode vom Framework durchsteppt wird man sehen das es kein einfaches try catch um ein parse ist.
nö,
varist nicht typenlos, sondern dient nur dazu, den Typ nicht zweimal schreiben zu müssen.
var v5 = new { Color=108, Price = 12.2};
var ist sicherlich nicht typenlos, aber mehr als "dient nur dazu , den Typ nicht zweimal schreiben zu müssen"
MSDN: Anonyme Typen (C#-Programmierhandbuch)
MSDN: Implizit typisierte lokale Variablen (C#-Programmierhandbuch)
Das PropertyGrid zeigt alle public Eigenschaften Deiner Klasse an wenn Du diese mittels SelectedObject zuweist.
Beides findest Du entweder in der MSDN oder im Grundlagenbuch.
Thread.Sleep(xxx) verhindert u.a. das Windows-Nachrichten richtig ausgewertet werden. Es gibt die große Keule
Application.DoEvents()die zwingend alle vorhandenen Windows-Nachrichten weiterleitet / auswertet. Aber das sollte man vermeiden.
Bei einem Thread.Sleep im UI Thread wird Dir auch ein Application.DoEvents nicht helfen. Der Thread seht AFAIK mindestens so lange wie in Thread.Sleep angegeben. Er bekommt einfach keine Zeit zugewiesen etwas zu machen.
if (connection == null) else if (connection != null)eher
if (connection) else if (!connection)
Wo ist da jetzt der Unterschied ?