Insgesamt sollte man dieses unsägliche ToString nur benutzen, wenn es wirklich nicht anders geht.

vollkommen richtig, ich hab mich hier nur auf das zusammenhängen konzentriert.

edit:
appendformat ist zwar wesentlich besser lesbar aber auch langsamer als das alles mit + aneinander zuhängen und dann einmal zu appenden (string.format ist nicht besonders performant).

ich schreibs im normalfall auch so, aber speziell hier gehts ja um die performance vom strings zusammenfügen.

performanter ist

html.Append( "<tr><td>" + data["Titel"] + "</td><td>" + data["Autor"] + "</td>" + "<td>" + data["Kategorie"] + "</td><td>" + data["Serie"] + "</td><td>" + datas["Name"] + "</td><td>" + datas["Klasse"] + "</td><td>" + data["Ausleihe"] + "</td><td>");

variablen vor der ersten anweisung zu deklarieren macht in c# keinen sinn. die idee, es so zu machen ist wahrscheinlich noch von pascal inspiriert, dort war das noch pflicht.

spontan fällt mir noch was auf:

Convert.ToDateTime(data["Frist"].ToString()) < DateTime.Today

ist in data["Frist"] nicht ohnehin schon ein DateTime drinn? In dem Fall wäre doch
((DateTime)data.Frist) < DateTime.Today besser undn schneller als mit dem Umweg über string.

Das würd ich eher so optimieren:
1.

StringBuilder html = new StringBuilder()

und dann mit deinem Code (ungetested, ich zitier hier nur):

                    html.Append( "<tr><td>" + data["Titel"].ToString() + "</td><td>" + data["Autor"].ToString() + "</td>" + "<td>" + data["Kategorie"].ToString() + "</td><td>" + data["Serie"].ToString() + "</td><td>" + datas["Name"].ToString() + "</td><td>" + datas["Klasse"].ToString() + "</td><td>" + data["Ausleihe"].ToString() + "</td><td>");
                    if (Convert.ToDateTime(data["Frist"].ToString()) < DateTime.Today && data["Schüler"].ToString() != "0")
                        html.Append( "<font color=\"red\">" + data["Frist"].ToString() + "</font></td></tr>");
                    else
                        html.Append(data["Frist"].ToString() + "</td></tr>");

die table row wird dann praktisch auf einen rutsch zusammengefügt und in einem weiteren angehängt (bis auf den if-teil)

Möglicherweise hast du aber auch in den Queries zur Db noch einiges an Optimierungspotential wie meine Vorposter schon schreiben.

Eine Einschränkung hat das Ganze... VB.NET ist nicht case-sensitive, d.h. eine Methode TEST() und test() können nicht unterschieden werden. Beim Erstellen von VB.NET Code mag das irrelevant sein, versuchst du jedoch eine Assembly einzubinden, die in C# kompiliert wurde und eben genau diese beiden Test() Methoden mitbringt, so kannst du diese nicht in VB.NET aufrufen (keine von beiden).

mit dem Attribute
[assembly: CLSCompliant(true)]
kann man zumindest in eigenen C# assemblies sicherstellen, dass es auch von VB aus verwendbar ist.

den redgate profiler haben wir auch eine weile verwendet.

die tatsächlich angezeigten zeiten der methoden sind beim messen aber um ein vielfaches länger als in der tatsächlichen ausführung - allerdings stimmen sie ziemlich gut, wenn man sie im verhältnis zu anderen betrachtet. dadurch kann man relevanten stellen mit schwacher performance trotzdem gut identifizieren.

structs als key sind durchaus ok, aber:

überschreib unbedingt .Equals() und GetHashCode(), damit du noch ordentliche Performance hast. Die Standard-Implementation dieser zwei arbeitet für structs massiv mit Reflection um an die Member zu kommen und diese zu vergleichen, bzw aus den membern einen hashcode zu errechnen.

@kleines_eichhörnchen:
Kombinationen aus mehreren HashCodes der unterelemente macht man besser mit ^ (XOR) statt mir OR... sonst kommt dir ein hash von 0xFFFFFFFF sehr schnell vor, 0x00000000 aber praktisch nie. dem Fall:

override GetHashCode(){
  return Name.GetHashCode ^ Month ^ Year;
}

vorher natürlich noch Name auf null prüfen. Month und Year kann man ausserdem direkt ein-x-odern, weil GetHashCode für int der int selber ist, also nochmal etwas zeit gespart.

