er meint folgendes

class test
{
  int i;

  public void something()
  {
    if (i == 0) {}  // kein kompilerfehler

    int j;
    if (j == 0) {} // kompilerfehler
  }
}

sieht interessant aus und ganz anders als mein ansatz - ich verwend für mein aktuelles hobbyprojekt auch einen eigenen settings manager und nicht das vom Framework 2.0. werd ich demnächst mal hierher (oder neben diesen thread) posten.

nicht probiert, könnte aber hinhaun:

Process.Start("about:blank");

edit: ausprobiert, haut hin.

edit: doch nicht... ich sollte mal lernen die vorposts genau zu lesen 🙁 bei mir entspricht das allerdings der startseite...

Danke,
ich habe die Bilder mal in das JPEG Format umgewandelt

Ich glaub wenn du es dann in den Resourcen als Image hinzufügst, wirds erst recht wieder als Bitmap gespeichert - nur eben mit der schlechteren Qualität.

Statt dessen leg die Image dateien in ein Verzeichnis im Projekt und setz bei den Properties die "Build Action" auf "Embedded Resource" (ka wie das auf deutsch heisst). Dann wird das auch ins Programm kompiliert, aber bleibt ein jpg. Allerdings musst du es dann mit Assembly.GetManifestResourceStream() laden.

Ich habe viele Maps in einer List und diese haben ein eindeutige ID.

Da fällt mir grad auf, dass in genau so einem Fall ein Derivat von KeyedCollection<> die bessere Wahl wäre. Angenommen, dieser eindeutige Key der Map wäre ein Guid im Property "UniqeId":

class MapCollection : KeyedCollection<Guid, Map>
{
  protected override Guid GetKeyForItem(Map item)
  {
    return item.UniqueId;
  }
}

und diese Collection verwendest du dann.

Vorteil gegenüber dem Dictionary: ...Add(Map item) anstatt ...Add(Guid key, Map item).

Hallo DNAofDeath,

klingt so als wäre HashMap in C# Dictionary.

herbivore

Ist auch so (dafür reichen meine Java-Kenntnisse grade noch).

Allerdings heissen ein paar Methoden des Dictionary mit Sicherheit auch anders als von der HashMap

Dictionary<> ist gut. Wenn die Eigenschaft nach der du suchen willst, sich aber unterschiedlich sein kann (einmal Nachname, einmal Vorname), könntest du unterschiedliche Dictionaries mit jeweils verwenden, was aber zu inkonsistenzen führen kann, wenn man nicht gut aufpasst. Ich würde da eher zu List.Find greifen.

Wenns dann immer noch um Performance geht schreib dir eine eigene Collection die intern mehrere Dictionaries hält und sich um die Konsistenz kümmert. Diese kann dann entsprechende Methoden anbieten.

4. Wenn man einer TimeSpan mit 3 Jahren definieren könnte, wielang ist diese dann in Tagen? Um das zu bestimmen bräuchte man zumindest ein Anfangsdatum... daher wurde es wohl weggelassen.

Schau dir mal das an, vieleicht brauchst du das Rad dann nicht neu erfinden: C# Script

Aber vielleicht kannst du die Windows Einstellung auslesen, mit wieviel Dpi dargestellt wird (als Benutzer unter Systemsteuerung/Anzeige -> Tab "Einstellungen" -> Erweitert Tab "Allgemein")

Mit Hilfe der Dpi und der Bildschirmgröße in Pixel kannst du die Grösse dann ausrechnen.

Allerdings kann der Benutzer da auch was anderes einstellen und dann stimmts nicht mehr.

Eine TreeNode ist ein Blatt, wenn this.Nodes.Count == 0

per default ist das Shift-Alt-F10

Vielleicht liegt es daran, dass ich die BETA-Version von Visual Studio 2008 nutze.

Die Beta 1 war tatsächlich noch sehr langsam. Die Beta 2 entspricht aber in der Performance schon ziemlich oder sogar ganz der endgültigen 2008.

Und das erstmalige erstellen des DataContext dauert auch ziemlich lang, bei allen weiteren geht das blitzartigst.

Ich möchte von einer Textbox eine Zeitdauer einlesen im Format...

