Laden...
Avatar #avatar-3206.png
Benutzerbeschreibung
„Morgen ist noch nicht gekommen, und gestern ist vorbei. Wir leben heute.”

Forenbeiträge von malignate Ingesamt 742 Beiträge

02.04.2011 - 16:48 Uhr

Erstelle eine eigene Liste und leite diese von Collection<T>) ab,benutze für die Validierung die InsertItem Methode.

23.03.2011 - 12:26 Uhr

Wenn du schon Team Foundation Server hast würde ich in Kombination dazu Finalbuilder einsetzen.

Das integriert sich gut in das Build System und du kannst dir dort dein Deployment Script zusammenklicken und debuggen.

Dann machst eine neue Build Config "Build and Deploy" und hast mit einem Click alles neu gebuildet und verteilt.

Eigene Actions (wie Config verändern) kannst du dann selber programmieren und für 300 Dollar bekommst du ein super Tool.

19.03.2011 - 12:09 Uhr

Sehe ich genauso, mein Wunsch Syntax wäre:


.Method(MemberAttributes.Public | MemberAttributes.Static, "Main")
    .Parameter(typeof(string[]), "args1")
    .Parameter(typeof(string[]), "args2")
.BeginBody
    .CallStatic(typeof(Console), "WriteLine", Expr.Primitive("Hello Fluent CodeDom"))
    .CallStatic(typeof(Console), "WriteLine", Expr.Primitive("Hello Again"))
.EndBody

16.03.2011 - 10:52 Uhr

Sieht super aus, die API könnte man aber noch verbessern:

  • Ist das .Body wirklich nötig
  • Könnte man CallStatic nicht vereinfachen, damit das Expr.Primitive unnötig wird? (z.B. objekt array als Argumente, alle nicht-expressions werden in ein primitive umgewandelt).

Ich denke da gibts noch viel Potential, die Idee finde ich aber Klasse und werde es auch verwenden, sobald ich wieder was mit CodeDOM mache.

11.03.2011 - 16:56 Uhr

Mir ist gerade noch was eingefallne, was nur bedingt zum Thema passt:

Falls du folgenden Link nicht kennst: Sehr empfehlenswert, bei Queries mit vielen Ergebnissätzen bringt das gut was an Performance.

http://www.codeproject.com/KB/cs/DynamicCodeVsReflection.aspx

11.03.2011 - 16:47 Uhr

Ich vermute dass du genau für den Fall nichts finden wirst, aber eventuell helfen Graph Komponenten, die Bäume darstellen können.

z.B.
http://www.easydiagram.net/
http://www.yworks.com/en/products_yfiles_web_about.html

11.03.2011 - 16:26 Uhr

Kannst dir ja selber machen, mit Reflector zum Beispiel 😄

11.03.2011 - 14:41 Uhr

Ich denke Variante 3 wäre am einfachsten. Du musst nur alle Properties suchen, die Lazy<?> als Property Type verwenden und dann eine Instanz von Lazy<?> zuweisen, die die Info aus der Datenbank nachlädt.

Vorteile:

  1. Keine weiteren Abhängigkeiten zu PostSharp oder Rhino Mocks or whatever.

  2. Du kannst ohne Zusatzinfos leicht entscheiden, welche Werte nachgeladen werden sollen und welche nicht.

  3. Es ist wirklich einfach zu implementieren.

  4. Deine Properties müssen nicht virtuell sein.

PS: Ich würde generell auf jeden Fall noch das PrimaryId Property mit einem Attribut [Id] versehen, dann kann das leicht ausgelesen werden und dein PersonAdapter kann dann sehr leicht von TableAdapter ableiten und muss nur noch die konkreten SQL Statements implementieren. Alternativ auch seperare Mapping Info.

PPS: Bei Variante 2 würde ich noch PostSharp verwenden um INotifyPropertyChanged zu implementieren (wenn du schon dabei bist).

