Ich kann den Grundgedanken schon verstehen, daß man nur lesend auf ein Objekt von außen zugreifen möchte, und der schreibende Zugriff nur von einer bestimmten Klasse aus erlaubt sein soll.
Deswegen wünsche ich mir für C# auch ein "const" für Methoden (bzw. automatisch für Getter-Properties).
Für Collections z.B. wurde dafür extra eine ReadOnlyCollection geschaffen.
Ausweg bleibt daher wie beschrieben nur über Vererbung oder Interfaces (d.h. Mehraufwand beim Schreiben der Klassen).
Darf man den namen des Spieles wissen? Dass was du machen möchtest, würde man am leichtesten auf einem "nicht erlaubten" weg schaffen.
http://www.codeproject.com/KB/cpp/codecave.aspx
Ein beispiel für Pinball, mit einem Codecave könntest du die Chat-Nachricht an dein Programm weiterleiten, dass müsste man dann natürlich in C++ erstellen(dll) und dann in dein C# projekt benutzen. Falls du kein ASM kannst, dann wird es wahrscheinlich sehr schwer.
nicht wenn man ne statische methode uebergibt {o;
table.Sort(ByBetrag);
.
.
.
private static int ByBetrag(TableEntry lhv, TableEntry rhv)
{
return lhv.Betrag.CompareTo(rhv.Betrag);
}
der vorteil dieser methode ist das man es leichter anpassen kann wonach sortiert werden soll - wenn das IComparable[<T>] implementiert wird ist es fest
creation_2 schrieb:
genau c ... hab da probleme damit 0_o
dann bist du im falschen forum - in diesem schreiben nur schwachsinnige - also ich und leute die sind wie ich #gg
Geloest
Zunaechst Danke fuer Eure Tips.
Kurze Problembeschreibung:
eine C# Anwendung fuer .NET V3.5 kann auf x64 basierten Windows Betriebssystemen nicht auf Datenbanken von SQL Server Compact 3.5 zugreifen. Grund: SQL Server Compact 3.5 gibt's nur fuer x86 Systeme.
Loesung:
SQL Server Compact 3.5 SP1 fuer x64 installieren, zu finden hier:
http://blogs.msdn.com/stevelasker/archive/2008/08/07/sql-server-compact-3-5-sp1-released.aspx
Erst im zweiten Anlauf via versch. Suchmaschinen hab ich dieses Blog eines Compact Entwicklers entdeckt. Wird dieses SP1 nachtraeglich installiert, dann klappts jetzt auch mit der C# Anwendung auf x64 Windows Betriebssystemen.
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.