Dann ist DateTime wahrscheinlich eher zweite Wahl. Erste Wahl wäre TimeSpan, weil das tatsächlich eine Zeitdauer repräsentiert (und keinen Zeitpunkt) und ebenfalls eine TryParse Methode besitzt.

Control.IsKeyLocked(...)

danke, die hätt ich auch schon mal gebraucht und habs dann aber über Rectangles gelöst (was halt nicht so genau ist).

ich glaub es gibt auf object eine protected Methode die MemberwiseClone() heisst. Die könnte das übernehmen. Wenn deine Klasse allerdings Referenzen enthält, wird die Referenz kopiert und nicht das Objekt auf das sie zeigt.

Als großen Nachteil sehe ich leider im .NET die String-Klasse an. Ist zwar eine Klasse (Verweis-Typ), wird aber ständig bei jeder Operation und Zuweisung kopiert und der Speicherverbrauch je nach Anwendungsfall vervielfacht

also bei zuweisungen wird nur die referenz kopiert, genauso wie bei parameter übergabe.
und wenn das mal wirklich stört, kann man immer noch die StringBuilder Klasse verwenden. Die beiden ergänzen sich sehr gut, und sind auch in Java nicht viel anders implementiert (ausgenommen der dort nicht überladbaren operatoren)

@0815Coder: Ein Namespace sollte mindestens 5 ehr über 9 Klassen enthalten. Des weiteren sollte ein Namespace eine eingenständige Einheit sein, was heißen würde, dass die Komponente (aus der die Innnereklasse kommt) mit in den neuen Namespace müsste.

Richtig. Sollte. 😁

Der Namespace kann ja noch andere IComparer enthalten (um bei deinem Beispiel zu bleiben), so könnten es zB mehr werden.

Ausserdem kann man einen Unter-namespace auch als Namensraum verstehen, der Erweiterungen zum Übergeordneten enthält, die aber in 80% der Fälle nicht verwendet werden müssen, und das Intellisense schonen. In den 20% wo man erweiterte Funktionalität braucht kann man den dann immer noch einbinden.

(
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reuseable .net Libraries kann ich sehr empfehlen, habs noch nicht ganz durch)

edit: quote fixed.

1. Kann man mit Ihnen die "Fasade" eines Namensraumes verbessern. Wenn man z.B. IComparer für seine eigene Komponente speziell implementiert, muss man
   [...]
   C) die Klasse in der Komponente einbetten. So wird der Namensraum intern und extern "sauber" und die Klasse bleibt bei Bedarf verfügbar.

würde ich eher mit 1D) lösen:
die Klasse in einen weiteren, tieferen Namensraum einbetten, ausgenommen dein Punkt 2 oder 3 trifft zu.

wenns aber am resharper liegt, müsstest du trotzdem kompilieren und ausführen können, und die resharper meldung einfach ignorieren.

du müsstest sagen:

X m = new A();

dann gehts implizit:

m = y;

Was geschiet mit den Sektoren, wo sich kein Spieler aufhält, jedoch KI's und sich bewegende Objekte vorhanden sind?

Gegenfrage:
Was ist, wenn im Wald ein Baum umfällt und keiner ist da, der den Krach hören kann?

Ist in meinen Augen keine gute Idee von MS gewesen, Dispose(bool) im Designer-Code zu verstecken.

Vom Standpunkt sauberen Programmierens müsste man jede Bitmap, jedes Dataset disposen, wenn ein Form schließt, aber durch dieses Verstecken wird das meist vergessen (und macht ja auch nix, weil das Form ist dann ja weg).
Und im override Dispose(bool) habich die Kontrolle, ob meine Objekte vor den Form-Komponenten freigegeben werden, oder danach.
Das Event _Disposed() kommt immer danach.

Stimmt, die Idee, das Dispose(bool) ins designer.cs zu stecken war bescheuert.

Dennoch kanns kein Problem sein das im Event_Disposed() zu machen. Das heisst ja nur das alles andere schon disposed ist, aber deshalb hast du auf deine statische Liste immer noch zugriff und kannst selber disposen was da drinn ist. Effektiv ist Dispose() dann ja noch nicht fertig, weil es ja OnDisposed() aufgerufen hat und somit auf den Abschluss deiner Event_Disposed() wartet.

vielleicht gibts aber auch eine Möglichkeit, die Größe zu errechnen oder wenns reicht zu schätzen (niemand interessiert sich für +/-3 Byte bei >1k)... das wäre sicher performanter.

