loks schrieb:
Ebensowenig diskriminieren wir schließlich Leute die Sarkasmus nicht verstehen.
Dein "Hey" und der Smiley haben mir schon gezeigt, dass das Sarkasmus war, jedoch fande ich dein Thread etwas zu schonend formuliert
CStoll schrieb:
Das könntest du auch als Default-belegten Parameter in deiner C#-Funktion festlegen.
Lieber nicht. Der Default-Parameter wird fest in den Code eingebaut, der die Funktion aufruft. Das führt zu unschnen Ereignissen, wenn man den Wert des Default-Parameters ändert, aber den aufrufenden Code nicht neu gegenkompiliert
2AndAHalfBit schrieb:
das dein Beispiel funktioniert, ist unkritisch. Aber was wäre, wenn ich ein Array von deinem Enum habe? Bei der ausgabe des zweiten Arrayelements würde das auch noch passen? Ich habs nun nicht ausprobiert, also glaub ichs dir erstmal.
Enum ist in C# standardmässig Int32 . Falls du einen anderen Typen willst, dann musst du dies angeben.
http://msdn.microsoft.com/en-us/library/sbbt4032.aspx
2AndAHalfBit schrieb:
Eine Enum orientiert sich ja an dem größtmöglichen Wert, ...
In C# nicht.
Grüssli
Hallo,
mal eine Frage: Warum speicherst du dir die Daten nicht in einer Settingsklasse? Die wird von MS schon frei Haus gereitgestellt und ist im Projekt konfigurierbar.
grüße
Ich habe den Text vorher schon gelesen, folgendes ging nicht:
... Form-Konstruktor ...
Graphics g = CreateGraphics();
Cursor.DrawStretched(g, new Rectangle(10, 10, 30, 30));
...
Da erschien links oben tatsächlig der verkleinerte Cursor, dieser rührte sich
aber nicht, dafür war der alte noch da, und wurde nicht durch den neuen ersetzt.
Häufig ist Komposition der bessere Weg als Vererbung. Dann hat die neue Klasse ein Objekt der alten Klasse als Feld und delegiert die Anfragen.
Aber, bei GUI-Controls zieht man häufig doch Vererbung vor, wenn die Funktionalität erweitert werden soll. Das ist i.d.R. praktikabler und wäre in deinem Fall die richtige Vorgehensweise. Vorausgesetzt natürlich, die Button-Klasse lässt sich erweitern.
Und wir sind dazu verpflichtet dir ein schnelles WE zu organisieren, nur weil du zu Faul bist selbst dein Kopf anzustrengen? Der wichtigste Schritt um ein guter Programmierer zu werden ist Eigeninitiative und Kopf-Anschalten!
2AndAHalfBit schrieb:
ich schlage vor, wir beruhigen uns nun alle mal wieder ein bisschen. Ich finde es nicht schlecht, das David versucht zu helfen. Wie er schon sagte, kommt er aus der WPF-Ecke, genau wie ich.
Es versucht ja nicht zu helfen, sondern trollt nur rum!
2AndAHalfBit schrieb:
Ich verstehe eh nicht, warum man sich noch mit WinForms beschäftigt, aber ist ein freies Land.
Gibt tausend Gründe, wieso dies der Fall sein könnte, aber das ist auch völlig egal. Er will Hilfe zu WinForms, also gibt man ihm auch entsprechende Hilfe.
Und jetzt bitte nur noch Beiträge zum Thema! Alles weitere wird kommentarlos gelöscht oder rauseditiert.
Grüssli
ghostwhisperer schrieb:
Hab ich das richtig gerechnet? Wär dat mehr als doppelt so schnell??
Ja und z.B. für nen 10x10 Filter wärs schon 5x so schnell. "Nur linear statt zweidimensional" macht eben doch einen riesen Unterschied
Hi,
nur mal ein paar Gedanken. Schau Dir mal MEF an (ist ab .net 4 Bestandteil desselben unter System.ComponentModel.Composition). War zuerst als plugin-Framework gedacht und wird jetzt von einigen MVVM-Frameworks als IOC-Container genutzt. Möglicherweise kannst Du damit zwei Fliegen mit einer Klappe erschlagen. Ich könnte mir beispielsweise in der App vorstellen das kundenspezifische Erweiterungen als zusätzliche Assemblies bei dem spezifischen Kunden mit installiert werden und das MEF diese dann im App-Startup lädt und in seinem Katalog oder als Service Locator zur Verfügung stellt.
Das Entity Framework arbeitet mit Konfigurationsfiles (mal von Code-First-Development abgesehen). Diese Konfigurationen (edmx-File) werden ind das Assembly eingebettet und während der Ausführung geladen und die Mapping-Anweisungen entsprechend interpretiert. Eine Möglichkeit besteht nun darin diese als freie Dateien der Installation beizulegen. Du könntest also für jeden Kunden eine spezifische EDM-Konfiguration hinterlegen, dann müssten die unterschiedlichen/erweiterten DB-Schemata kein Problem sein. Natürlich muß das ausgelieferte Repository (im Extra-Assembly) zum ausgelieferten Schema passen.
Ein zusammengesetztes Fenster/GUI sollte in MVVM kein Problem sein, ich empfehle bei komplexeren Szenarien dann die zusätzliche Verwendung von Controller/Presenter die das Zusammensetzen der ViewModels zu baumartigen Strukturen und deren Aktualisierungen etc steuern (MVVMP). Ein solcher Controller kann dann wissen welche Models gebunden wurden und diese dann z.B. zu speichern sind. (wenns ganz kompliziert wird kannste ja auf Kompositum und Visitor zurückgreifen :-). Ein solcher Controller bzw das zu verwendende Repository kann dann auch die DB-Transaktion steuern.
Hallo Alexander,
du mußt immer alles im Paint-Event (bzw. in der OnPaint-Methode) zeichnen.
Nicht nur beim Vergrößern eines Fensters sondern z.B. auch beim Minimieren/Wiederherstellen als auch beim Ändern des Z-Index (anderes Fenster wird über dein Fenster gesetzt und dann z.B. wieder minimiert) wird das Fenster (teilweise, d.h. evtl. per Clipping) neu gezeichnet.
Wenn die Erstellung des Koordinatensystems aufwändig ist, dann benutze dafür ein Image (Bitmap) als Zwischenpuffer und zeichne es dann im Paint-Event mittels e.Graphics.DrawImage(image) bevor du dann die einzelnen Punkte zeichnest.
Und wenn sich die Punkte (besonders, wenn es viele, d.h. z.B. mehr als 1000 sind) auch nicht so oft ändern, so kannst du diese auch in diesem (oder einem zweiten) Image zwischenspeichern.
Ungetestet:
XNamespace Namespace = "http://schemas.microsoft.com/developer/msbuild/2003";
var itemGroups = XDocument.Load(...).Element(Namespace + "Project").Element(Namespace + "ItemGroup");
var elements = itemGroups.Where(group => group.Elements(Namespace + "EmbeddedResource").Any() || !group.HasElements);
Der Code liefert dir alle ItemGroup-Elemente die "EmbeddedResource"-Elemente enthalten oder leer sind. Wenn keines von beidem vorhanden ist muss man eine neue ItemGroup erzeugen und einhängen, zum Beispiel so:
XElement newItemGroup = new XElement(Namespace + "ItemGroup");
itemGroups.Last().AddAfterSelf(newItemGroup);
Ein neues Element erzeugt man z.B. so:
newItemGroup.Add(new XElement(Namespace + "EmbeddedResource",
new XElement(Namespace + "DependentUpon", filePath),
new XAttribute("Include", includePath)));
Was hier natürlich komplett fehlt ist Fehlerbehandlung. Wenn im ersten Codefragment, beispielsweise, irgendein Element nicht vorhanden sein sollte gibt es eine NullReferenceException etc.
Darunter versteht man, wenn ich es richtig verstehe, wenn man ein Projekt - mehr oder weniger automatisiert - von einer Sprache/Plattform auf eine andere Sprache/Plattform portiert.
Wobei das Original dann normalerweise nicht weiter gepflegt oder weiterentwickelt wird.
Wann man portieren und wenn migrieren sagt, also wo da die Unterschiede sind erschliesst sich mir auch nicht ganz. Anhand davon wie "migrate" gebraucht wird würde ich sagen "migrate" sagt man eher bei In-House Projekten die nicht verkauft werden, sondern lediglich für eine Firma irgendwo installiert sind (möglicherweise auf mehreren PCs/Servern).
Kann man ein VB Projekt zu einem C Sharp Projekt migrieren ?
Es gibt "Konverter" die VB .Net Code in C# Code übersetzen. Wobei ich keine gratis Lösung kenne die gut funktioniert. (Ob die kommerziellen besser sind weiss ich nicht, gehe aber stark davon aus.)
Bedeutet Migration auch implizit Upgrade ?
Äh. Hä?
Ich sag mal so: du hast dann eine neue Version deiner Applikation. Wenn dabei etwas besser geworden ist, dann ist es ein "Upgrade".
Wenn du allerdings nur die Programmiersprache gewechselt hast, sich für den Anwender aber (noch) keine Verbesserung ergibt, dann ist es kein "Upgrade". Oder Höchstens ein "Upgrade" für das Entwicklungsteam, weil die dann z.B. mit neueren/besseren Tools etc. arbeiten können.
Naja, du kannst es ausprobieren oder ausrechen, wenn du willst sogar zur Laufzeit. WinForms sind allerdings für solche Anwendungen nicht so geeignet. Dazu eignet sich WPF deutlich besser.
Grüssli