Menüpunkt "Debug"/"Break All" und dann im Threads-Fenster den Thread wechseln und zur aktuellen Codeposition springen (bzw. über den Stacktrace navigieren).
johan schrieb:
Könnte sein, dass ich das falsch ins Forum übertragen habe. Die Original-Datei habe ich leider nicht mehr. Hatte ich aus dem eigentlichen Projekt mittels copy and paste in die hier veröffentlichte, stark verkürzte Version übernommen - ließ sich aber soweit ich mich erinnere erstellen.
Per Copy&Paste? Dann ist das kein Schreibfehler bei der Übertragung: "puplic"? Das siehst du ja sogar in der Syntaxhervorhebung, dass du das Wort falsch geschrieben hast.
Grüssli
Hallo zusammen!
Im Buch von David Sceppa über ADO.NET gibt der Autor einen Hinweis bezüglich Unterschiede im Verhalten von DataRowView zwischen ADO.NET 1.1 und ADO.NET 2.0.
Folgender Code
DataTable tbl = new DataTable("MeineTabelle");
// Tabelleneigenschaften festlegen
tbl.Columns.Add("Spalte1", typeof(string));
tbl.Columns.Add("Spalte2", typeof(string));
// Daten in Tabelle einfügen
tbl.Rows.Add(new Object[] { "AAA", "aaaaaa" });
tbl.Rows.Add(new Object[] { "BBB", "bbbbbb" });
DataView vue = new DataView(tbl);
// aufsteigend sortieren
vue.Sort = "Spalte2 ASC";
// erste Zeile der DataView auswählen und erste Spalte ausgeben
DataRowView row = vue[0];
Console.WriteLine(row["Spalte1"]);
// absteigen sortieren
vue.Sort = "Spalte2 DESC";
// vorher gewählte Zeile erneut ausgeben
Console.WriteLine(row["Spalte1"]);
Laut Sceppa ist row in ADO.NET 1.1 ein Verweis auf ein DataRow-Objekt, was dazu führt, dass die geänderte Sortierung keine Wirkung auf die Ausgabe hat.
D.h. in ADO.NET 1.1 würde obiger Code folgende Zeilen ausgeben:
AAA
AAA
In ADO.NET 2.0 soll row hingegen ein Verweis auf einen Eintrag in der DateView sein. Das führt dazu, dass row immer noch auf die erste Zeile der DataView zeigt, welche sich aber durch die Änderung der Sortierung selbst auch geändert hat. Die Ausgabe soll in ADO.NET 2.0 also so lauten:
AAA
BBB
Leider bekomme ich mit Visual Studio 2008 Express diese Behauptung nicht nachvollzogen. Bei mir kommt es immer zur ersten Ausgabe, also zweimal "AAA". Habe es auch schon mit Zielsystem .NET 2.0 versucht.
Stimmt die Behauptung von Sceppa bzw. was mache ich falsch?
Vorab schon mal Danke fürs Lesen.
Dann solltest du das vielleicht dazusagen.
Mit einem rechteckigen mehrdimensionalen Array geht das nicht, da gibt es nämlich nur das Gesamtarray und die einzelnen Elemente. Es gibt keine Referenzen auf Teil-Arrays. Anders bei einem "verzweigten" Array (Microsoft nennt das so: http://msdn.microsoft.com/de-de/library/2s05feca(v=vs.80).aspx ). Das ist ein Array, das ganz normal (Referenzen auf) andere Arrays enthält, und damit geht auch das, was du vorhast.
int[] [] dimArr = new int[5][];
int[] arr = new int[5];
dimArr[0] = arr;
OrginellerName schrieb:
Kein Thema das mit dem double Vergleich. Mann kann hier noch vieles verbessern. Und keiner hat gesagt, dass ich Geschwindikkeitsvorteile habe mit der Dictionary. Aber viel sauberere als die if else Lösung. Und leicht erweiterbar.
OK, also meinst du mit Dictionary ja doch ein sequentielles Durchmustern aller Fälle. Dann sind wir aus meiner Sicht wieder zurück bei "da gibts nichts zu diskutieren".
Ihr habt mir immer noch nicht verraten wie ihr das if else Konstrukt erweitert wenn ihr die Werte per GUI pflegen wollt.
Was erwartest du denn darauf für eine Antwort, die du nicht schon kennst? Die Frage ist, ob man das je braucht. Sollte man das von vornherein flexibel machen, auch wenn man es eigentlich meint nicht zu brauchen?
BTW wenn du nicht "Dictionary" gesagt hättest wär der Thread 50% kürzer.
Ähm in der IDE auf Attribute klicken und dann geht der Dialog auf ??
Das wäre mir neu..
Wie wärs wenn du dich mal klar ausdrückst was du willst ?
Wenn du das Property von NullBockException nutzt wird der Dialog immer aufgerufen wenn du den den Wert des Property abfragst.
Wenn es anders sein soll musst du es ander schreiben. Und wenn das Property irgendwie mit Windows Forms Controls verknüpft ist ändert das auch einiges.
sinnmacher schrieb:
In C# könnte man problemlos einführen, dass alle Klassen und Methoden deklariert sein müssen bevor man sie benutzt.
Jop und in C++ ist es bereits so...
sinnmacher schrieb:
Und *nur* deklariert.
Genau so funktioniert das in C++ im Allgemeinen...
sinnmacher schrieb:
In C++ ist das nicht möglich. Den Templates müssen vollständig bekannt sein.
Ja, für viele Dinge muss unter gewissen Umständen die vollständige Definition bekannt sein. Mir ist aber nicht klar, wieso genau das in C#, wo das im Moment fundamental anders funktioniert, nun mehr Sinn machen sollte als in C++, wo das im Moment genau so funktioniert...
ADO.net ist Teil des .Net-Frameworks, und auch das Entity Framework wird soviel ich weiß inzwischen mit .Net ausgeliefert. Da aber gerade das Entity Framework schneller als die .Net-Versionen aktualisiert wird, kann es hier sinnvoll sein über Nuget neuere Versionen zu laden.
Wobei ich nach deinen verschiedenen Fragen nicht den Eindruck habe, das du für das eine oder andere wirklich fit genug bist. Oder aber du bist einfach zu faul selbst nachzulesen...
OrginellerName schrieb:
Das heißt die Objekte die die Events abfangen, füllen dann die Listen im ViewModel. Oder im Model?
Die Frage ist hier wohl: Welche Abhängigkeiten akzeptiert man, und welche kann man aufbrechen.
Ich persönlich ziehe den Ansatz vor das die Aufrufrichtung immer von einem höheren (Näher am Benutzer) zu einem niedrigeren (Näher an einer Datenquelle) Layer geht [Oder mittels "Callbacks" (Seien es nun registrierte Schnittstellen, Eventhandler...) die Abhängigkeit umgedreht wird, ohne Detail preis zu geben], dabei aber Abhängigkeiten auch hinter austauschbaren Schnittstellen verborgen werden.
Sprich: Ich selbst habe kein Problem damit das ein ViewModel die Daten abruft, doch würde ich hier das ganze hinter einer Schnittstelle verbergen die ich austauschen kann.
hustbaer schrieb:
Dass Doxygen die XML Kommentare versteht wusste ich nicht. Funktioniert das gut?
Wie gesagt, nicht unbedingt sehr gut. Aber man kann damit arbeiten. Man muss sich vielleicht zum Teil etwas einschränken und Rücksicht auf Doxygen nehmen.
hustbaer schrieb:
Dabei werden aber vermutlich die original .cs Files geparsed und nicht die von VS erzeugten .xml Files, richtig?
Genau.
Grüssli
Jetzt habe ich ein DoEvents vor TextBox.SelectAll eingefuegt und jetzt tritt dies nur noch beim Erstmaligen Aufruf auf und verkuerzt sich ansonsten auf <150ms.