11.03.2011 - 11:57 Uhr

Ich sehe 3 Möglichkeiten:

  1. Du kannst zum Beispiel mit dynamisch generiertem Code arbeiten. Deine Klasse Person hat nur virtuelle Properties. Zur Laufzeit erstellst du dann eine von Person abgeleitete Klasse, die für die Properties eine entsprechende Implementierung bereitstellt.

Vielleicht hat das Rhino Framework schon entsprechende Implementierungen.

  1. Eine andere Möglichkeit wäre ein AOP Framework, dann hättest du ein Attribute 'Lazy' oder so.

  2. Die dritte und einfachste Alternative wäre die Klasse Lazy: http://msdn.microsoft.com/en-us/library/dd642331.aspx

10.02.2011 - 13:05 Uhr

Sehr schön. Was mir auch noch nicht so gefällt ist das IChannel interface. Das ist ja ganz nett, weil es halt schon existiert, aber total überladen, da grauts einem echt davor , dass zu implementieren.

Für mich wäre MSMQ interessant, aber dsa IChannel zu implementieren macht ja gar kein Spaß...

27.01.2011 - 11:54 Uhr

Wie siehts mit Request-Response Szenarien aus, zum Beispiel Callbacks für ein spezielles Request.


DoRequest(x => 
   {
      Console.WriteLine(x);
   });

26.01.2011 - 10:40 Uhr

Außerdem kann man durch einen Obfuscator nicht verhindern, dass man das Konzept einer Anwendung erkennt.

Ist zwar nur durch den Source Code schwer zu beurteilen aber geht durchaus. Da öffentliche Namen ja nicht geändert werden ist das kein Problem.

Ich finde das also total sinnlos.

20.01.2011 - 18:08 Uhr

Ich würde einfach ein WriteableBitmap drüber rendern und dann an der Maus Position die entsprechenden Pixel Transparent machen.

Funktioniert auf jeden Fall in Silverlight, in WPF zu 99% auch. Vll. hilft dabei http://writeablebitmapex.codeplex.com/.

19.01.2011 - 00:05 Uhr

Kannst dir auch mal CMS Orchard 1.0 anschauen. Habs noch nicht verwendet, aber die Doku sieht ganz gut aus.

14.01.2011 - 16:51 Uhr

Ich finde das jetzt nicht so übermäßig schwer, was ich im Prinzip machen würde:

(1) Eigene Metadaten mit Informationen zu Spalten (Validierung, Erklärung, Id des Fehlertextes etc.)

(2) DataLayer der mit Hilfe der Metadaten Queries erstellt.

(3) Eigene Datenstruktur oder eine DataTable für das Auslesen der Daten.

(4) Validierung zu Beginn der Anwendung: Passen meine MetaDaten zum DB Schema?

(5) WPF als Oberflächentechnologie. Eigene Controls für die Datenbank Felder. Speichern der konfigurierten Oberfläche als Xaml.

(6) Datenbank Designer (Editieren der Metadaten).

(7) Updaten der Datenbank aufgrund der Schemadaten, evtl. Portierungsregel (z.B. hilfreich bei einem Update der Anwendung)

Ich würde mir mal dazu Dynamic Data anschauen. Im Prinzip hast du ja dabei auch eine dynamische Oberfläche und kannst bestimmt einiges davon abschauen. Dynamic CRM kann das afaik auch.

Ich finde das nicht sonderlich komplex, sondern relativ straight forward. Es ist aber einen Haufen Arbeit und kein Task für ein paar Tage. Man muss viel Zeit in das Design / Architektur investieren um nicht ein riesen Chaos zu produzieren. Ich würde mal aus eigener Erfahrung mit ca. 4-6 Mannmonaten rechnen bis zu einer nichtperfekten ersten Version.

14.01.2011 - 16:39 Uhr

Vorrausgesetzt alle deine Third Party hersteller haben auch nen WPF Port.

