Oder das ganze als Cursor: WPF - The Ghost Cursor.

Bezüglich dem Einsatz von Triggern / Storyboards kannst du mal in Richtung "Behaviors" Ausschau halten bzw. selber eins schreiben.

Ähm - wir reden hier doch von Wpf, und da würde ich jedenfalls es sehr sehr gerne vermeiden, die überaus umfangreiche System.Windows.Forms - Dll einbinden zu müssen - nur um 2 oder 3 Rechteck-Informationen abrufen zu können.

Naja - meist braucht man dann noch einen DateTimePicker und die Application Klasse und man kommt um eine Refernz nicht herum. 😉
Das reine Einbinden sollte ja auch nicht mit allzugroßen Nachteilen verbunden sein.

Hallo mygil,

ich würde das gleiche Format verwenden, das letztlich auch von der Hauptanwendung verwendet wird.
Also XML, wenn das die Hauptanwendung auch einsetzt, ansonsten eine relationale DB, ...

Siehe (für fertige Komponenten) auch 2 Datenbanken synchron halten sowie Datensynchronisation verteilter Anwendungen

wenn ich allerdings eine Klasse von Button ableite, und dafür das Template erstelle, dann taucht besagtes Problem auf.

Dann leite einfach keine Klasse von Button ab 😁

Klappt es denn bei Ableitung von ButtonBase oder CustomControl?

Poste am besten mal ein kleines (aber vollständiges) Mini-Beispiel.

Hallo omega90,

so ganz habe ich deine Frage nicht verstanden.

Willst du zwischen einem Dienst und einer Konsolenanwendung kommunizieren?

Dazu gibt es viele verschiedene Möglichkeiten:*Remoting (schon recht lange im Framework - siehe z.B. [FAQ] mehrere Programminstanzen verhindern (inkl. Parameterübergabe) ) *WCF (spielt seine Stärken vor allem in uneinheitlichen Umfeldern aus) *ASP.NET Web-API (vor allem geeignet, wenn auch ein Webbrowser Client sein soll)

Oder meinst du was ganz anderes?

Wenn ich aber auf einem Pixel komme, der dem ContentPresenter "gehört", dann gilt für das UserControl.IsMouseOver=false.

Eigentlich gerade nicht; bei IsMouseDirectlyOver ist dies höchstens der Fall (sicher, dass du nicht gegen das gebunden hast?).

Kleines Beispiel, das bei mir funktioniert, wie es soll:

<Button Content="Foo">
    <Button.Template>
        <ControlTemplate TargetType="Button">
            <Border x:Name="_border" Margin="20" BorderThickness="10" BorderBrush="Black">
                <ContentPresenter HorizontalAlignment="Center" VerticalAlignment="Center" TextBlock.FontSize="90" />
            </Border>
                    
            <ControlTemplate.Triggers>
                <Trigger Property="IsMouseOver" Value="True">
                    <Setter Property="Background" Value="Red" TargetName="_border" />
                </Trigger>
            </ControlTemplate.Triggers>
        </ControlTemplate>
    </Button.Template>
</Button>

Hallo Hellfire76,

Aber warum verhält die eine Software sich so und die andere genau anders ?

ein Schuss ins Blaue: Die eine Anwendung legt die DB selber an, bei der anderen wird diese vom Installer installiert?
Im ersteren Fall sollte ein Kompatibilitätsfeature von Windows greifen, die sogenannte "Windows redirection" bzw. Virtualization, sodass die DB letztlich doch User-Spezifisch abgelegt wird.

Aber IMHO sollte in diesem Fall gelten: Nicht wundern, warum etwas mal nicht und mal doch funktioniert, wenn man es falsch macht, sondern es besser gleich richtig machen und die DB ins Benutzerverzeichnis (öffentlich oder des aktuellen Benutzers) legen 😉

Hallo Quaneu,

ich sehe ehrlich gesagt das Problem nicht so genau:
Du packst x Objekte in eine Collection und der User wählt eins davon aus. Dieses Item ist dann das SelectedItem.
Mit welchen anderen Items dieses dann evtl. noch "übereinstimmt" (d.h. Equals true liefert), ist in diesem Falle doch recht egal; über das Binding wird das ausgewählte geschrieben.

Anders sieht es höchstens aus, wenn du im Code das Item setzt: Da kann dann - mit fehlerhafter Implementierung von Equals der Fall auftreten, dass nicht eindeutig bestimmbar ist, welches Item nun tatsächlich von der Combobox ausgewählt wird.

In diesem Fall hilft (wie eigentlich immer in der WPF 😉 ) das MVVM-Pattern weiter:
Binde nicht direkt die Model-Klassen (auf die du ja keinen Einfluss zu haben scheinst) an das View, sondern schiebe ein ViewModel dazwischen.
Dann greift wieder die standardmäßige (d.h. Objektbezogene) Equals-Implementierung für die ViewModels und du hast keinerlei Probleme mehr.

