audacia schrieb:
Übrigens kann man viele typische C++-Anwendungsfälle von Mehrfachvererbung in C# mit Interfaces und Extension-Methoden lösen.
Und viele von den übrigbleibenden Fällen kann man mit Mixins abdecken. Wobei C# keine Mixins anbietet - aber das muss ja nicht immer so bleiben.
hustbaer schrieb:
12test schrieb:
Wie kann man das mogelichst einfach/elegant aendern ohne das ganze neu zu schreiben?
Wenn du ein Singleton los werden willst, dann musst du dafür sorgen dass überall - ohne Verwendung der statischen ".Instance" Property - eine Instanz der Klasse zur Verfügung steht. (Also nur wo halt eine benötigt wird, nicht überall, logisch.)
Die einfachste Variante das umzusetzen ist meist den Klassen die das ehemalige Singleton benötigen im Konstuktor eine Instanz der ehemaligen Singleton-Klasse mitzugeben.
Und ganz aussen, z.B. in der "main" Funktion, erzeugst du dann eine einzige Instanz und gibst diese allen weiteren Objekten über ihren Konstruktor mit.
Was dabei Problematisch werden kann sind statische Funktionen in der die ehemalige Singleton Klasse verwendet wird. Die können ja auf keine Membervariablen "ihres" Objekts zugreifen, da sie kein solches Objekt haben. Diese muss man sich dann Fall für Fall angucken, und entscheiden was zu tun ist. Manche statischen Funktionen wird man einfach zu Memberfunktionen "hochstufen" können, anderen wird man die nötige Referenz als zusätzliches Parameter übergeben, und wieder andere wird man vielleicht ganz wo anders hin verlagern.
Danach hast du effektiv immer noch nur eine einzige Instanz, aber dann hast du Code mit dem es möglich sein sollte zwei oder mehr verschiedene Objekte zu erzeugen und zu verwenden. Dafür können dann weitere Änderungen nötig sein, aber der Weg sollte dann klar sein.
Ich würde auf jeden Fall empfehlen das in zwei Schritten zu machen. Also erstmal den Singleton-Getter (die ".Instance" Property) entfernen und mit explizit rumgereichten Referenzen zu ersetzen. Und danach erst den 2. Schritt machen für den es dann nötig ist mehr als 1 Objekt zu erzeugen/verwenden. Sonst verliert man schnell den Überblick.
Danke fuer die Ausfuerliche Antwort! Ich werde so vorgehen und Stueck fuer Stueck alles aendern.
hustbaer schrieb:
Klar kannst du.
UB ist es nur wenn das Objekt selbst const ist.
Wenn dagegen einfach nur ein T const* , auf ein T was selbst gar nicht const ist, übergeben wurde, dann kann man problemlos das const wegcasten und in dem T drinnen rummalen.
Ups, stimmt da hab ich mich zu weit aus dem Fenster gelehnt.^^
Aber man könnte es ja trotzdem anbieten, nur halt den (ohnehin bösen) const_cast weglassen.
Was für eine Forumsoftware ist das?
UA sollte irrelevant sein. Vielleicht weil du vorher überhaupt keinen UA gesendet hast?
EDIT:
Es gibt für Firefox verschiedene addons, die den UA ändern können.
Einfach mal nen UA weg oder leer lassen. Was passiert?
Oder ein tool benutzen, das dir das erlaubt (wäre aber eher der fortgeschrittenen Modus).
mgaeckler schrieb:
EOP schrieb:
Diese Frage stelle bitte an die NSA, die kennen Deinen Quelltext besser ALS wir.
Sei liaba froh dass i ned boarisch schreib.
Man muss ja nicht immer gleich mit dem Schlimmsten drohen.
Zu den buttons:
In der MFC müssen die buttons in der Z-Ordnung hintereinander liegen und du musst eine Gruppe für sie definieren.
Was ja auch Sinn macht. Irgendwie muss das Programm ja z.B. bei 5 buttons wissen, wo die eine Gruppe aufhört und die nächste anfängt.
Kenne mich mit C# aber überhaupt nicht aus und mit WinForms noch viel weniger.
Dann wäre es wohl besser, wenn du einmalig (quasi als Cache) die Tiles als Bitmap lädst (sollten ja nicht so viele sein, max. ein paar Dutzend ;-), evtl. sogar erst bei Bedarf (schreib dir dazu eine Klasse/Methode mit einem Dictionary<string, Bitmap> welche nachschaut ob es die Bitmap mit dem Dateinamen schon gibt, und wenn nicht dann lädt).
Bei deinem bisherigen Ansatz würde ja eine Bitmap x-fach geladen werden (wenn gleiche Tiles benutzt werden).
Ja, das geht genau so einfach. Erstelle einfach eine neue Klasse und leite dann von dem Steuerelement ab:
public class MyTreeView : TreeView
{
}
Nun kannst du dort alle Methoden, Eigenschaften und Ereignisse hinzufügen, die du haben möchtest.
Bei den Ereignissen sollte man dann jedoch einfach die virtuellen On...-Methoden überschreiben (und dadrin dann die base.On...()-Methode aufrufen), anstatt sich an das öffentliche Ereignis zu hängen.
Wenn du diese Klasse (d.h. das zugehörige Projekt) einmal kompiliert hast, dann steht es auch im Forms-Designer zur Verfügung.
Dann kannst du einfach im Form dann dieses neue Steuerelement benutzen.
Bei zusammengesetzen Controls würde man aber besser ein UserControl (Benutzersteuerelement) erstellen (z.B. ein Label mit TextBox und ein Button daneben).
NullBockException schrieb:
Oder hab ich da jetzt nen Denkfehler drine?;)
Ja.
Denk es nochmal durch.
Der Sender hält den Empfänger am Leben. Umgekehrt nicht.
(Mal abgesehen von statischen Membervariablen etc.) Nur ein Objekt das selbst durch irgendwas am Leben gehalten wird kann ein anderes Objekt am Leben halten.
Hallo deine Lösung hab ich schon gesehen im Endefekkt ist sie nicht viel anders als meine mit der Anpassung des Array-Typs nur das du es danach machst.
Und meine Antwort war auf deine Frage nach einer eleganteren Lösung gemünzt :). Und einer kurzen Erklärung worin genau der Fehler bestand.
Mfg Marco
Was soll c:\Documents sein?
Ich kenne c:\Users und c:\Documents and Settings , aber c:\Documents - das klingt nach nem ganz normalen Pfad.
Natürlich sollte auch der nicht hardcoded sein. Aber das ist dann wieder ein anderes Thema.
Dafür gibt es das Startup-Ereignis, s. z.B. Command-line parameters in WPF.
Die im Explorer angeklickte Datei steht dabei im ersten Parameter (vorausgesetzt deine Extension ".xyz" ist mit deiner WPF-Anwendung verknüpft).
Mit
char1_server1.Text = reader[2].ToString();
schreibst (bzw. überschreibst) du ja jeden ausgelesenen Wert in das eine Label.
Wenn du eine Liste anzeigen möchtest, dann nimm am besten gleich ein Listen- bzw. Tabellencontrol (z.B. ListBox, ListView, DataGridView) - und les dich mal in "DataBinding" ein (Stichwort: DataSource).