Für was soll das gut sein?

27.12.2010 - 17:09 Uhr

Ja, mit 40 KB. Selbst mit Silverlight würde ich Behaviors auf jeden Fall einsetzen. Wenn man Telerik Control verwendet, hat man gleich 5-6 zusätliche DLLS mit 0,5 MB

05.12.2010 - 10:27 Uhr

Klar, schreib dir halt einen eigenen Catalog.

Vielleicht hiflt dir der Artikel weiter: http://www.wintellect.com/CS/blogs/jlikness/archive/tags/deploymentcatalog/default.aspx

30.11.2010 - 21:49 Uhr

Mist, hätte ich noch erwähnen sollen:

Ich brauche das ganze auch für Silverlight, damit fällt Windows.Drawing und die Lib, die nur einen C# Wrapper hat leider flach.

30.11.2010 - 18:57 Uhr

Hi, ich suche eine fertige Implementierung oder auch einige Papers um aus einer Liste von Polygonen vereinigte Polygone zu bilden, wenn sich zwei Polygone überschneiden (sonst das Original Polygon).

Zur Vereinfachung:

  • Nur konvexe Polygone
  • Nur Rechtecke

Wenn jemand eine fertige Implementierung kennt oder auch nen gutes Paper würde ich mich sehr darüber freuen. Habe leider noch nichts gefunden.

22.11.2010 - 00:16 Uhr

Gibts von dem Tool auch ne Version in Englisch? Ich bin in einem Team, in dem wir auf Englisch kommunizieren, da kann ich mit Deutsch nicht so viel anfangen.

13.11.2010 - 02:00 Uhr

Was haltet ihr von Dynamisches Proxies?

Mit Castle Windsor kann man recht einfach Dynamische Proxies generieren und mittels eines Inceptors vor jede Public Method für die man es braucht eine Rechteprüfung schalten.

Das finde ich eigentlich relativ interessant, wenn man so einen Proxy bei Unity & Co registriert wird das total transparent, man muss sich nirgends Gedanken machen, außer eine Zeile ändern:


unity.RegisterType<IRepository, Repository>();

wird zu


unity.RegisterType<IRepository, PermissionControlled<IRepository, Repository>();

Ich habe das noch nie in einer richtigen App eingesetzt aber mal ne Demo gemacht und fand es ganz cool.

28.09.2010 - 10:29 Uhr

Es macht von der Abstraktion eines Treibers gesehen auch keinen Sinn, eine solche Unterscheidung zu machen, aber ich hatte gehofft, es gibt vll. doch was.

28.09.2010 - 09:09 Uhr

Gute Idee. Bitte hier nicht weiter den Sinn diskutieren, da bin ich eh der gleichen Meinung.

Ich möchte wissen, ob es möglich ist, virtuelle Durcker von richtigen Druckern zu unterscheiden.

Richtige Drucker: Netzwerkdrucker, Drucker, Plotter, eben physikalische Geräte.
Virtuelle Drucker: PDF Drucker, XPS Drucker usw.

27.09.2010 - 15:06 Uhr

@MarsStein, TomLeech: Das braucht ihr mir nicht sagen 😉

27.09.2010 - 09:04 Uhr

Hallo,
wir arbeiten im Moment für einen Kunden an einem Reader für ein Mail System über das hochsensible Informationen versendet werden.

Nun hat sich der Kunde in den Kopf gesetzt, die Anzahl der Druckaufträge reduzieren zu können. Das heißt ich versende eine Mail, die man nur 1x Drucken kann. Über den Sinn kann man sich streiten und tun wir auch, aber da wir uns nicht durchsetzen könne (und auch nicht müssen) versuchen wir immerhin das beste aus dieser Anforderung zu machen.

Ist es möglich virtuelle Drucker im Drucken Dialog zu deaktivieren oder auch mit einem eigenen Dialog nur richtige Drucker anzuzeigen, also zum Beispiel alle PDF und XPS Treiber?

