Hehe da haben sie es sich relativ einfach gemacht.
Wie folgt sieht die neue Funktion aus:
public StringBuilder Clear()
{
this.Length = 0;
return this;
}
Also wie erwartet.
hustbaer schrieb:
Du kannst dir ein eigenes Attribut implementieren, und das hängst du dann an alle abgeleiteten Klassen dran.
Darin kannst du die Daten hinterlegen die die Manager/Factory Klasse braucht um zu wissen was sie machen soll.
ähnlich wie hier - http://x8bit.de/index.php?option=com_content&view=article&id=70&Itemid=79&lang=de
Und was das EventArgs Beispiel angeht...
Einen Anfänger hätte es hier vermutlich auch nicht gerettet, wenn er auf Optimierungen verzichtet hätte, denn der IMO naivste Weg sowas zu machen ist:
class Foo
{
void MyThread()
{
while (...)
{
// do some stuff, modify m_list and/or the objects referenced in it
do_some_stuff();
something.BeginInvoke(new SomeDelegate(Target), new SomeEventArgs(m_list));
}
}
List<Stuff> m_list;
}
class SomeEventArgs
{
public SomeEventArgs(List<Stuff> list)
{
List = list; // just referencing the list, no copy!
}
public List<Stuff> List;
}
Das fliegt dir dann genauso um die Ohren.
Damit es nicht knallt, muss man die Liste kopieren, und u.U. sogar die darin referenzierten Objekte.
Das Erstellen des Delegate kann man dagegen problemlos in den ctor verlagen, denn den Delegate ändert man ja nicht mehr (kann man auch gar nicht, da .NET Delegates genauso wie .NET Strings immutable sind).
BTW: du meinst vermutlich Control.BeginInvoke. Control.Invoke ist synchron
Vor dem selben Problem stand ich auch mal. Was in meinen Augen ein Problem darstellen könnte ist folgendes: Die SystemsEvents Klasse hat ein Event das heißt
EventsThreadShutdown. Diese Event beendet den Thread der auf alle Events lauscht. Es kann sein das dieses Event VOR den anderen beiden Events fliegt, somit kann man auf die gar nicht mehr reagieren, aber das ist nur eine Theorie, ausprobiert habe ich das nicht, jedoch kann ich mir das aufgrund des Verhaltens gut vorstellen.
Achso daran habe ich jetzt gar nicht gedacht:D
Grundsätzlich gilt, wenn du in einem Thread ein Control erzeugst kann auch nur in diesem Thread damit gearbeitet werden. An deiner Stelle würde ich die Listview über den UI Thread erzeugen lassen und das anzeigen deiner Progressbar über einen anderen Thread machen, über BeginInvoke kannst du dann der GUI kurz zwischendurch immer nochmal eine Anzeige rüberschieben sozusagen.
Was haltet ihr denn von folgender Lösung, ich geh mal davon aus das die Matrikelnummer eindeutig ist.
var student = MyArrayList.ToList().Where(s => s.Matrikelnummer.Equals(matrikelnummer,StringComparison.InvariantCulturIgnoreCase).FirstOrDefault();
//wenn also einer gefunden wurde
if(student != null)
MyArrayList.Remove(student);
Ja, der Operator ^ funktioniert nur für einfache Datentypen (nicht für Arrays).
Aber kannst ja selber daraus eine Funktion basteln, falls du diese Operation öfter benötigst:
byte[] Xor(byte[] a, byte[] b)
{
int nLen = Math.Min(a.Length, b.Length) // kleinere Länge ermitteln
byte[] c = new byte[nLen];
for (int i = 0; i < nLen; i++)
c[i] = a[i] ^ b[i];
return c;
}
Alternativ bei unterschiedlicher Länge beider Arrays dann mit Nullen auffüllen...
P.S: Für die Klasse BitArray gibt es die Xor-Methode
(ich nehme jedoch an, daß du den Xor-Operator für die Verschlüsselung benutzt, oder?)
Diesel schrieb:
Kann ich von einer Klasse, die in einer anderen Klasse deklariert und implementiert ist auf die Felder/Funktionen der "Parent" Klasse zugreifen?
Nur in dem man ihr eine entsprechende Referenz auf den "Parent" mitgibt.
Auch mit Timeout etc. und mit true als rückgabe kein gültiger fensterhandel.. ich hab mir überlegt die WinApi Variante CreateProcess zu verwenden, was meint ihr? Oder sonst welche tipps?
dcssssss schrieb:
Na ja, gut. Aber das Exception-Zeugs brauche ich dann noch immer. Und das ist sehr nervig, wenn man so viele Funktionen hat, die auch dieses Zeugs brauchen...
Dafür hat der liebe MSDN die Dokumentation erfunden...
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(TopLevelErrorHandler);
Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException);
Zentraler gehts nimmer.
Siehe auch: Anti Pattern "Expection handling" als Beispiel dafür wie man es nicht machen sollte.
(Expection Handling anstelle von Exception handling, das ist kein Tippfehler)