du wirst dir die PropertyInfo möglicherweise über typeof(IConnectable<>) holen müssen, nicht über typeof(Memento)...

zu 1. es wird vermutlich der (automatisch generierte) Konstruktor MyClass (SerializationInfo si, StreamingContext context) verwendet.

Ich muss herbi ausnahmsweise widersprechen.

Dieser Konstruktor wird nicht automatisch generiert, daher auch nicht aufgerufen.

Tatsächlich ruft der BinaryFormatter keinen Konstruktor auf, die Instanzierung des Objekts erfolgt über System.Runtime.Serialization.FormatterServices.GetUninitializedObject() oder die GetSafeUninitializedObject() (welche der 2 weiss ich grad nicht), wobei kein Konstruktor aufgerufen wird, daher auch keine felder initialisiert werden (auch keine die direkt per "private int i = 1" initialisiert werden;

Dieser Konstruktor wird nur aufgerufen, wenn ISerializable implementiert ist (und der Konstruktor vorhanden ist)...

BinaryFormatter
ISerializable

edit: deutsche Sprache, schwere Sprache

= null (deallokieren mit GC) wenn man nicht mal weiss wann man sie wieder benötigt.

null setzen bringt nur was, wenn die variable die auf die liste zeigt selber noch länger verfügbar sein wird, also static ist oder in einer instanz einer anderen klasse, welche noch verwendet wird.

{
  List<...> x = new List<...>();
  ...
  x = null; // brauch ich nicht mehr.
}

Das die Liste in diesem Fall nicht mehr gebraucht wird, sieht nicht nur der GC sondern auch der Compiler und optimiert das im Release-build beinhart weg (kann sein dass das erst der JIT Compiler wegoptimiert, da bin ich grad nicht sicher).

Auch ein List.Clear() würde in dem Fall nichts zusätzlich bringen, da der GC auch sieht, dass die Items nicht mehr verwendet werden, wenn die Liste nicht mehr verwendet wird. Wenn sichs um WertTypen (zB int, DateTime) handelt, gibt es ohnehin nur den List-internen DateTime[] der aufgeräumt werden muss, einzelne DateTime instanzen die der GC einzeln aufräumen muss gibts dann nicht.

Das ist auch ein Grund, warum es performanter ist, List<DateTime> zu verwenden als ArrayList. Bei der ArrayList oder List<object> würden die DateTime objekte in eine Referenz verpackt (boxed) und einzeln aufgeräumt werden müssen.

protected void OnSetBoundsCore() müsste machen was du willst.

in 99.9% aller fälle ists doch egal ob ein string = null oder string.Empty ist. Fakt ist: es ist nichts drinn. Daher prüfe ich ausschließlich mit string.IsNullOrEmpty(). Somit reicht auch die initialisierung auf null.

Bei Methoden die einen string zurückgeben gebe ich aber immer zumindest string.Empty zurück, damit es wie norman_timo schon sagt nicht kracht wenn wer die Länge abfragt.

ich würde byte[] deshalb bevorzugen, weil wenn ein Zustand serialisiert wurde, ist der serialisierte Zustand fix. Ein Stream hat für mich was dynamisches, in das immer wieder geschrieben/gelesen wird. Ansichtssache, Stack<Stream> müsste genauso gehen.

Wenn du die Zustände nicht allel gleichzeitig im Ram halten willst weil sie zuviel Speicher brauchen, könntest du pro Zustand eine Datei verwenden, müsstest dich aber um die Verwaltung selber kümmern.

Zwar könntest du auch den Stack selber inklusive Zuständen serialisieren, aber das ist insofern kontraproduktiv, als dann wieder alle im Ram wären.

Nimm einen Stack<byte[]>

Dann kannst du einen Zustand per MemoryStream serialisieren und dessen Bytes in dem Stack abspeichern. Du hast dann also einen Byte[] pro Zustand.

Um das ganze aber relativ performant zu schreiben, erst den Hashcode der strings Vergleichen. Ist dieser gleich nochmal die Equals-Methode drüber jagen.

Ein Vergleich zweier Ints ist performanter als ein Vergleich zweier unterschiedlich langer Strings.

GetHashCode für System.String wird bei jedem Aufruf berechnet und muss natürlich den gesamten String einbeziehen. Dadurch ist das alles andere als nur ein Vergleich von 2 ints, da diese erst berechnet werden müssen. Wenn mans mit Reflector anschaut sieht man gewisse Ähnlichkeiten, zB dass beide Methoden den String in 4er Blocks abarbeiten (also zB 4 bytes in ein int casten und das vergleichen).

Ein kurzer Test hat bei 2 Strings gleicher länge, bei denen sich nur das letzte Zeichen unterscheidet, ergeben, dass 2x GetHashCode 3-4x so lang dauert wie das.Equals() bzw operator==. Die Strings sind dabei ca 1000 Zeichen lang gewesen. Bei 100 Zeichen war der Unterschied ca 10%, aber 2x GetHashCode war immer noch langsamer als der Vergleich.

Zugegebenermassen sind Vergleiche mit CompareTo() aber wesentlich langsamer als erst die GetHashCode() aufzurufen, wahrscheinlich weil die Culture miteinbezogen wird.

ich hab jetzt die zweite hälfte der posts nicht gelesen g aber, ich hab erst letzte Woche sowas gemacht.

Ich hab dabei von UserControl geerbt, aber ScrollableControl dürfte auch reichen.

1. durch AutoScrollMinSize setzen kannst du die Höhe festlegen die dein Control innen "tatsächlich" groß ist.

2. im OnPaint und bei MouseEvents musst du AutoScrollPosition beachten und addieren (oder subtrahieren, weiss jetz nicht genau)
   2a. in OnPaint würde ich die graphics.TranslateTransform() vorschlagen, dann kann der Rest gleich bleiben.

3. fast fertig: wenn man am Control ein BackGroundImage verwendet, wird dieses nicht mitgescrollt, das muss man dann selber in OnPaint() zeichnen - oder was ich jetzt nicht probiert hab in OnPaintBackground()...

Die Properties HScroll, VScroll, HorizontalScroll, VerticalScroll, braucht man dann nicht mehr anfassen.

Danke, die Lösung gefällt mir auch wesentlich besser.

wens noch interessiert:

    [Designer(typeof(MyDesigner))]
    public class MyEditor : UserControl
    {
        // mein zeugs...
    }

    public class MyDesigner : ControlDesigner
    {
        protected override void PreFilterProperties(System.Collections.IDictionary properties)
        {
            base.PreFilterProperties(properties);
            
            if (properties.Contains("AutoScrollMinSize"))
                properties.Remove("AutoScrollMinSize");
            
            if (properties.Contains("AutoScroll"))
                properties.Remove("AutoScroll");
        }
    }

abgesehen davon muss noch System.Design.dll referenziert werden.

eben, aber den eigenen Designer schau ich mir mal an.

Hallo,

ich hab eine abgeleitete Klasse (im speziellen Fall von UserControl), in welcher ich ein Property (im speziellen Fall AutoScrollMinSize) im Designer verstecken will [Browseable(false)].

Leider ist das Property nicht virtuell, daher kann ich nicht überschreiben und die Attribute einfach draufsetzen.

Was ich probiert hab ist folgendes

        [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
        [Browsable(false)]
        public new Size AutoScrollMinSize
        {
            get
            {
                return base.AutoScrollMinSize;
            }
            set
            {
                base.AutoScrollMinSize = value;
            }
        }

Das führt zu dem gewünschten Ergebnis, dass das Property aus dem Designer verschwindet (und auch kein InitCode im Form.Designer.cs erzeugt wird).

Dadurch, dass ich direkt auf die originale Version von AutoScrollMinSize weiterleite sollte es auch keine weiteren Probleme geben (?)

Ich bin ansich gegen Verwendung von "new" zum überschreiben, aber, das hier könnte ich mir als gerechtfertigten Fall vorstellen - hat jemand eine bessere Idee, oder haltet ihr die Vorgehensweise für ok?

robocopy von microsoft (google mal danach) is auch gratis, und kann glaub ich auch synchronisieren

ich habe festgestellt, das WoW ein ähnliches suchtmuster wie zigaretten hat. interessanterweise gehen die raucherzahlen bei der jugend stark zurück, jedoch die spielsuchtzahlen steigen stark an.

Die Summe aller Laster ist konstant...

[XmlRootAttribute("commission")]
public class Commission
{
  [XmlElement("commissionTotal")]
  public int CommissionTotal;
}

// irgendwo im code (achtung, hier gehören noch einige Dispose() dazu:
string filename = ...
{
  XmlSerializer ser = new XmlSerializer(typeof(Commission));
  XmlReader input = XmlReader.Create(filename); // glaub ich

  Commission comm = (Commission)ser.Deserialize(input);
  Console.WriteLine(comm.CommissionTotal)
}

Achtung: In der Commission Klasse unbedingt alles public, sonst gehts nicht.

Die anderen Werte kannst du ähnlich auslesen, für die Listen schau die XmlArrayAttribute und XmlArrayItemAttribute an.

Nur für den einen Wert ist der XmlSerializer die Kanone für den Spatz, aber trotzdem weniger Code als du geschrieben hast 🙂

Von MS gibts da sogar eine Art Pattern

besser so:

class XYZ
{
  public event MyEventHandler MyEvent;

  protected virtual void OnMyEvent(MyEventArgs e)
  {
    MyEventHandler handler = this.MyEvent;
    if(handler!=null)
      handler(this,e??MyEventArgs.Empty);
  }
}

sonst kanns durch Multithreading passieren, dass direkt nach dem if() der andere thread sein (letztes) abo am event beendet und MyEvent somit null wird.

Oder Microsoft.VisualBasic.dll referenzieren und die eigene Application von WindowsFormsApplicationBase ableiten. Diese beherrscht auch Splash-Screens.

@0815Coder:
Meine Liste ist doch extra typisiert, dann müsste man doch auch den Typ herausbekommen, oder?

ja. aber maximal bekommst du den Type == typeof(GeometrischeForm), und wenn noch so viele Dreiecke drinn sind.

@0815Coder:
Wenn die Liste doch ursprünglich als

List<Dreieck> eineListe;  

definiert wurde, dann müsste man eben diesen Dreiecks-Typ doch herausbekommen, evtl. sogar wenn sie noch leer wäre, oder?

ja, dann bekommst du typeof(Dreieck), genauso wie du bei der List<GeometrischeForm> eben typeof(GeometrischeForm) bekommst.

abgesehen davon könntest du den Typ nicht rausfinden, wenn die Liste leer ist...

Wenn du List<object> hast wird dir keine Reflection der Welt sagen können, welchen Typs die enthaltenen Elemente sind. Da könnten ja Personen, Äpfel und ints gemischt drinn sein. Wenns geht, mach das <object> bereits als Typparameter, dann sparst du dir die Abfrage komplett.

das + kennzeichnet die nested class.

die <>c__DisplayClass1 ist vom compiler generiert (ja, das <> gehört dazu) und dient in diesem fall wahrscheinlich einem Enumerator, weil du ein yield return verwendet hast. Die kann aber auch für closures verwendet werden (bei anonymen delegates)

hui, das sieht interessant aus. Mit WinProc funzts zwar einwandfrei, aber das schaut doch noch besser aus.

danke das reicht mir, ich hab ein Fenster.

edit:

Falls das noch wer brauchen kann:

 protected override void WndProc(ref Message m)
        {
            base.WndProc(ref m);

            if (m.Msg == WM_DISPLAYCHANGE)
            {
                uint lParam = (uint)m.LParam;
                int width = (int)lParam & 0xffff;
                int height = (int)lParam >> 16;
            }
        }

aber vorsicht: Screen.Primary.Bounds... wird erst updated, wenn die überschriebene WndProc zurückkehrt, da nützt auch das base.WndProc vor dem Rest nichts.

Hallo,

gibts auch eine Möglichkeit mitzubekommen wenn sich die Auflösung ändert (zB als Event)?

Wenn schon nicht in .net, dann vielleicht wenigstens Win32...

witzig 🙂
meine findet den WinForms Teil besser lesbar (ich auch).

1. Ist dies mit net 3.5 immer noch so, dass unter WPF die fonts sch... aussehen sprich total verschwommen mit farbigen pixeln aussenrum oder wurde der Bug behoben?

Ist immer noch so und "by Design". Microsoft nennts Antialiasing (oder ClearType), ich nenns Augenkrebsauslöser.

Also selbst wenn du die "new" aus den Quellcodes verbannen kannst, kannst du dennoch nicht verhindern, dass bei

string s1 = "bla";
string s2 = s1+s1;

von der String-Klasse ein (mehrere) new() gemacht wird (werden).

Das Problem, dass die zwei wsdl unterschiedlich sind, ist in der Praxis wahrscheinlich keines. Es geht doch eher darum ob man mit einem C# Client auf einen Java-Webservice bzw. mit einem Java-Client auf einen C#-Webservice zugreifen kann.

Wenn beides funktioniert, ists doch egal, wenn die beiden Webservices unterschiedliche wsdl erzeugen...

@chavez:

besser: von Collection<int> ableiten und InsertItem() überschreiben, dann brauchts kein new dafür.

Methode2 kann einen Event auslösen der in Klasse2 implementiert ist. An diesen Event kann sich ein Eventhandler von Gui hängen und seinerseits einen Event aus dem Gui auslösen.

&lt; und &gt; sind nicht nur html-spezifisch...

wenn es wirklich html nimmt müsste es mit <p>mein absatz</p> funktionieren.

das <para> wird zumindest im studio richtig angezeigt

so zB:

/// <summary>
/// <para>
/// test 
/// </para>
/// <para>
/// test 2</para>
/// </summary>

Die Klasse ist partial, damit man sie selber erweitern kann ohne überschreiben zu müssen. Es gibt keinen "anderen" Teil ausser du schreibst selber einen.

Die Frage ist, ob sowas überhaupt config ist, oder ob das Definitionen sind, die von einem Editor erstellt werden und mit einer Player gespielt werden können. In dem Fall würd ich das nicht über Config machen sondern als eigene Dateien, die vom Editor geladen, bearbeitet und gespeichert werden, und vom Player nur geladen werden.

Für sowas eignet sich dann am Besten ein Objektmodell das die Daten strukturiert abbildet und der XmlSerializer oder BinaryFormatter zum Lesen/Schreiben.

Die Klasse hat einen kleinen Bug, teilweise werden überzählige Zeichen von vorigen Icons angezeigt, weil '\0' "nur" replaced wird.

Fix:

iconName = iconName.Replace("\0", "");

ersetzen durch

 iconName = iconName.Substring(0, iconName.IndexOf('\0'));

Activator.CreateInstance(string)

Mach ein Singleton und den Indexer darauf. Wobei das dann den Namen "Singleton" wahrscheinlich nicht mehr verdient - aber nach dem Prinzip mein ich.

das funktioniert aber nur wenn sich die objekte nach dem instanieren nicht ändern, sonst muss man jedesmal wenn ein property sich ändert den string anpassen, was auch änderungen verlangsamt.

P.S. Man kann den Warm-/Cold-Boot auch per Tastatur ansteuern, was aber für den Anwender zu kompliziert wird. Die Tasten hierfür wären:
Cold-Boot: Steuerkreuz + ESC + Power
Warm-Boot: ESC + Power

Versuch diese mal mit SendKeys.Send() zu simulieren... vielleicht hilft das.

Folgendes ist etwas aufwändig aber mit sicherheit performanter:

1. Properties wie gehabt durchlaufen
2. Code zur Laufzeit erzeugen der die Properties vergleicht und den kompilieren.
3. Das erzeugte Assembly cachen, damit es nicht mehrfach kompiliert werden muss.

Stichwort dazu: CSharpCodeProvider

Das ist eine ähnliche Vorgehensweise die auch der XmlSerializer verwendet, und nach dem ersten Aufruf ziemlich schnell.

Alternativ könnt ich mir folgenden Hack vorstellen, aber vielleicht funktioniert das auch nicht (bzw könnte noch langsamer sein als Reflection):
Beide objekte per BinaryFormatter in einen MemoryStream reinserialisieren, und das stream.ToArray() result miteinander vergleichen. Theoretisch müssten beide gleich sein. Da wird dann zwar mehr verglichen, aber byteweise... (wahrscheinlich ist das langsamer als deine Reflection Methode)

üblicherweise wird per convention object sender als "this" mitgegeben, also dem objekt, das den event auslöst. Das sollte man auch nicht ändern, wenn man nicht einen triftigen grund hat. Wenn du das machst könntest du den Event eben so auslösen:

  OnMyEvent(System.Reflection.MethodBase.GetCurrentMethod(), someeventargs);

Ich glaub aber du willst für Debugging Zwecke eher ein Logging einbauen mit dem das besser nachzuvollziehen ist.

(Abgesehen davon wird das in der Release auch nicht 100%ig funktionieren, wenn die Methode vom JITCompiler inlined wurde.)

wie schon geschrieben aber eher ein Fall für Eventargs

Ich könnte mir vorstellen, dass man den Code dazu verwenden kann, alle aktuellen Positionen zu speichern und auf anforderung des Benutzers wiederherzustellen (wenn Windows nach einem Auflösungswechsel alle Positionen nach links oben verschoben hat).

Was mich am fasziniert sind Kunden die von .NET nichts aber von Access alles halten...