26.09.2010 - 19:26 Uhr

Ich nehme an Quadtree + Herbivores Vorschlage:

Also:
(1) Sichtbare Sektoren ermitteln (Quadtree).
(2) Objekte aller Sichtbaren Sektoren ermitteln.
(3) Objekte aus (2) die sich im Radius befinden ermitteln.

26.09.2010 - 09:29 Uhr

Außerdem ist natürlich ein Quadtree vorteilhaft, dann brauchst du nur die Objekte prüfen die sich auch in den aktuellen Sektoren befinden.

Ist ja eh sinnvoll, z.B. zum Ermitteln der sichtbaren und zu rendernde Objekte.

25.09.2010 - 16:55 Uhr

Hi, ich habe mir auch mal den Code angeschaut:

Was ich am Konzept nicht verstehe: Irgendwie sieht das wie eine Neuentwicklung von WCF aus, zumindest teilsweise.

Warum nicht einfach ein Wrapper über WCF als Schnittstelle zu EBCs und Vereinfachung der Kommunikation?

18.09.2010 - 21:55 Uhr

Ich denke Manhatten Routing = A* mit Manhatten Heuristik.

Ich habe lange gesucht und keine Implementierung gefunden, da meine Teil eines eigenen, kommerziellen Projektes ist, kann ich sie dir leider nicht anbieten. Die Implementierung ist aber nicht so schwierig und wenn man davor plant ist man in 1-2 Tagen fertig.

18.09.2010 - 18:14 Uhr

Ich habe das schon mit A* und Manhatten Heuristik implementiert.

Das Pfd kann auch helfen:
Orthogonal Connector Routing

Eine Bibliothek habe ich nicht gefunden.

17.09.2010 - 20:15 Uhr

Das hat uns die Erfahrung und wohl auch einige Studien gezeigt. Und das wird es auch bei EBC - oder eben nicht. Wer weiß das schon, aber dafür ist es noch zu früh denke ich. Es muss sich ja in der Alltags und Projektwelt noch beweisen und das dauert eben.

17.09.2010 - 16:22 Uhr

Daher wird das mit EBC nichts (in meinen Augen), weil man nicht garantieren kann, das jeder (oder fast jeder) auch wirklich weiß was das ist und wenn auch nur einer nix damit anfangen kann, dann kommt dabei nur murks raus. Das ist schon häufig genug bei OOP so und dabei wissen glücklicherweise schon die meisten (hat ja auch sehr lange gedauert), was OOP ist.

Dann würden wir ja immer noch in den Höhlen hocken und unser Fleisch roh essen, weil das der Standard wäre und noch nicht alle wüssten, dass man Fleisch auch braten kann.

Also das ist eine sehr komische Begründung. Ich kenne kein Unternehmen, indem jeder mit allen Technologien vertraut ist. Softwareentwicklung ist ja nicht homogon, sondern heterogen, gerade wenn es große Projekte sind. Da kommuniziert die komponentenorientierte Silverlight APP mit MVVM Pattern und WCF mit dem ohne OOP geschriebenen PHP Service. Dafür brauchts nur eine Vereinbarung und nicht gleich einen Standard.

17.09.2010 - 16:08 Uhr

Ich weiß zwar ehrlich gesagt nicht mehr um was es in der Diskussion ging, aber ich schließe mich Uwe81 aber an.

Ich hatte bisher in meinen noch nicht ausreichenden Experimenten die Erfahrung gemacht, dass sich Abhängigkeiten nicht eliminieren lassen. Eine logische Abhängigkeit zu entfernen ist sehr schwer, bis gar unmöglich, je nachdem wie das Problem gestaltet ist.

Mein Code durch EBCs hat sich dabei so verändert, dass die Abhängigkeiten von den Komponenten weg, in die Platinen gewandert ist. Das ist ja ganz nett, weil ich die Komponenten leicht testen kann, aber die Komponenten haben sich zu einem Chaos entwickelt.

