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
icarus2 schrieb:
Aber gerade bei hoher Parallelität sollte aus meiner Sicht die Performance besser sein
Gerade bei hoher Parallelität wird Deine Implementierung problematisch werden. Nehmen wir mal zur Vereinfachung an wir haben genau einen Prozessor-Core und wir reden von 50 Threads die gleichzeitig versuchen eine Node einzuhängen.
In diesem Scenario wird es genau einen Thread geben der den Enqueue sofort schafft, für alle anderen wird (zwangsläufig) deine erste if-Bedingung false sein und diese durchlaufen eine weitere Runde der while(true).
Im zweiten Durchlauf schafft es dann ein zweiter Thread sein Enqueue zu machen, alle übrigen 48 Threads durchlaufen ein weiteres mal while(true)
Strickt man dieses Muster weiter folgt daraus:
Abhängig von der Laufzeit von Node.Next() und der Anzahl gleichzeitig laufender Enqueue() wird sich die Rechenlast auf der Machine erhöhen da Du ein aktive-wait implementiert hast.
Durch die if-Bedingung in der while(true) hast du eine Serialisierung geschaffen, weil immer nur genau ein Thread gleichzeitig diese Bedingung erfüllen kann. damit greift Amdahl's Law (Performancegewinn durch Parallelisierung wird durch den Seriellen Anteil des Systems bestimmt)
Hier ist die Überlegung ob ein Monitor-Ansatz schneller ist also durchaus gerechtfertigt, weil die Abwägen mußt: 49 Threads die aktiv Pollen gegen 49 Threads die im Wait-Status sind, also keine Rechenzeit kosten bis sie durch MOnitor geweckt werden. Dabei darft Du nicht ausser Acht lassen das aktives Pollen ja auch zu entsprechend vielen Kontext-Switches führt, was für sich allein betrachtet zu einem Performance-Problem ausarten kann.
icarus2 schrieb:
Ich habe gerade etwas weitergelesen im Buch "The Art of Multiprocessor Programming" und habe festgestellt, dass dort genau die gleiche Implementierung für eine lockfreie Queue drin ist. Die Sprace ist halt einfach Java. Von daher müsste die Implementierung korrekt sein.
Das heisst nichts. Es gibt auch schlechte Beispiele, falsche Aussagen und fehlerhafte Bücher
Hallo,
ich möchte über das PDF-Com-Object den Pdf-Reader automatisieren, das Control kann eingebunden werden(UserControl), und pdfs anzeigen funktioniert auch. Jetzt möchte ich allerdings über das Interface AcroPDTextSelect die aktuelle Seite mit GetPage() abfragen, jedoch wird bei der Erzeugung mit
var page = new AcroPDTextSelect(); eine COM-Exception geschmissen: Die COM-Klassenfactory für die Komponente mit CLSID {F2366405-A204-405B-A116-FCE5C748E13B} konnte aufgrund des folgenden Fehlers nicht abgerufen werden: 80040154 Klasse nicht registriert (Ausnahme von HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)). Verweise sind auf alle DLLs im Reader Ordner gesetzt. Habe auch schon versucht alle DLLs mit regsvr32 zu registrieren(Als Admin), jdoch ist dies nicht möglich. Übrigens System ist Win7. Mein Quelltext an dem der Fehler passiert:
Acrobat.AcroPDPage page = new Acrobat.AcroPDPage();
MessageBox.Show(page.GetNumber().ToString());
//page = new AcroPDTextSelect();
this.axAcroPDF1.gotoNextPage();
//page.GetPage();
Ich hoffe jemand kann mir bei meinem Problem helfen.
Mit freundlcihen Grüßen
Anon
Das wird meistens gemacht, wenn es sich um eine Klasse handelt die über mehrere Dateien verteilt ist (Schlüsselwort partial ). Die Designer für Forms und WPF nutzen das z.B. Es gibt allerdings keinen mir bekannten Weg direkt über Visual Studio die Gruppierung zu erreichen. Die einzige Möglichkeit die ich kenne ist über das Editieren der Projektdatei.
Nebenbei... Alle Klassen, auch eigene, leiten von Object ab. Also ist das Equivalient zu einer void* Liste von C++ eine List<Object> in C#. Mit dem Unterschied das vei void* sämtliche Typinformationen verloren gehen, bei Object nicht.
Installiere mal das .Net Framework 3.5 SP1!
Visual Studio 2010 umfasst nur .NET Framework 4. Um frühere Versionen von .NET Framework als Ziel festzulegen, muss .NET Framework 3.5 Service Pack 1 (SP1) installiert sein. .NET Framework 3.5 SP1 schließt .NET Framework 2.0, .NET Framework 3.0 und .NET Framework 3.5 SP1 ein. Wenn Sie .NET Framework 3.5 SP1 installieren möchten, können Sie es unter Microsoft .NET Framework 3.5 Service Pack 1 (möglicherweise in englischer Sprache) auf der Microsoft Download Center-Website herunterladen.
(Quelle: http://msdn.microsoft.com/de-de/library/bb398197.aspx)
