Das Problem ist das 64bit-Anwendungen nur 64bit-DLLs laden können (das gleiche Spiel bei 32bit-Anwendungen).
Mit der "x86"-Einstellung hast du deine Anwendung nun quasi auf 32bit runtergestuft
Hey, im studio selber ist das ganze auch net schneller.. ja meine Maschine is auch rel. schwach. (3ghz 1GB ram) Was mir augefallen ist, wenn ich die gleiche abfrage zweimal hintereinander starte, ist sie beim 2ten mal 1000m la schneller?? Werden die daten wohl irgendwie noch gecached??
Danke.
Die Visible-Variante ist bei mir ziemlich praktisch.
Habe ich direkt angewandt, zumal das Label mit einem anderen Button click wieder verschwinden sollte. da ist visible=>false perfekt.
Kann mir noch jemand was zu der sache mit den nachkommastellen sagen?
=> hat sich erledigt, war nur ein fehler im dateityp.
AmunRa schrieb:
Bei den primitiven Datentypen ist die Verwechslungsgefahr deutlich stärker gegeben, vor allem deshalb weil die meisten primitiven Datentypen in gleiche FCL-Typen abgebildet werden, allerdings einige wenige nicht.
Das ist vollkommen subjektiv, und bezogen auf C# alleine eben einfach nicht wahr (EDIT: bzw. nicht relevant). Darauf wollte ich hinweisen, und du bist aufgeflippt. Kann ich auch nix machen.
Beim Programmieren überall zu berückichtigenm was in anderen Sprachen evtl. anders heissen könnte, ist IMO quatsch, sorry.
der Code implementiert das Anti-Pattern: Expection handling (http://en.wikipedia.org/wiki/Expection_handling)
Begründung: Bei einer Usereingabe ist es eine zu erwartender Zustand das z.B. aufgrund von Fehleingabe der eingegebene Pfad nicht existiert. Eine Exception dagegen sollte unerwartete Zustände behandeln.
Anstelle dessen sollte die Usereingabe auf Korrektheit geprüft werden (Directory.Exists() ) und dann abhängig davon der Programmfluß entweder seine Ausgabe oder eine Fehlermeldung produzieren.
Und ja, goto hat hier auch gar nichts verloren. (Nein, das ist keine goto-is-evil Diskussion, obwohl ich das supporte, sondern einfach die Aussage das bei sauberere Programmführung ein goto überflüssig wäre.
Anstelle von for(;;) würde ich in dem Fall while(true) benutzen.
Variablennamen sind zu kurz. b, a, c, fs... Keine Angst, Code wird nicht langsamer wenn man die Variablen vernünftig bezeichnet. Jedoch wird er auf dauer schwerer zu lesen, wodurch die Chance auf Fehler vergrößert wird.
Hmm, immer Komisch wenn der Code-Review mehr Zeilen hat als der Code to Review...
Wie wär's hiermit: http://books.google.de/books?id=p--ZBLrQMRAC&pg=PA503&lpg=PA503&dq=c%23+shutdown&source=bl&ots=VWpdHlN7nL&sig=5OTAnhscJ9Cnh3TXqoWzx5XC5ZU&hl=de&ei=g4vjSuexGNeN_Aao59CDAg&sa=X&oi=book_result&ct=result&resnum=2&ved=0CAkQ6AEwATgK#v=onepage&q=&f=false
Ich würde mir am Start die schon gespeicherten Datein angucken und die höchste Zahl raussuchen.Mit einer Zufallszahl ist nicht sichergestellt das der Name nicht mehrfach vorkommt.Oder wenigstens eine GUID benutzen.
Hallöle,
Rhombicosidodecahedron schrieb:
Anstatt new Class().GetType nimm typeof(Class) .
Werde ich testen.
Rhombicosidodecahedron schrieb:
Außerdem könntest du bitte den richigen Quelltext veröffendlichen? (Drei Console.WriteLine's ergeben keine 4 Einträge vor '---')
Sry, hatte während dem Posten noch ein
Console.WriteLine( new A().GetType().IsSubclassOf( typeof( A ) ) );
vor den anderen 3 eingefügt, damit es zur foreach()-Schleife paßt.
Rhombicosidodecahedron schrieb:
Sonst kannst du auch Type.IsAssignableFrom versuchen.
Das habe ich schon probiert, das geht auch nicht.
Rhombicosidodecahedron schrieb:
P.S.: Leicht Off-Topic: Schreibst du an einem Reflector?
Jein :D. Ich schreibe eine DataContract-Generator für WCF. Dazu extrahiere ich Infos aus dem Fachlayer per Reflection.
Jo da hast du fast Recht.
Hier ein kleiner Hilfslink
http://www.google.de/#hl=de&source=hp&q=C%23+FileInfo.Attributes&btnG=Google-Suche&meta=&aq=f&oq=C%23+FileInfo.Attributes&fp=12bc3e260a95ecf1
Bin auf den Draht gekommen, dass ich ja einfach mal den Compiler fragen könnte...
Also zu meiner Frage :D:
Die Sichtbarkeit eines Property überträgt sich auf getter und setter. Allerdings darf ich bein einem der beiden die Sichtbarkeit ändern. Dabei muss diese jedoch restriktiver sein als die des Properties.
Sieht man auch gut im .NET-Reflector.
Euer C#-Noob void*
Sorry, war vielleicht etwas konfus.
Also:
Ich will mit T4 einen Generator bauen. Dazu wäre die o.g. Assembly (eine DLL) für mich von Nutzen.
Also habe ich erst mal eine Konsolenanwendung gebastelt, die die benutzt (zum Testen außerhalb eines T4-Projekts). Diese explodiert jetzt aber beim Laden.
Die *.exe, die mit der DLL geliefert wird (FxCop) läuft jedoch.
Auf CodeProject habe ich eine andere *.exe gefunden, die mit der Microsoft.Cci laufen sollte. Die explodiert aber auch, sobald Funktionalität aus der Cci genutzt werden sollte.
Und das englisch-sprachige Zitat bezog sich jetzt auf das Code-Project-Tool (eine *.exe). Und die Frage war jetzt, ob ich dieses Code-Project-Tool neu bauen muss, damit es funzen kann.
Hoffe, dass die Lage jetzt etwas klarer ist...
Auch wenn DataBinding beim DataGridView zu bevorzugen ist, so kann man doch auf die einzelnen Zellen zugreifen:
object value = ...
datagridview.Rows[y].Cells[x].Value = value;
value = datagridview.Rows[y].Cells[x].Value;
Rhombicosidodecahedron schrieb:
Ich hoffe ihr versteht was ich meine
Und ob
das erinnert mich daran, dass heute noch in Jahre 2009 die DLL's und EXE's folgende Zeile beinhalten: "This program cannot be run in DOS mode."
D.h. damals schon wurde an einen Mechanismus gedacht, der es DOS ermoeglicht diese Meldung auszugeben wenn eine Windows-Exe gestartet wurde. Da stuerzt nichts ab, da kommt keine kryptische Fehlermeldung, sondern der sanfte Hinweis, dass das Proggie eben nicht im DOS Modus laeuft.
Was Du suchst bzgl. Dotnet-Exe-Assemblies suche ich auch schon eine lange Zeit, und vergebens.
Eine lesbare Meldung, dass zur erfolgreichen Ausfuehrung der gestarteten Exe-Datei ein Dotnet Framework benoetigt wird, und kein Absturz a la "mscore.dll nicht gefunden" etc. -> da heisst es dann naemlich gleich "was ist denn das fuer ein schei* Programm, das stuerzt ja gleich beim Start ab"
Wieso wurde da eigentlich Exe/DLL beibehalten und keine andere Endungen erdacht fuer Dotnet-Assemblies, um die es sich ja hier handelt? Dann waere das Problem erledigt. Wir werden es nie erfahren, und noch immer gibt es keine Loesung fuer Dein Problem, ich haette auch gerne eine.