Viele meiner Komponenten hatten bisher lineare Abhängigkeiten:

A -> B -> C -> D -> ... (A verwendet B, B verwendet C, ...), mit EBCs hat sich das in eine Hierarchie geändert:

P1 -> A, B, C; P2 -> D, E, F; P3 -> P1, P2 (Platine P1 verwendet A,B und C, Platine P2 verwendet D, E, F, ...):

Das heisst meine Abhängigkeiten hatten sich nur verändert und wurden nicht weniger.

Toll fande ich zu Beginn auch die Möglichkeit mich in den Programmablauf zu hängen und z.B. zu Loggen oder Proxies zu schreiben. Das geht zwar auf so elementare Weise in normalem Code nicht, aber ich sehe jetzt keinen Nachteil Interface Proxies (wie in Mockup Frameworks) oder AOP Frameworks verwenden zu müssen. Insofern bringen mir hier EBC keine neuen Features, vll. bisschen einfacher zu verwenden, aber auch die PostSharp Entwickler machne eine super arbeit).

Insofern muss ich sagen, dass auf Begeisterung Ernüchterung folgte, aber ich habe mich natürlich nicht wie du, Ralf, im Detail damit beschäftigt.

27.08.2010 - 22:05 Uhr

Lade dir doch mal die Trial Version des Memory Profilers von RedGate runter:

ANTS Performance Profiler

26.08.2010 - 16:49 Uhr

Genau diesen Ansatz habe ich mit b) verfolgt.

Ich habe aber bisher die Strafe zu niedrig gewählt. Wenn ich sie extrem hoch setze, klappt es einwandfrei. Zumindest in meinen Testfällen bisher, ich hoffe auch für alle anderen.

Mir ist der Zusammenhang noch nicht ganz klar. Aber ich werde mir das noch genauer anschauen. Wenn ich die Kosten zu hoch wähle riskiere ich dabei, dass zu viele Knoten besucht werden. Im Moment wird er durch die hohe Strafe immer geradeaus gehen bis mein Suchraum zu Ende ist und dann erst die erste mögliche Abzweigung weiterverfolgen.

26.08.2010 - 14:43 Uhr

Hi,
ich erweitere gerade für meine Diagram Software das Ermitteln von Orthogonalen Routen für Verbindungen.

Dabei verwende ich A* mit der Manhatten Heuristik. Das funktioniert meist sehr gut und ist bisher ausreichend schnell.

Allerdings kann es manchmal mehrere alternative Pfade geben, die verwendet werden können. Ich suche dabei einen Ansatz beim Path Finding den Pfad mit den wenigsten Richtungänderungen zu ermitteln. Das heisst die Anforderungen sind folgende:

  1. Suche den möglichst kürzesten Pfad.
  2. Wäre dabei die Kanten, die möglichst schnell zum Ziel führen (Manhatten).
  3. Wähle bei 2 alternativen Pfaden den Pfad mit den geringsten Kosten.

Was ich bisher versucht habe:
a) Heuristik anpassen, kann meiner Meinung nach nicht funktionieren, da sich die Werte nicht auf ein den ganzen Pfad beziehen.
b) Kosten anpassen, die werden ja dem Nachfolger mitgegeben, das heisst ein Knoten hätte die Information über die Gesamtrichtungswechsel.

Ansatz b) funktioniert auch teilweise. Manche Situationen werden verbessert, manche die aber ohne Anpassung funktioniert haben, tun dann nicht mehr.

Hat jemand einen Lösungsansatz der am besten ohne Modifikation des A* auskommt (Das heisst Kosten und Heuristik anpassen).

20.08.2010 - 12:01 Uhr