Schreib in einen MemoryStream und schau wie groß der ist. Der sollte dein "virtueller Filestream" sein.

Ich würde die Dispose() in der .designer.cs lassen, statt dessen den Disposed Event abonnieren, und dort den Rest disposen.

so wie du es machst, bist du beim BeginInvoke() noch im GUI Thread, dort bringts daher nichts.

Du musst einen neuen Thread starten, dort GetData() ausführen und dann die foreach in ein dataGridView2.BeginInvoke() packen. Wobei dort dann auch Invoke() reicht, weil danach ja nichts mehr ausgeführt wird.

versuchs mal mit

if (ReferenceEquals(other,null))

statt dem ==

wenn ich es umschreibe wie

  
for(int i=0;i<stlist.Size;i++){  
 if(stlist[i].equals("c")) stlist.remove(i);  
}  
  

Dann funktioniert es.

nein tuts nicht.

was ist, wenn du zwei "c" direkt hintereinander hast?
dir for() macht dann nach dem Remove ein i++ und hat somit das zweite "c" übersprungen, weil das zweite "c" durch den Remove() im index um eins nach vorn gerutscht ist.

Das ist auch der Grund warums in der foreach() nicht zugelassen ist.

Funktioniert auch bei uns nur teilweise:

• Checkout (prevent other users from blabla).
• ausserhalb vom Studio ändern
• Checkin

Studio meckert kurz ("da hat sich nichts geändert"), und zeigt die Datei dann als eingecheckt...

Vorallem wenn man über die Datei über den Windows Explorer eine neue Datei(-version) drüberkopiert, kennt das das TFS nicht.

Warum der BinaryFormatter so viel schneller ist, weiss ich nicht. ein Mitgrund ist sicher, dass bei einem Xml File die Tags meistens mehr Speicher brauchen als die Daten selbst.

Der BinaryFormatter schreibt die Daten ziemlich speichersparend raus.

Ausserdem solltest du das [NonSerialized] auf alles draufmachen, was du gar nicht schreiben willst (vielleicht wirds dann sogar noch etwas schneller).

Die Unterschiede in der Zeitmessung sind recht klein, und kommen vom Windows Multitasking, GarbageCollection und haben noch zig andere Ursachen.

bis zu 3x schneller gegenüber XmlSerializer
Mehr nicht??? Ich hätte da mindestens gedacht, da fehlt noch eine 0.

Der Xml Serializer ist ziemlich schnell. Beim Erstellen generiert er ein Assembly (über CSharpCodeProvider), das direkt auf die Properties der zu serialisierenden Objekte zugreift (daher gehn auch nur public), also nicht über Reflection. Das erstmalige Erstellen dauert wegen dem Compilieren noch recht lang, alle weiteren Male wird eine gecachte Version verwendet (obacht: nicht bei allen Construktoren).

LINQ verwendet doch intern auch ADO, also wie soll das schneller sein?