Hallo coga,

klassischer Fall für ein Interface.

Hallo

meinst du so etwas: Is there a simple “virtual file” class for .NET (c# if source is available)?
Damit stünden dir sogar die Möglichkeiten des "echten" Explorer zur Verfügung und selbst andere Programme könnten transparent via Pfad auf die Daten zugreifen.

Grundsätzlich stimme ich dir ja auch zu.

Unterlässt man das, macht man sich möglicherweise eines - mit Bußgeld oder gar Strafe bewehrten - Datenschutzverstoßes schuldig.

Daher auch mein Hinweis in den Klammern; so etwas sollte man nicht zu leichtfertig ohne vorherige Konsultierung eines Rechtsexperten implementieren - insbesondere, wenn auch Daten wie Computername, IP oder Domain mitgeschickt werden.

Das automatische Deaktivieren einer bestehenden oder das automatische Verweigern einer weiteren Installation ist aus meiner Sicht völlig unakzeptabel

Das sehe ich jedoch leicht anders: Sobald bekannt ist, dass ein Key "in falsche Hände" geraten ist, spricht meiner Meinung nach nichts gegen eine (manuelle) Sperrung via Blacklist im Installer der nächsten Version.
Dann schlägt lediglich das Update fehl - der zahlende Kunde kann weiterhin die (funktionierende) Vorversion nutzen und auf seine Daten zugreifen.

Allerdings stellt sich ein Lizenzschlüssel im Allgemeinen "nicht von selbst ins Netz" - dass somit auch der zahlende Kunde einen gewissen Aufwand hat, wenn er nicht auf seinen Key aufpasst bzw. diesen sogar bewusst weitergibt, halte ich nicht für einen Nachteil.

Personen, die eine gecrackte Version der Software einsetzen, also eine Version, in der die Prüfung ausgebaut ist oder umgangen wird, stehen dann besser da als zahlende Kunden.

Naja - letztlich ist mit jedem Crack auch ein gewisses Sicherheitsrisiko verbunden (man was nie, was da sonst noch mit drin steckt...); somit dürfte (insbesondere im Geschäftskundenumfeld die Hemmschwelle recht hoch liegen).
Bei dem "klassischen" Softwarekey (ca. 10-stellige Buchstaben-/Zahlenkombination ohne Aktivierung und Blacklisting) liegt diese Hemmschwelle deutlich niedriger; Seiten, auf denen man hunderte Keys für alle mögliche Software findet, gibt's wie Sand am Meer. Und das Risiko, sich durch den Einsatz eines illegalen Keys (z.B. in Verbindung mit Trial-Software von der offiziellen Herstellerseite) Malware einzufangen, geht faktisch gegen null.

Ohne Aktiverungszwang bzw. Statistik über aktivierte Keys bekommt man unter Umständen nicht einmal mit, wenn ein Key auf diese Weise geleakt ist oder gar Kriminelle selbt-generierte Softwareschlüssel für die eigene Software verkaufen.

Wenn man jedoch sieht, dass plötzlich Keys aktiviert werden, die nie verkauft wurden oder eine Einzelplatzlizenz mehrere hundert Male aktiviert wurde, kann man den Key dann immerhin noch auf die Blacklist setzen und im kulantesten Fall dem ursprünglichen Käufer gleich per Mail einen neuen, gültigen Key schicken (mit dem Hinweis, dass der alte geleakt ist).

Klar - es darf nicht sein, dass (wie zunehmend in der Computerspieleindustrie) zahlende Kunden schlechter gestellt werden als nicht zahlende (z.B. durch ständigen Onlinezwang nur zu Lizenzprüfungszwecken; Installation von Spyware-Ähnlichen Überwachungstools, ...).
Aber nur auf die Ehrlichkeit der Menschen kann man IMHO auch nicht vertrauen...

Ich schließe mich herbivore an:
Nimm "normale" (d.h. nicht aktivierungspflichtige) Seriennummern (bzw. die in dem verlinkten Thread genannte Alternative mit der Signierung, sodass eine Schlüsselgenerierung ohne Veränderung der exe quasi unmöglich ist - wer es nicht scheut, eine manipulierte Anwendung einzusetzen, für den sind auch weitere Hürden kein Hindernis).

Diese kannst du ja zu Statistikzwecken (Achtung bzgl. Datenschutz!) bei jeder Installation an deinen Server übermitteln und ab einem gewissen Schwellenwert (nach manueller Auswertung) den Key in der nächsten Programmversion deaktivieren bzw. sogar rechtliche Schritte gegen den ursprünglichen Käufer einleiten.
Oder zumindest mal freundlich nachfragen, wieso plötzlich mit einer Seriennummer so viele Installationen aktiviert werden 😉

//das Ende markieren  
naechster = null;  

in SetDaten sieht mir verdammt verdächtig aus...

Zudem hängst du in deiner Schleife immer wieder das gleiche Objekt an; das kann nicht gut gehen. Klassen sind Referenztypen!

Daher erst alle Controls "zeichnen" und Code anpassen, so dass die Anwendung mit WPF läuft und dann MVVM usw. einführen... so war zumindest der Plan...

Wie gesagt: Binde besser die bisherigen WinForms-Formen und stelle dann eine nach der anderen "richtig" um; deine jetzige Vorgehensweise führt IMHO nur dazu, dass du alles doppelt machen musst.

Wenn du es jedoch unbedingt so machen willst.
Verwende einfach ein recht unsauberes MVVM und packe einfach alles aus der WinForms-Form in eine eigene Klasse, die du dann an das WPF-View bindest:

public class ViewXYViewModel
{
   public string TextBox1Text { /* Getter + Setter mit INotifyPropertyChanged */ }

   //...
      this.TextBox1Text = "";
   //...
}

<TextBox Text="{Binding Path=TextBox1Text}" />

Mit etwas Refaktoring kommst du dann mit vertretbarem Aufwand zu "sauberem" MVVM (indem du die ganzen Control-Spezifischen Dinge aus dem ViewModel raushaust und etwas aufräumst).

Und nun kommt WPF... und ich weiß nicht wie man dies nun am schönsten abbildet.

Eine WinForms Anwendung 1:1 nach WPF zu portieren, ist in meinen Augen nur Zeitverschwendung: Man ärgert sich und hinter funktioniert alles nur schlechter als vorher.

Warum willst du die Anwendung überhaupt komplett portieren?
Es gibt genügend Ansätze, WinForms und WPF parallel in einer Anwendung zu verwenden.

In WPF ist es nicht üblich, direkt auf Controls zuzugreifen.
Stattdessen verwendet man DataBinding, Templates und Commands. Damit kannst du den Code, den du in deine Basisklasse packen willst, komplett einsparen.
Schaue dir einmal das MVVM-Pattern an; ohne dieses macht die WPF meiner Erfahrung nach keinen Spaß und wirkt wie ein großer, sehr frustrierender Rückschritt im Vergleich zu WinForms.
Hat man sich aber erst einmal an MVVM gewöhnt, möchte man gar nicht mehr ohne arbeiten.

Ich nutze seit einer Weile Cloud-Dienste, um meine Dateien zwischen Laptop und PC zu syncen.

Vor ein paar Wochen bin ich hierbei von Dropbox zu Google Drive gewechselt; hauptsächlich, da mir Google (wenn auch als Datenkrake bekannt) in puncto Datenschutz /-sicherheit einfach sympathischer ist als Dropbox (siehe vor allem Dropbox confirms security glitch--no password required; seither war mir immer etwas mulmig zumute, da ich auch Dateien synchronisiere, die man nicht wirklich öffentlich verbreiten möchte.)

Generell überwiegt bei mir aber der Komfort, Dateien quasi ohne größere Zeitverzögerung zwischen den beiden Rechnern synchron zu halten. Und das, ohne Rücksicht darauf zu nehmen, wann welcher Rechner angeschaltet ist.
Auch der Zugriff via iPhone / iPad ist ganz nett, wenn man mal zwischendurch etwas nachschauen möchte.

Seit meinem Wechsel ist mir allerdings aufgefallen, dass der Google Drive Client (sowohl unter Windows als auch unter OSX) nicht ganz so ausgereift wie der von Dropbox ist; manchmal werden Dateien erst nach einem Neustart synchronisiert und der Resourcenbedarf von GDrive ist deutlich höher (wirkt sich besonders beim Laptop auf die Akkulaufzeit aus, wenn nach dem Start die CPU erst einmal für ein paar Minuten voll ausgelastet ist...).

Vor dem Hintergrund erwäge ich, evtl. mal für eine Weile zu Skydrive / LiveMesh / LiveSync / oder wie es dann gerade heißt zu wechseln.

Als Netzlaufwerk kannst du soweit ich weiß keinen einbinden; stattdessen wird ein Ordner (je nach Anbieter mit selektiver Auswahl der Unterordner) synchronisiert.

Hallo CoLo,

ich persönlich handhabe das ganze wie folgt:

Wenn ich es nicht mal vergesse, schalte ich in den Buildoptionen meiner Projekte immer die Option "Check for arithmetic over-/underflow" (unter "Build-Advanced" unter VS). Diese hat quasi den gleichen Effekt wie ein "großer" checked-Block um den gesamten Code.

Hintergrund ist, dass man IMHO beim "normalen" Lesen von Code nicht über eventuelle Overflows nachdenkt. Bei der Ausführung des Codes wird somit sichergestellt, dass dieser keine "unangenehmen" Überraschungen enthält; ich kann davon ausgehen, dass kein Bug, der durch unabsichtlichen Overflow verursacht wird, unentdeckt bleibt.

Will ich hingegen bewusst Overflows ausnutzen, sodass "(sbyte) 255" auch tatsächlich "-1" ergibt, verwende ich für diese Stellen unchecked. Erfahrunsgemäß beschränkt sich dies auf wenige Klassen bzw. Methoden (die dann Algorithmen auf Bytebene implementieren).

Die Convert Klasse verwende ich recht selten; hauptsächlich, wenn ich wie im Beispiel von chriscolm von Object aus casten will, und nicht genau weiß, ob sich jetzt hinter dem Objekt ein Integer, ein Byte oder doch etwas anderes verbirgt.
Convert.ToXXX nutzt ja soweit ich mich erinnern kann auch IConvertible<T>, was die normalen Casts nicht tun.

Oder gibt es hierfür noch bessere Vorgehensweisen?

Ja - verzichte auf die Basisklasse.

Wenn du sagst, welches Problem dich dazu veranlasst hat, eine einzuführen, können wir dir vielleicht helfen, dieses ursprüngliche Problem zu lösen 😉

"Every system resists its proper functioning. In this case, a design to make programs less annoying and intrusive merely drives those programs to even more annoying and intrusive behavior. "

Hallo Mausschubser,

laut Ergebnis einer Google-Suche xt:Commerce 3: Administratorpasswort oder E-Mail reseten ist es nicht verschlüsselt, sondern (scheinbar ungesalzen...) als MD5-gehasht hinterlegt.

Kleine Ergänzung: Das ganze sollte man am besten noch in einen unchecked-Block packen, sodass es später nicht wegen irgendwelcher Überläufe (bei der Konvertierung nach byte) knallt (wenn die entsprechende Prüfung in den Buildoptionen eingestellt ist, was sich IMHO empfiehlt).

Jetzt klappt das mit jpg beim nächsten drucken klappt das iweder nicht dann gehts wieder

Evtl. funkt dir da dann teilweise auch noch der Druckertreiber mit irgendwelchen Optimierungen dazwischen, der die Kompressionsartefakte manchmal verstärkt und manchmal nicht.
Aber das ist eine reine Vermutung 😉

Zum eigentlichen Thema:

Gibt es eine schnelle möglichkeit alle daten einzulesen um der Progressbar einen maximal Wert vor dem einlesen zu geben?

Nein, gibt es nicht.
Du kannst lediglich einen Wert schätzen, indem du dein Auslesealgorithmus möglichst geschickt aufbaust (z.B. Ermittlung durchschnittlicher Zahl der Dateien in einem Ordner / Ordnertiefe), um dann Hochrechnungen anstellen zu können.
Es ist jedoch fraglich, ob dass so viel bringt.

Eine recht pragmatische Methode wäre z.B., die Progressbar ausgehend vom Root jeweils auf alle Ordner einer Ebende gleichmäßig zu verteilen.
Lägen im Root z.B. 10 Ordner, würde die Abarbeitung eines Ordners 10% Fortschritt bedeuten; diese 10% eines Ordners wird dann wieder an die Anzahl der Unterordner dieses Ordners aufgeteilt usw.

Hallo matz,

meistens reicht auch der Emulator, den VS 2008 mitbringt.

Sorry aber was meinst du mit Mono? Google hilft

ein anspruchsvolles GUI in Embedded Geräte zu integrieren, oder nicht? Sonst müsste man solange noch kein Windows Embedded Standard 8 raus ist damit programmieren

Kommt darauf an, was genau du als Embedded Gerät ansiehst.
Wenn wir von ARM reden, hast du mit der Aussage (unter Windows) recht.
Für x86 (gibt's auch einige "embedded" Hardware, die das einsetzt), ist das hingegen kein Problem.

Was würdest Du denn tun? Welches Framework?

Ohne eure genaue Situation zu kennen, würde ich im Moment eher zu WPF unter Win 7 tendieren.

Mal abgesehen von der Ressourcenfreundlichkeit, meint Ihr Qt mit Embedded Linux wäre da besser geeignet?

Siehe:

Evtl. ist unter Linux auch Mono eine Option (du müsstest evaluieren, ob und wie gut das unter der embedded Version unterstützt wird), wenn die Lizenzkosten ein Thema sind.

Ohne fundierte Erfahrungen ein komplexes C++-Projekt zu beginnen, halte ich für recht gewagt.

Hallo Akhanto,

hast du zwischenzeitlich mal neu gebaut?

Dateiverwaltung.DataSets liegt im gleichen Projekt wie die XAML-Datei?

Weiß jemand, ob sich die Farbe der Icons einstellen lässt?
Das wäre auf jeden Fall eine nette Spielerei 😁

Ansonsten haut mich die Farbgestaltung jetzt nicht wirklich vom Hocker; ich glaube aber, dass ich mich recht schnell daran gewöhnen könnte.

Den Tree-View mit den Ordnern haben sie aber doch hoffentlich nicht vollständig wegoptimiert, oder?
Es wäre mal interessant zu sehen, wie sich der in das Design einfügt.

@herbivore: Ja - da hast du recht.
Ich glaube, das ist auch, was mich an dem Design bisher stört: Der eigentliche Inhalt wird meiner Meinung nach visuell nicht klar genug von den Steuerelementen / dem Rahmen abgesetzt.

Kleine Idee, falls es nicht gehen sollte: Per Mini-Tool im Prebuild-Ereignis eine CS-Datei mit dem gewünschtem Inhalt erzeugen.

Was meinst du an dieser Stelle mit "gleich in die Klasse packen"?

In deinem Beispiel würde ich FireEndPredicate und FireEnd in eine Klasse packen (abgesehen davon, dass es ja durch das "Event" ersetzt wird).

Weiterer Vorteil bei dem Observer ist, dass du mehrere Aktionen am Ende durchführen kannst (z.B. Benachsrichtigung des Users, Schließen der Streams, Anstoßen der weiteren verarbeitung, ...)

Naja, die Aussage kann ich so nicht unterschreiben. Du kannst WES7 das schon sehr stark modularisieren

Meine Aussage war eher auf Kernel / nutzbare Features usw. bezogen.
Klar - weglassen kann man vieles; aber man kann soweit ich weiß auch soviel dazubauen, dass man quasi ein "vollwertiges" Desktop-Windows hat.

Will sagen: So lange man Zugriff auf die Auswahl der Komponenten hat, kann man es beinahe wie ein Desktop-Windows programmieren.

Hallo MVP,

wenn du tatsächlich action-spezifische Prädikate verwendet, würde ich diese nicht in einer separaten Klasse implementieren, sondern gleich in die Klasse packen.

Statt eines "Magic-Strings" würde ich zum Beenden eher ein leeres Array verwenden.

Der Producer könnte dann am Ende ein "Event" feuern (unter Java halt einen Observer benachrichtigen), woraufhin dann der Stream geschlossen wird; dies muss IMHO nicht in einer Aktion erfolgen.

Besser ist es die eigenen Quelltext-Bibliothek in eine eigenen Klassenbibliothek (od. mehrere) zu übersetzen und dann diese DLL(s) zu referenzieren.

Genau: Unter .NET ist es nicht mehr nötig / üblich, Quellcode weiterzugeben.
Stattdessen wird der kompilierte Code in eine Assembly verpackt, welche du dann als Verweis hinzufügen kannst.

Das hat viele Vorteile: Angefangen von Schutz des geistigen Eigentums über bessere Versionierung bis hin zu schnelleren Buildzeiten.

Aber da bin ich wohl bestimmt während meiner 17 Jahre Delphi zu sehr verwöhnt worden

Falsch, du hast dich einfach daran gewöhnt 😉

Compact Framework 3.5, kann ich ja kein WPF benutzen, richtig?

Nein, meines Wissens nicht.

Aber Windows Forms geht doch eigentlich alles, wenn ich das Compact Framework 3.5 nutze oder?

Vieles geht, aber längst nicht alles.
Freiwilllig würde ich persönlich nicht auf das "richtige" Framework zugunsten des CF verzichten.

Ich habe auch letztens auf einem Embedded Computer mit Windows Embedded Standard 7 ein WPF Programm gestartet. Wenn ich das so machen würde, wo würde ich dann spätestens scheitern?

Wie meinst du das?
Windows 7 Embedded ist ein "ganz normales" Desktop-Windows, das lediglich etwas (bis gar nicht) abgespeckt ist.
Mit Windows CE hat das nichts mehr zu tun; nur dort kommt das CF zum Einsatz.

Transparenzen kann man doch auch mit PNG simulieren, oder?

Nicht so einfach bzw. so umfassend wie unter WPF.

Für WPF finde ich lauter Design-Beispiele für Touchscreen GUIs. Bei WIndowsForms siehts leider sehr lau aus.

Willst du eine Multimediaoberfläche realisieren (d.h. zur Verwendung im Kioskbetrieb / Präsentationen / zum Erreichen von neuen Nutzern)?
Dann empfiehlt sich tatsächlich WPF aufgrund der besseren Unterstützung vieler Gestaltungselemente (echte Transparenz, performante Transformationen, Animationen usw.).

Geht es dir "nur" um klassische Maschinensteuerung (Single-Touch; grafisch "langweilige" Oberfläche) brauchst du vermutlich nicht einmal spezielle Anpassungen: So lange Buttons etc. ausreichend groß sind, kommst du auch mit WinForms sehr weit - unter CE (und auch unter den Desktop-Windowssen) werden Bildschirmberührungen automatisch in Mausklicks an der entsprechenden Bildschirmstelle umgewandelt.

Evtl. ist unter Linux auch Mono eine Option (du müsstest evaluieren, ob und wie gut das unter der embedded Version unterstützt wird), wenn die Lizenzkosten ein Thema sind.

Im Javascript gibt es dafür eine spezielle Funktion, die ich mit C# nachbauen muss, da später im Skript Abfragen auf a == "function" getätigt werden.

Bevor du anfängst, Javascript-Bibliotheken "nachzucoden", solltest du sie lieber direkt in C# nutzen.
Siehe als Anregung: Are there any .NET CLR/DLR implementations of ECMAScript?

Hallo Nathan79,

herzlich willkommen hier auf myCSharp.de!

Den Generator in dieser Weise abzuändern, ist eine sehr naheliegende Lösung.
Ganz im Sinne der Vermeidung unnötiger Komplexheit (oder "KISS" wie man so schön sagt 😉 ) kann das je nach Situation IMHO eine durchaus gangbare Lösung darstellen.

Meiner Meinung / Erfahrung nach fährt man unter WPF jedoch häufig besser, wenn man nie direkt EF-Klassen an die Oberfläche bindet. Stattdessen empfiehlt sich je View eine Art ViewModel-Wrapperklasse, welche die benötigten Properties der EF-Klasse im Sinne eines Proxies nach außen zur Verfügung stellt.
Hierzu kannst du z.B. MicroModels (oder etwas in die Richtung) verwenden, um dir einiges an Tipparbeit zu sparen.

Das hat dann den Vorteil, dass du gerade solche "Datentyptransformationen" einfach im ViewModel erledigen kannst (wäre dann eine Zeile wie "this.Details = new ObservableCollection<Detail>(model.Details)" ).
Zudem bist du flexibel bei sonstigen Änderungen (z.B. Formattierung von Werten, Änderungen von Hierarchien, Auflösen von Aggregationen zur Anzeige usw.).
Auch kannst du Dinge wie Validierung, Save-/Cancel Funktionalität usw. ohne allzu großes Kopfzerbrechen einbauen.

Aber wie gesagt ist diese Vorgehensweise nicht immer nötig - sofern du allerdings anfängst, Converter und / oder Formnatstrings in XAML einsetzen zu beginnst oder deine EF-Klassen um anzeigespezifische Member erweiterst, solltest du noch einmal über diese Variante nachdenken.

Hallo talla,

ich persönlich sehe das aus zwei "Perspektiven":

Unter .NET habe ich schon einiges an Erfahrung mit den verschiedensten Technologien gesammelt: WinForms / WPF, ASP.NET / ASP.NET MVC, Remoting / WCF, ADO.NET / LINQ to SQL / EF...
Durch die Anwendung der Technologien entwickelt man mit der Zeit ein Gefühl, welche Technologie in welcher Situation die "Richtige" ist bzw. welche Vorteile auch jenseits des Marketing-Papers spürbar sind (und über welche erheblichen Nachteile niemand spricht).
Hier ist die Technologievielfalt folglich eher "Segen" für mich: Ich kann die Vorteile aller Technologien nutzen, indem ich jeweils die "richtige" wähle; dabei verwende ich manche Technologien (für neue Projekte) überhaupt nicht (bspw. kalssisches ASP.NET), während ich bei anderen Technologien keine generellen Präferenzen habe (wie WinForms / WPF).

Allerdings: Zum "Segen" ist die Technologiefülle für mich nur durch die Erfahrung geworden, die ich (hauptsächlich neben meiner Schulzeit) selbst mit den Technologien gemacht habe.
Hätte ich diese Zeit für "sinnlose" Projekte (aus Sicht der Sinnhaftigkeit, Vollständigkeit etc. - aus den meisten ist nichts wirklich Brauchbares für ohnehin nicht existierende Anwender geworden) allerdings nicht gehabt, und wäre alleine auf Dokumentation und Artikel angewiesen gewesen, glaube ich nicht, dass dieser Zustand jemals eingetreten wäre.

Sehr extrem merke ich das derzeit bei Java: Hier fehlt mir bisher noch einiges an praktischer Erfahrung, die ich auch in nächster Zeit nicht in dieser "ungezwungenen" Form sammeln kann, wie mir das unter C# / .NET möglich war.
Hierzu fehlt mir inzwischen einfach die Zeit; wenn etwas in Java entwickle, muss am Ende auch ein Endprodukt stehen, bei dem "technologische Perfektion" eine sehr untergeordnete Rolle spielt.

Das führt dann bei mir im Moment dazu, dass ich vermutlich unter Java häufig suboptimale Lösungen einsetze, über deren .NET Äquivalent ich genau wüsste, dass es eine bessere Technologie gäbe.

Unter .NET käme ich z.B. nie auf die Idee, mit einem XmlReader ein XML-Dokument zu parsen.
Unter Java? Da mir die Zeit für eine intensive Recherche / Vergleich von XML-Parsing unter Java schlichtweg nicht zur Verfügung stand / steht, parse ich dort ein Dokument gerade mit XPath-Klassen.
Ob es bessere Möglichkeiten gäbe? Sicherlich - aber ich habe mich selbst dabei ertappt, wie ich einfach die "Erstbeste" Technologie genommen habe.
Den Versuch, mittels Java eine dynamische Webseite zu erstellen, habe ich sogar wieder zurückgestellt: Einfach zu groß ist die Fülle der techologischen Möglichkeiten und Varianten und die Aussagen über Vor- und Nachteile davon sind widersprüchlich und helfen nicht wirklich. Um eine Vielzahl kleiner Beispielprojekte käme ic folglich nicht herum - und selbst dann müsste ich erst einmal herausfinden, welche Möglichkeiten es überhaupt gibt (und nicht nur, welche besonders häufig diskutiert werden, da es sie schon lange gibt).

Insbesondere den Einstieg in eine derartige Technologievielfalt halte ich somit für sehr problematisch: Woher soll man als Anfänger wissen, dass eine Technologie inzwischen obsolet ist, wenn diese noch Top-Plätze im Google-Suchranking einnimmt?
Wie soll man erfahren, dass eine andere Technologie weitaus besser geeignet wäre, als die erstbeste, mit der es auch irgendwie funktioniert?
Wie unterscheidet man "Marketing-Geschwätz" von echten Ratschlägen?

Unter .NET muss ich inzwischen wohl sogar ehrlich zugeben, dass ich eine gewisse "Technologiearroganz" entwickelt habe:

Ich werfe es Fragestellern vor, wenn sie in der WPF Controls statt via DataTemplates über Schleifen erstellen, LINQ to Objects mit dem EF verwechseln, oder sich über die Performanceunterschiede von Properties und Feldern auslassen.

Aber wirklich anders würde es mir wohl als Einsteiger auch nicht gehen bzw. geht es mir unter Java auch nicht.
Klar - Informationen findet man überall:

Aber wie soll ich bewispielsweise ohne dieses Praxiswissen erkennen, dass die in unzähligen Blogposts und Diskussionen thematisierten Performanceunterschiede zwischen Feldern / Properties für mich nicht relevant sind?
Oder einsehen, dass die unzähligen WPF-Beispiele von "Pseudo-Experten", die hunderte Zeilen von Code schreiben, um den "WPF-Designfehler" zu "beheben", dass man nicht ohne Weiteres auf die generierten Controls eines ItemControls zugreifen kann, auf unzureichenden Erfahrungen basieren?
Welche Chancen habe ich, wenn mit "LINQ" mal "LINQ to Objects", mal "LINQ to SQL", mal "LINQ to Entities / EF" gemeint und dann mal wieder die Gesamtheit aller Technologien mit LINQ im Namen gemeint ist?

Vielelicht ist auch vielmehr das Problem, dass man viel zu leichtfertig annimmt, man beherrsche eine bestimmte Technologie, wenn man eigentlich gerade mal einen Bruchteil davon begriffen hat.
Schnelle Ergebnisse erreicht man in der Softwareentwicklung bekannterweise durchaus recht problemlos; aber für qualitative Ergebnisse kommt man eben nicht um einen gewissen Aufwand herum.

Leider wird heutzutage hauptsächlich vermittelt, wie einfach Softwareentwicklung doch ist und dass quasi jeder nach ein paar Wochen Trainings jede Art von Anwendung entwicklen kann.
Und Ausbildung beschränkt sich meist auf Sprachsyntax und "die eine" Technologie, die man dann (in Projekten, Klausren etc.) einsetzen zu hat.
Wo bleibt da dann der Blick "über den Tellerrand", um beispielsweise zu erkennen, dass Datenbankzugriff unter C# eben nicht automatisch ADO.NET bedeutet, sondern auch NHibernate oder das EF eine deutlich bessere Alternative darstellen können?

Insofern ist die Technologievielfalt im Framework für die meisten (insbesondere Einsteiger) vermutlich ein Fluch; es fehlt einfach an geeigneten Überblicken bzw. an der Zugänglichkeit derselbigen.
Nur durch einen enormen Zeitaufwand schafft man es dann nach und nach, dass für einen selbst der Fluch nach und nach zum Segen wird.
Doch dafür hat man in den meisten Fällen vor dem Hintergrund der erwarteten, schnellen Ergebnisse wohl nicht die nötige Zeit.

Technologievielfalt im Framework für mich? (Derzeit) ganz klar Segen - aber ich habe vollstes Verständnis für diejenigen, die sie als Fluch ansehen.
Unter Java erlebe ich nämlich derzeit genau dieses Gefühl.

Das "einfachste" wird sein, wenn du einfach die falsche Variante deines Dozenten für die Klausur lernst und dir "für's Leben" die richtige Variante merkst.

Alles andere wäre - meiner Erfahrung nach - zwar sicherlich ein Zeichen für Eigeninitiative und Engagement; wird dir aber relativ sicher bei der Klausurbewertung alles andere als positiv angerechnet.

Mich persönlich stört so etwas zwar auch - ich musste mich aber damit abfinden, dass diejenigen, die quasi das Skript auswendig lernen, häufig bessere Ergebnisse einfahren, als diejenigen, die auch tatsächlich verstehen, was sie da eigentlich gelesen haben und sich auch mal außerhalb des Skriptes informieren (und somit halt auch mal leicht vom Skript abweichende Lösungen niederschreiben).

Ist das - auch von dir FZelle - eine Vermutung, oder gibt es dazu irgendwelche Herstelleraussagen oder Presseberichte, auf die ihr euch stützt?

Dass nur beim Lesen gecacht wird, stand auch mal in einer c't (frag' aber bitte nicht, in welcher 😄); dürfte aber irgendwann zwischen Januar und Mai gewesen sein.
Schreibzugriffe erfolgen (zumindest in der aktuellen Generation) immer mindestens gleichzeitig auf HDD und SSD (wodurch die HDD dann die SDD ausbremst).

BTW: Ich setze (zugegebenermaßen aus Kostengründen) eine 80GB SSD in Kombination mit einer 2TB-Platte und einer 500er Platte ein.

Der Platz auf der SSD reicht, wenn man größere Verzeichnisse, bei denen es nicht auf hohe Geschwindigkeiten ankommt (z.B. C:\Windows\Installer; Steam-Bibliothek etc.) auf die HDD kopiert und dann per mklink eine Junction erstellt (oder gleich auf die HDD installiert).
Daten (z.B. Schriftverkehr, FF-Profil, ...) habe ich ausschließlich auf der HDD liegen; die VS-Projekte liegen in einem Unterordner auf der SSD und werden per subst zwecks schnellerem Zugriff als virtuelles Laufwerk "X:&quot; gemountet.

Klar - das ganze erfordert ein paar Minuten Einrichtungszeit; wenn's dann aber mal läuft, reicht aber auch eine "kleinere" SSD (wobei ich bei den Preisen zur Zeit auch eher eine 256er nehmen würde). 512GB SSD-Kapazität halte ich derzeit zwar für sicherlich ganz nett, aber eben auch (im Angesicht des Preises) für durchaus verzeichtbar; das Geld würde ich dann eher in eine höherwertige HDD investieren (7200 Umdrehungen, großer Cache usw.).

Hallo Thomas_1,

was du ausrechnen kannst, ist höchstens die minimale Laufzeit eines Signals. Da helfen dann Entfernung, Lichtgeschwindigkeit und ein paar ms (oder auch ein paar mehr) für den Overhead durch Routing etc. weiter.BTW: Hier hilft z.B. Wolfram Alpha.

Die maximalen Laufzeiten sind aber - wie von Abt angemerkt - nach oben äußerst offen und variiert stark je nach Auslastung bzw. gewählten Routen der Pakete.

Du kannst ja mal ein paar Server in verschiedenen Ländern automatisiert und periodisch anpingen und auswerten, wie sich das ganze verhält.

Um nochmal genauer nachzuhaken: Welche Objekte leaken denn laut Profiler? (du verwendet ja hoffentlich einen und schaust nicht einfach den Speicherverbrauch im Taskmanager an, oder?)

In dem Kontext ganz gut zu wissen:
Will man nur die Events einer Anwendung einfach "Include" als Filter-Aktion für den Process nehmen; die anderen werden dann automatisch ausgeblendet (und müssen nicht explizit excluded werden).

Den Pfad der ersten Ausführung in die Config aufnehmen klappt auch nicht, denn dort wäre er leicht zu ändern.

Du kannst deine Config zusätzlich noch signieren.
Vielleicht reicht das auch schon für die Zertifizierung.

Allerdings musst du den privaten Schlüssel auch irgendwo speichern (außer, du schickst die Config zum signieren zu einem Server... - aber selbst dann könnte jemand den private Key der exe austauschen usw.).

Finde dich damit ab, dass das nicht so geht, wie du dir das vorstellst.
Du kannst es dem User zwar schwer machen, deine Anwendung zu kopieren / ohne Lizenzschlüssel zu betreiben etc., aber ausschließen wirst du es nie können, solange der User Schreibrechte auf die Binaries deiner Anwendung hat.

Hallo Sinned88Mt,

herzlich willkommen hier auf myCSharp.de!

Das Programm zeichnet den Kontrollpunkt an die richtige (gedrehte und transformierte) Stelle.

Dann nehme ich an, dass du irgendwo eine Transformation durchführst bzw. Graphics.Transform nutzt.

Auf die gleiche Art kannst du dann auch den Punkt transformieren, um das richtige Pixel zu erhalten.

Wenn ich das gleiche Datum subtrahiere kommt 1 raus. Macht das Sinn?

IMHO schon - wenn man ersten und letzen Arbeitstag am selben Tag hat, hat man ja genau einen Tag gearbeitet.

Vermutlich kann die WPF nicht ein Objekt einer Collection aufgrund eines Bindings ersetzen.

Verpacke die ObservableCollection besser in eine Klasse, sodass du sie letztlich wieder als Property bereitstellst.
Oder noch besser: Verwende immer die gleiche Collection (d.h. ersetze sie nicht innerhalb des Controls), sondern cleare sie nur.