Ich sehe keine direkte Gefahr in Street View selbst, aber die Möglichkeit der extremen Verlinkung von Daten sehe ich schon als recht kritisch an.

  • Amazon kennt deine Vorlieben und Hobbys über deine Einkäufe.

  • Google kennte deine Bewegungen im Internet über Suchanfragen.

  • Google hat E-Mails, Dokumente und Karten-Informationen.

  • Facebook speichert die Bewegung im Internet über Like Buttons.

  • Facebook speichert auch Daten von Kontakten die nicht bei Facebook angemeldet sind.

usw.

Das ist nicht unbedingt was neues, wenn man überlegt, wo man überall auch ohne Internet Daten angeben muss (Bank, Vermieter, etc.), aber neu ist die Möglichkeit Beziehungen zu setzen und aus diesen Beziehungen und Klassifikationen neue Informationen zu bilden, z.B. Kunden die X gekauft haben, kauften auch Y.

Das finde ich noch beängstigend. Noch arbeiten Google, Facebook und Co nicht miteinander, aber das ist vll. nur eine Frage der Zeit.

15.08.2010 - 20:42 Uhr

Ich sehe das wie gfoidl.

Ich würde mir als erstes ein Vektor Format überlegen. In dem es alle benötigten Formen gibt.

Dieses Vektor Format wird dann einerseits in ein Pixel Format für deine Anwendung umgewandelt, des weiteren erstellst du daraus Befehle für deine CNC Fräse, die auch sehr einfach sein können, indem einfach eine Liste von Punkten übergeben wird.

15.08.2010 - 11:08 Uhr

Ich würde außerdem vorschlagen, ein Core Team aufzubauen, dass Frameworks erstellt und allgemein verwendbare Klassen / Bibliotheken erstellt. DRY sollte nicht nur innerhalb eines Projektes gelten.

13.08.2010 - 13:37 Uhr

http://www.yworks.com/en/index.html: yFiles, genial aber sau teuer.
http://www.silverdiagram.net: Silver Diagram: Nur für Silverlight.
http://graphsharp.codeplex.com/: Open Source. Leider nicht mehr weiterentwickelt.
http://quickgraph.codeplex.com/: Open Source: Nur zur Reprensentation von Graphen + Algos, benötigst also eigene Controls.

13.08.2010 - 10:27 Uhr

In die Generic.xaml kommen die Standard Styles der Controls. Das heißt wenn du keine Custom Controls schreibst, deren Template verändert werden kann (!= UserControl) solltest du keine derartige Datei anlegen.

In App.xaml kommen globale Resourcen und Styles. Wenn deine Converter nicht sehr speziell sind, hast du dort einen guten Platz gefunden.

Ok, ich kapiers iwie immernoch nicht X( (Und meinst du mit GLOBAL.xaml die Generic.xaml?)
Wo trag ich denn zum Beispiel:

  • ein Style für ein Control (Button, ListView, ...)
  • ein DataTemplate (für ListViewItem, ...)
  • die Instanz eine Converters
  • die Resourcen mit den Farben (auf die die Controls zugreifen)
    ein?

Hier gilt die Regel von Lars Schmitt. Wird dein DataTemplate nur für ein UserControl oder ein Window verwendet, sollte es dort platziert werden. Sonst in der App.xaml, eben so lokal wie möglich und so global wie nötig.

13.08.2010 - 10:18 Uhr

Ich denke hier DI mit einem DI-Container gleichzusetzen ist durchaus legitim. Ich kenne eigentlich niemand der konsequent DI ohne einen Container betreibt.

13.08.2010 - 09:32 Uhr

Ich schlage mich auch auf FZelle's Seite. Professionelle Softwareentwicklung -> Unit Tests & Modularisierung -> DI

Ich sehe auch null Mehraufwand durch DI, also nutze ich es eigentlich immer. Abhängigkeiten kommen immer vor und Singletons zu schreiben kosten ja auch Zeit. Ich denke man unterschätzt die Arbeit, die einem von einem DI-Container abgenommen wird.