Viel einfacher wäre es, mit dem BinaryFormatter, deine Objekte einfach in den Stream zu serialisieren. Dann kannst du sie auch wieder genauso simpel deserialisieren. Das sind dann grad mal ein paar Codezeilen fürs De-/Serialisieren (inklusive Stream Erzeugung), sowie das [Serializable] Attribut auf den zu speichernden Klassen (sowie ggf ein [NonSerialized] auf den Properties/Fields die nicht gespeichert werden sollen.

Beim XmlSerializer ist mir grundsätzlich aufgefallen, dass der im Vergleich zu selbergeschriebenen (IXmlSerializable implementierenden) Code sehr schnell ist, vorallem was Deserialisierung betrifft - wahrscheinlich weil er sich den eigentlichen Serializer auf die Klassen zugeschnitten kompiliert.

BinaryFormatter ist auch sauschnell, ich habs aber nicht gemessen oder mit XmlSerializer verglichen.

Wahrscheinlich ist der langsamere Teil eher das Laden, weil man dauernd prüfen muss, was kommt und obs zusammen passt. Das muss man beim Speichern nicht.

Wenn eins der Properties des DatenObjekts, dass in den Value des Dictionary ist, selbst der Key ist, dann kannst du statt Dictionary<TKey,TValue> eine KeyedCollection<TKey,TValue> verwenden, diese lässt sich problemlos mit XmlSerializer verwenden.

Für den Verlust an Performance gewinnst du die Objektorientierung und Compilezeitsicherheit.

Nach meiner Theorie gilt die Regel "Was an Kraft gewonnen wird, geht an Weg verloren" und umgekehrt - aus der Physik (Hebelgschichten) auch in der Informatik.

rechne doch intern mit der genauigkeit von double. zurück auf float kommst du immer wieder.

mach ganz am anfang

if (ReferenceEquals(this, _other))
  return 0;

dann müssts gehen.

Grund: .net prüft auch ob deine Methode ordentlich funktioniert. Das tut sie nicht, wenn sie für das gleiche objekt 1 oder -1 zurückgibt, sprich wenn:

Abschnitt a;
a.CompareTo(a)

nicht 0 ergibt, was es muss, weil die natürlich gleich sind. Das stellst du mit dem oberen Code sicher.

Es gehört einfach zur grauen Theorie...

Wir haben im Chemieunterricht (langlangistsher) ja bei der Einführung auch ganz kurz veraltete/antike Atommodelle durchgenommen, auch wenns nie zu Prüfungen kam.

Oder in Physik wird auch angesprochen wie die Leute vor einer Weile dachten, dass Licht sich ausbreitet (Äther (Physik))

Struktogramme gehören irgendwie in die "Geschichte der Informatik"

Ich glaub, dass es im Unterricht Sinn macht, Struktogramme zu durchzunehmen, damit man auch ein Gefühl für Abstraktion bekommt, das kann manchen die sich mitInformatik schwerer tun sicher auch helfen. Allerdings sollte man damit auch nicht mehr als ein paar Stunden über einen gewissen Zeitraum verteilt verschwenden, da sie so veraltet sind, dass es staubt.

Hab mich grade mit einem arbeitskollegen unterhalten.

man kann instanzmethoden auch ohne instanz aufrufen. zwar nicht über c# aber über IL code direkt... intern werden instanzmethoden so aufgerufen wie die extensionmethods aus c#3.0 also in etwa Call(this, parameter).

so gesehen macht die abfrage in einer derart grundlegenden klasse sinn.

hallo herbivore,

du meinst, mit "before this" dass eine NullReference geworfen wird? dann müsste mein beispiel aber so aussehen:

string a = "bla";
string b = null;
if (b.Equals(a)) ...

ich frag mich auch wie in einer instanzmethode das keyword "this" jemals null liefern könnte.

public bool Equals(String value) {  
            if (value == null)  
            {  
                // exception will be thrown later for null this   
                if (this != null) return false;  
            }   
   
            return EqualsHelper(this, value);  
        }   

o.k wann kann this == null sein!

so:

string a = "bla";
string b = null;
if (a.Equals(b)) ...

edit: verlesen sorry... ich beantworte wieder mal nicht die frage X(

Ja, VS generiert im MyControl.designer.cs bereits einen override für Dispose().

Ist die Testversion möglicherweise eine Team Edition und du hast nur einen Productkey für die Professional gekauft? Dann wirst du die Testversion deinstallieren müssen und die richtige installieren.

Das ist grundsätzlich ok, nur kann der Benutzer dann immer nur ein Form offenhaben, welches mit ShowDialog arbeitet (was ja auch gewünscht sein kann).

Wenn es möglich sein soll, dass er mehrere Forms öffnen kann und in allen gleichzeitig Daten ändern, musst du irgendwo die Events der erzeugten Form abonnieren, ggf. auch eigene Events definieren und auslösen.

Wenn du weisst, in welchem Assembly und in welchem Namespace die Klasse definiert ist, kannst du das einfach zusammenstecken:

Angenommen der namespace wäre "Das.Ist.Mein.NameSpace" und das Assembly heisst "Mein.Assembly", dann ist der AssemblyQualifiedName

"Das.Ist.Mein.NameSpace." + classname + ", Mein.Assembly"

wenn du nicht mit [assembly: log4net.Config.XmlConfigurator(Watch = true)] konfigurierst, musst du irgendwo einmalig aufrufen:

XmlConfigurator.Configure(true); // oder so ähnlich

übrigens, bei

p => p.Value as object

kannst du dir das "as object" sparen, da alles ein object ist.