Mach das Disposable am besten doch wieder, dann werden Resourcen auch früher freigegeben.
zb wenn du ein Objekt in einem using erstellst, dann wird das Dispose direkt aufgerufen sobald der Scope verlassen wird. Wenn du dich auf den Finalizer verlässt kann die Resource noch eine ganze weile im Speicher rum liegen bis es freigegeben wird da der Garbage Collector nach eigenen ermessen los legt. Resourcen sollten aber freigegeben werden sobald man sie nicht mehr benötigt.
Ich konstruiere mal ein Beispiel, du hast ein "MyReader" Objekt der eine Handle zu einem Bild auf macht.
foreach (var folder in folders)
{
object folderImage = null;
using (var reader = new MyReader("theImage.png")
folderImage = reader.GetImage();
myList.Add(new Folder(folder, folderImage);
}
Stell dir vor das "MyReader" IDisposable nicht implementiert und die Datei "theImage" liest, da kann es passieren das es dir um die Ohren fliegt da der Garbage Collector erst los läuft sobald er es will.
Falls es nicht knallt hast du dann X Handles offen, und kannst dann Probleme bekommen.
Wenn "MyReader" aber IDisposable implementiert, wird es jedes mal aufgeräumt sobald der using Scope verlassen wird, d.h. du hast da immer nur ein handle zur selben Zeit offen und es kommt nicht zu unerwarteten Fehlern wegen nicht aufgeräumten Resourcen.
Man ruft das IDisposable nur als Sicherheit im Finalizer auf, falls das Dispose() vergessen wurde. Also sobald du mit Resourcen Arbeitest die aufgeräumt werden müssen, solltest du das IDisposable implementieren.
//Dazu
Aber microsoft/msdn betont immer wieder, dass destruktoren schlecht für die performance sind. so ganz kann ich das nicht nachvollziehen
Microsoft sagt "Implementing Finalize methods or destructors can have a negative impact on performance" - also es kann aber muss nicht.
Es wird damit begründet das der Garbage Cllector das Objekt dann zwei mal ansteuert, einmal um den Finalizer auf zu rufen und dann nochmal um es aus dem Speicher zu schmeißen. Das kann Performance Probleme geben wenn du sehr viele solcher Objekt hast.
Ich dachte an irgendwie sowas:
interface IConverter<T>
{
T FromText(string text);
string ToText<T>(T obj);
}
public class IntegerConverter : IConverter<int>
{
public int FromText(string text) { ... }
public string ToText(int obj) { ... }
}
Hab es grad hier im Forum getippt aber nicht getestet ob es überhaupt baut.
Aber jetzt wo ich es seh merk ich auch das man es so nicht in ein Dictionary bekommt - vermutlich hatte ich es aus dem selben Grund auch damals nicht gemacht ^^
Dravere schrieb:
man könnte auch statt der ListView ein DataGrid nehmen. Oder man erweitert ListView um DataSource . Gibt dazu auch ein paar Einträge im Internet.
Ich denke in zukünftigen Projekten werde ich wohl Abstand vom ListView nehmen - das DataGrid schein mir generell etwas mächtiger zu sein.
danke, .NetPhysiker
Dravere schrieb:
Ich sage es immer wieder, lest die verdammte Dokumentation
http://msdn.microsoft.com/en-us/library/system.io.streamreader.readline.aspx
MSDN schrieb:
Remarks
A line is defined as a sequence of characters followed by a line feed ("\n"), a carriage return ("\r"), or a carriage return immediately followed by a line feed ("\r\n"). The string that is returned does not contain the terminating carriage return or line feed. The returned value is null if the end of the input stream is reached.
Grüssli
Na, da hab ich wohl zu schnell die Doku gelesen. Hatte mir doch gedacht, dass es komisch ist, dass das nicht in der Doku steht...
Danke!
Achjeh, das ist eine dieser lustigen "params" Funktionen.
Wo er dann hergeht und ein leeres Array übergibt wenn man sie ohne Parameter aufruft. Was bei der speziellen Funktion natürlich so richtig Sinn macht. Wäre vielleicht auch besser sie hätten da ne Möglichkeit geschaffen anzugeben, dass mindestens ein Objekt erwartet wird.
Ca. 3 sek. Google Suche ergab diese ersten beiden Treffer:
http://www.c-sharpcorner.com/UploadFile/dsandor/ActiveXInNet11102005040748AM/ActiveXInNet.aspx
http://www.codeproject.com/KB/cs/CreateActiveXDotNet.aspx
Und, damit es nicht so schwer für den Anfang für Dich ist, hier: http://lmgtfy.com/?q=active+x+c%23.net
Gut Schuß
VuuRWerK
Wow, da bin ich mal ne Woche win Paar Tage im Urlaub und dann stehe ich vor Romanen an Hilfestellung. Scheinbar hat es sich schonmal gelohnt, dass ich mich nochmal mit den Grundlagen befasst habe. Bei den Klassen sieht man ja immernoch Verbesserungsbedarf, aber ich dachte mal, dass ich die Kenntnisse versuche selber anzuwenden, was ja nicht so schlecht war.
Eingegangen bin ich auf deine Vorschläge, lieber David W, weil du offensichtlich der Fachmann bist und weshalb sollte ich mein Programm nicht auch dementsprechend aktualisieren. Alleine die Gestaltung der Tierunterklassen ist viel übersichtlicher und vom Programmcode kürzer, was beim Scrollen hilft;)
Außerdem konnte ich die Fehler nunmehr arg reduzieren.
Ich muss nun mal alles versuchen anzupassen und zu tüfteln und hoffe, dass ich dadurch nun viel weiter komme. Ich melde mich, wenn es noch irgendow speziell im Verständnis hakt;)
Groupboxen, Bilder und Transparenz ... das ist sehr übel.
Ich würde erstmal die Transparenz deaktivieren und das Bild beim ersten laden der Anwendung zerstückeln. Jede Groupbox bekommt dann den passenden Ausschnitt als Backgroundimage zugewiesen.
Damit solltest die Anwendung wenigstens benutzbar werden.
Oder noch besser: Verzichte auf dieses nervtötende Hintergrundbild und wähle einen dezenten Farbverlauf.
Dann wähl doch deine Namensräume so wie MS. Packe das zusammen was zum System gehört usw. Kannst es auch in UI und Core aufteilen. Also Möglichkeiten sind da viele
Jo ... ich hatte halt immer wieder das Problem, dass das VS2010 die Verzeichnis-Einträge so abgeändert hatte das absolute Pfadangaben verwendet wurden, sobald das Projekt bearbeitet wurde. Dies war halt störend, da unterschiedliche Entwickler ihre Dll's (3rd party software) unterschiedlich installiert hatten. Sobald nun einer das Projekt bearbeitet hatte und dies in die Versionsverwaltung einbrachte konnte ansonsten kein Anderer mehr die Projekte/Solutions kompilieren.
Da ich ansonsten aus dem VC Bereich komme war dieses Problem so für mich unbekannt und habe daher nachgefragt. Da Umgebungvariablen in VC Projekten anscheinend noch immer nicht in absoulute Pfadangaben expandiert werden, stand ich hier erst vor einem Problem. Da ich dann dachte ... ich kann vlt. anderen Leuten helfen, die das gleiche Problem haben, habe ich einen kleinen Link zu einer MS Seite gepostet.
/Closed
Du schreibst die Embedded HTML temporär auf Platte und öffnest sie dann
So werde ich das machen, es ist die praktikabelste Lösung...
Dankeschön für die Informationen...
Oder man schaut sich einfach kurz die Dokumentation zu beiden Steuerelementen an. Zum Beispiel die Dokumentation von RichTextBox hat unten bei "See also" einen Link auf diese beiden Themen:
TextBox Overview
RichTextBox Overview
In beiden Themen gibt es als erstes Unterthema "TextBox or RichTextBox?", wo die Unterschiede aufgelistet werden.
So einfach ist das Leben mit der MSDN. Man muss diese Dokumentation nur nutzen
Grüssli
