Forenbeiträge von Arithmetika Ingesamt 69 Beiträge
Hallo Abt,
das dachte ich auch, habe ich auch ausprobiert, führte jedoch zum gleichen und falschen Ergebnis.
Gruß
Arith
Hallo,
ich möchte folgenden Output erzeugen:
<CreateMsisdn xmlns="http://asdf">
<ValidFrom >0001-01-01T00:00:00</ValidFrom>
</CreateMsisdn>
Meine Klasse:
[Serializable]
[XmlRootAttribute(Namespace = "http://asdf", IsNullable = false)]
[XmlTypeAttribute(AnonymousType = true, Namespace = "http://asdf")]
public class CreateMsisdn //: MsisdnBase
{
public DateTime ValidFrom { get; set; }
}
das Ergebnis der Serialisierung ist jedoch:
<CreateMsisdn>
<ValidFrom xmlns="http://asdf">0001-01-01T00:00:00</ValidFrom>
</CreateMsisdn>
Warum steht der Namespace im Child und nicht im Root, wie eigentlich angegeben?
Wie Typen intern bei dir im code heißen ist in jedem fall egal. Wie diese nach außen hin bekannt sind, kannst du im allgemeinen steuern. Notfalls baust du dir für die externe repräsentation einen Wrapper.
Daher die Frage: wie sieht deine Schnittstelle denn aus? Wie kommunizierst du genau?
Das war dasselbe, als OOP die Strukturierte Programmierung ersetzt hat. Einen essentiellen Punkt scheinst du da außer acht zu lassen. Mit Hochsprachen konnte man schneller zum Ziel kommen. Daher hatte man einen spürbaren und vor allem messbaren Mehrwert. EBC bietet das nicht.
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.
Ich dachte mir schon, das jemand mit diesem Argument kommt.
Würdest du auch demjenigen folgen, der behauptet, das das Fleisch viel besser schmeckt, wenn man dabei zeitgleich von der Klippe springt?
Fakt ist: mit EBC kann man nichts neues machen, was man nicht vorher schon produktiv und gut machen konnte. Man gewinnt durch EBC nichts in meinen Augen. Das einzige, was man momentan bei der verwendung von EBC in kauf nimmt, ist mehr Risiko durch Unkenntniss mehrerer als im vergleich zu OOP.
Ich kenne kein Unternehmen, indem jeder mit allen Technologien vertraut ist.
Habe ich ja auch nciht behauptet. Ich denke nur, das wenn man mit c# programmiert, das man davon ausgehen kann, das die meisten OOP kennen und wir reden hier doch über EBC in c# oder?
Wenn ein Prozessschritt auf den Erfolg zweier anderer warten muss, dann ist das mit IBC und EBC gleich.
Das ist vollkommen richtig. Jedoch habe ich etwas anderes behauptet. Ich meinte, das die Komponente oder der besagte Prozessschritt anders reagieren soll, wenn die jeweiligen Vorbedingungen in bestimmten Konstellationen erfolgreich oder nciht erfolgreich waren.
Das sind so die typischen kaufmännischen Abläufe.
Was soll ich dazu sagen, Arithmetika?
Ich habe dich nicht direkt angesprochen. Daher habe ich auch keine Reaktion erwartet. Ich habe meine Meinung kundgetan und begründet, warum ich diese Meinung habe.
Dass auch EBC wieder keine silver bullet ist? Klar. Habe nie das Gegenteil behauptet. Dass EBC OOP und IBC nicht überflüssig machen? Klar. Habe es nie anders gesagt.
ACK. Habe ich auch nicht behauptet.
Meine Kernaussage ist: Wenn man wirklich gut und Produktiv sein will, dann muss man sich auf einen etablierten Standard konzentrieren und darin möglichst Perfekt werden. Kein Projekt der Welt kann es sich leisten, vor der ersten produktiven Zeile Code alle Entwickler auf eine Schulung zu schicken und erstmal ein oder zwei mittlere Lernprojekte durchzuführen, um nachher eine relativ saubere Lösung zu haben.
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.
Ich persönlich habe mich ein wenig mit EBC 1.0 beschäftigt und schon damals hatte ich dabei das Gefühl, das das so ähnlich wie mit den c++ templates & co ist.... abgefahrene sache die niemand wirklich braucht.
Oder wie es Joel formuliert hätte: Don't Let Architecture Astronauts Scare You
Ebc ist für mich ein set von Abstraktionen. Im sinne von "Aktion wird durch Platine abstrahiert und die komponenten erledigen die Schritte". Hierzu fällt mir dann aber wieder etwas von Joel ein: The Law of Leaky Abstractions
Manchmal muss eben eine Komponente von einer oder anderen mehreren wissen oder eine komponente muss mal eben wissen, das vor ihr schritte 1, 2 und 3 erfolgreich oder nur teilweise erfolgreich durchgelaufen sind und dann wird es auch mit EBC haarig.... dann fängt man an statusobjekte mitzuschleifen und validationsmechanismen vor jedem schritt aufzurufen, welche am besten in einer Validationskomponente untergebracht sind, welche aber auch je anch status andere mechanismen fährt usw...
Oder man bietet n eingänge je nachdem welche und wieviele schritte vorher erfolgreich durchgelaufen sind, wobei man dann wieder ein exponenzielles wachstum zur komplexität hat und dann abstrahiert man das ganze wieder teilweise in eine statusobjekt und nlogn eingängen, und ist glücklich, das man nur eine woche gebraucht hat um mit den unerwarteten sonderfällen der BWL leute zurechtkommen zu können....
Da neige ich doch eher in diese richtung: The Duct Tape Programmer
(ja, ich bin einer seiner fans 😉 )
Ich wäre allerdings jetzt auch nicht bereit, einen oder mehrere Tage zu opfern um in eine andere Stadt zu fahren und öffentlich einen Wettstreit auszutragen, welches ein ausgedachtes Problem in möglichst kurzer Zeit lösen soll. Das ist Realitätsferner als ein Drogentrip.
(Betonung liegt auf das Zeit opfern... nicht auf die Fahrt selbst)
- sind das keine Properties in deinem Struct sondern Felder.
- sind die Felder per default "private". Du musst "public" explizit schreiben.
Dann solltest du allerdings die Anwendung in Silverlight schreiben und diese dann in WPF portieren, da Silverlight ein Subset aller möglichkeiten von WPF ist. Außerdem kannst du dich darauf einstellen, das du bei gemeinsam verwendeten Dateien (silverlight&wpf) Präprozessordirektiven einbauen musst, da bei den beiden nicht alles gleiche, was vorhanden ist auch gleich verhält.
Wie es bei einer WPF Browserapp aussieht kann ich dir nicht sagen. Vermuten kann ich allerdings, das es Probleme beim zugriff auf lokale Dateien geben könnte, da im Browser alles üblicherweise in eine Sandbox läuft....
Picturebox hat bereits aktivierten Doublebuffer. Die Ursache des Flackerns kannst du somit so nicht bekämpfen.
Siehe "Extension methods"
kaum bis nein.
Einfacher ist es die GAC version zu löschen (Adminrechte benötigt) und ggf mit der neueren zu ersetzen (und hoffen das keine breaking changes drinn sind).
ich kann dir deine Frage leider nciht beantworten aber ich kann dir sagen, das du dein Array unbdeingt auf dem Heap Pinnen solltest, ansonsten verschiebt dir der GC das array wie es ihm beliebt und dein IntPtr stimmt dann ggf nicht mehr.
fügst du die Zahl programmatisch oder händisch ein?
sorry aber eine Queue ist nicht Threadsafe und daher ist Synchronisation und Locking notwendig.
Also denkbar wäre auch ein Webinstaller, der die Setup.exe herunterlädt und ausführt und nach dem beenden des Prozesses die Datei löscht.
Das ist zwar nicht ganz so sicher, um die verbreitung der Setup.exe zu verhindern aber es ist schnell und einfach implementiert.
Hallo,
nein das geht nicht. Wenn du auf dem Clientsystem eine Datei ausführen willst, musst du sie auch runterladen. Wenn diese etwas installieren soll, darf diese nicht in einem Browser ausgeführt werden.
Es gibt aber 2 Alternativen:
Ein ActiveX installiert die Anwendung:
Das ist ein großes Sicherheitsproblem. Im Intranet mit eingestellten Trusted Sites kein Problem aber im Internet würdet ihr damit nur Kunden verärgern, da die Browser sowas per default nicht zulassen (sonst könnte ja jede Website Schadcode installieren).Ein Webinstaller:
Ein einfacher ThinClient, der nichts anders macht, als die eigendlichen Daten herunterladen und installieren. Der Vorteil ist, das die Webinstaller.exe das zu installierende Programm nicht enthält, sondern immer für das Installieren herunterladen muss.
Nichts für ungut aber "dezentraler Server" ist etwas komplett anderes als ein zentraler Server auf einem vServer oder normalem Server.
Was für Möglichkeiten hat C# denn, um Datenquellen möglichst so flexibel anzusprechen, dass man diese später mit möglichst wenig Aufwand austauschen kann?
Viele. Das obliegt dir, ob du diese nutzt. Eine absolut strickte und saubere Trennung zwischen Datenzugriff und dem Rest der Anwendung ist hier Pflicht.
Meine Traumvorstellung wäre das ich die HTTP/XML Datenquelle später bequem durch eine lokale Sqlite Datenbank ersetzen kann
Evtl wäre das hier ein Anwendungsfall von Linq2Xml und Linq2Sql. Ich bin mir aber nicht sicher, inwiefern ein Switch der beiden Aufwände bereitet.
Da ich Aufgrund des Rechtesystems nicht direkt mit der Datenbank arbeiten kann wollte ich PHP Skripte als Zwischenschicht einsetzen, welche sich um die Authentifizierung kümmern. Als Datenformat würde ich XMLs nutzen. Der C# Client würde sich beim Start eine Session vom PHP holen und diese für alle Anfragen an das PHP nutzen.
Ich persönlich würde das mit WCF machen. Da hast du weitaus mehr möglichkeiten bei der Transportschicht und Sicherheitsschicht und das ohne zusatzaufwand.
Zudem könntest du dann die WCF Serveranwendung auch ohne weiteres auf dem Clientsystem laufen lassen, wenn der Kunde das so wünscht, ohne deine Clientanwendung oder Serveranwendung anpassen zu müssen.
Ich weiß, das man mit DirectInput den output der Soundkarte umleiten kann. Sogar direkt als Input verwenden kann (um z.B. lieder über Voice zu streamen damit Mitspieler von Ego-Shootern wahnsinnig werden). Ich weiß aber nicht ob du da differenzieren kannst. Also das die Outputs separat behandelt werden.
Suche mal nach "Direct Input Redirect"
Das Verwenden von Sockets hat garnichts mit Programminstanzen zu tun. Du kannst in einer Programminstanz n Sockets aufmachen. Irgendwie ist dein Statement äußerst verwirrend.
bei der OpenNETCF klasse muss man aber aufpassen, das es nicht zu verhungernden Threads kommt, da dort nicht sichergestellt ist, das die threads wie im .net Framework in einer festgelegten Reihenfolge aufgerufen werden.
edit: und wenn man die Sourcen des OpenNETCF Frameworks betrachtet, so entdeckt man, das die Monitor Klasse mit dem genannten AutoresetEvent arbeitet....
•Hinzufügen des einen Projektes als Referenz: Das "alte" Programm ist nur noch mithilfe des neuen Programmes lauffähig, kann aber auch von anderen Programmen verwendet werden
jain. man kann auch eine exe hinzufügen und als dll verwenden.
@Lukas B.:
mir scheint, das nicht du das programmiert hast. Hört sich eher nach Copy&Paste oder Beispielprojekte aus dem netz ziehen an.... denn wenn du das selber gemacht hättest, dann wüsstest du, wie du beides einfach vereinen kannst....
Generell würde ich den weg des hinzufügens als DLL realisieren und dann die DLL so modifizieren, das diese ein Event anbietet, welches die benötigten daten nach außen liefert.
egal ob dll oder exe. es ist eine assembly und die CLR kann beides laden und sucht sogar explizit nach beiden, wenn er was laden muss. Er hat also beim suchen festgestellt, das er diese assembly bereits gladen hat und hat versucht zuzugreifen, was aber gekracht hat.
@Th69:
ganz sicher nicht. Wegoptimiert wird nur was 100% weg darf. public static darf nciht weg.
Häng dich mal ins assemblyresolve ereigniss deiner appdomain und schau dir mal genauer an was da schief läuft... evtl ist es ja eine abhängigkeit oder aber es ist ein geändertes interface, das nicht nachgezogen wurde.
Nein das ist nicht so. Das Bild enthält 35 Frames mit jeweils 0,03 Sekunden zeitabständen. Aus mehr besteht das Bild nicht.
Da ist ein Fehler in Frame 13. Möglich, dass das die Ursache dafür ist, das die meisten Menschen es gegen den Uhrzeigersinn rotieren sehen... ansonsten ist das ein nettes Gif 😃
wenn du von Programm und Unterprogramm sprichst. Meinst du da eigenständige Prozesse?
Und generell gilt hier: versuche es zu lösen und bei problemen stell konkrete fragen. "kan mir mal jemand helfen" ist keine konkrete frage zu einem konkreten problem.
ja, aber warum hast du dann nicht einfach weitergelesen, was außerdem noch notwendig ist?
Dann verwende besser ein Delay, den du beim Resize startest und immer wieder neu resettest und wenn der einmal doch abläuft, machst du ein invalidate. Das ist bei weitem ressourcenschonender als ein Timer der jede sekunde auf eine änderung prüft.
Du hast mich falsch verstanden. Du sollst dir nicht die Hashes aller dll´s aller Spiele merken und für die Prüfung verwenden... Das ist viel zu aufwändig...
Du sollst Hashes aus den geladenen Dll´s generieren und mit denen der anderen spielteilnehmern vergleichen. Bei unstimmigkeiten wurde definitiv manipuliert, da die spiele schon von sich aus auf Versionsgleichheit prüfen.
Andere Cheats hängen sich wiederum nicht an das Spiel sondern Pflanzen sich wo anders ein.
Wenn sie nicht das Spiel selbst manipulieren, dann sind es auch keine Cheats. Wenn sie das Spiel auf unerlaubte weise manipulieren, dann müssen sie per Dll-Injection arbeiten. Und das kann man ohne weiteres aufdecken.
Eine weitere möglichkeit bietet die manipulation oder den austausch bestehender Dll´s und das lässt sich mit der genannten Hash-Vergleichsmethode auch aufdecken.
Eine dritte möglicheit sind die Manipulation von z.b. Lua-Scripten usw... da wird es schwieriger, da du hier genau definieren musst, welche dateien für einen Hashvergleich relevant sind.
Ja, das wirst du in GDI+ auch nicht wirklich abstellen können, da du wegen dem Farbverlauf die komplette Zeichenfläche neu zeichnen musst (Farbverlauf verschiebt sich ja...). Alternativ kannst du während des Resize vorgangs die Hintergrundfarbe auf eine solide Farbe ohne Verlauf stellen und nach dem Resize den Farbverlauf wieder setzen. Das erfordert ein wenig Code, ist aber gut machbar.
Ansonsten musst du auf WPF ausweichen, um das flüssig hinzubekommen.
Du musst im Konstruktor des abgeleiteten Controls mit SetStyle die Option ResizeRedraw auf true stellen oder aber im abonnierten Resize Event ein Invalidate auf die gesamte Zeichenfläche ausführen.
wenn es sich um Lan´s handelt, so kannst du aus dem aktuellen spiel alle dateien abgreifen und einen hash für jede datei bilden. Das selbe machst du für die geladenen dll´s (speicherabbild) und vergleichst diesen mit denen der anderen spieler. wenn es unterschiede gibt, dann cheatet jemand. wenn nicht, dann cheaten alle oder keiner.
Starte beim singleclick einen Timer und werte nach ablauf des Timers aus, ob es einen zweiten click gab. Wenn nein, feuerst du ein SingleClickEvent ansonsten ein DoubleClickEvent.
@Equilibrium:
es ist keine Endlosschleife. Die Datenmenge ist das erschlagende. Hier wird ein Dataset mit 300.000 Datensätzen a 140 Spalten befüllt.... da knallt es schon beim einlesen wegen der schieren Anzahl an objekten.
Die Art und Weise wie du die Daten holst ist falsch. Lade immer nur einen begrenzten Satz an Daten und schreibe diesen in den Stream. Dann hole den nächsten Satz usw..
SortedList (und auch SortedDictionary) macht nur Sinn, wenn ich Daten zum Beispiel aus einer Benutzereingabe heraus hinzufüge und die Daten anschließend wieder sortiert ausgeben lassen möchte
Genau dann, amcht SortedList keinen sinn. Denn genau dann verwendet man lieber eine List und ruft vor der ausgabe List.Sort auf.
SortedList macht genau dann sinn, wenn die Auflistung immer und zu jeder Zeit Sortiert sein muss. Unabhängig davon wann und wie Elemente hinzugefügt/entfernt werden. Zugegeben, diese Anforderung hat man nciht oft aber wenn, dann ist es gut, das es diese Auflistungsform gibt.
Eine Silverlightlösung wäre:
The simplest way to detect DoubleClick in Silverlight
Entweder du vergibst als ID eine GUID oder aber du verwendest eine statische Variable als Autoincrement-zähler für die Id-Vergabe.
Du verwendest hier eine SortedList für massives hinzufügen unsortierter Daten. Warum unsortiert? Weil strings eine andere Sortierung haben als reine Integers. Da du den integer hochzählst und zum string machst, erreichst du eine unsortierte reihenfolge. z.B würde die liste für 10, 11, 12, 101, 111 so aussehen:
10
101
11
111
12
Die SortedList hat aber ein großes Problem beim hinzufügen von unsortierten Daten. Siehe: [Übersicht] .NET Framework 2.X Auflistungen (Collections) punkt 9
Alternativ gilt für unsortierten daten: [Übersicht] .NET Framework 2.X Auflistungen (Collections) punkt 8
Hier im Forum gibts schon das, und JAck30lena schreibt mit Verweis auf inlining von besserer Performance...
Das gilt vor allem für rekursive Methoden. Desto mehr Rekursion, desto größer der Gewinn.
Nur ist es bei der Bildverarbeitung eher selten der Fall, das man Pixelweise oder Blockweise rekursiv arbeitet, da eine Lineare vorgehensweise perfomanter ist. z.b. weil man durch die 2d Ausdehung bei z.b. Füllalgorithmen prinzipbedingt keinen Pixel doppelt bearbeitet. Klar kann man eine Liste der besuchten Pixel mitschleppen aber dann kann man gleich einen linearen Algorithmus verwenden. Außerdem ist der ständige Check, ob Pixel xy bereits besucht wurde performancefressender als die gleiche lineare Vorgehensweise, wo prinzipbedingt die abgelaufenen Pixel nicht nochmals überprüft werden müssen.
Eine bereits umfangreiche und schnelle Lib in C# gibt es hier: LowLevelGraphicsLibrary
Das einzige, worauf man achten soll ist, daß man für öffentliche Member nur CLR-kompatible Datentypen verwendet.
CLR kompatibel sind prinzipiell alle Datentypen. Egal ob C# F# VB.NET... sonst könnte man sie ja nicht verwenden. Ich vermute daher das du CLS-Complient meinst.
F# hat da ein paar Datentypen, die das meines wissens nicht sind. Aber das merkt man schnell, wenn man in der Assemblyinfo das entsprechende Attribut setzt. Dann meckert der Kompiler sofort.
Was dein Vorhaben betrifft, so wirst du dich bei einer Grafiklib in ein für C# untypisches Gebiet vorwagen müssen, wenn du perfomant sein möchtest: Pointer
Schau dir die oben verlinkte Lib an 😉
edit:
C# erzeugt IL-Code. F# erzeugt IL-Code. Mit dem richtigen Know-how wird man wohl (fast immer, bis auf TailRecursion und solche sachen) ein äquivalentes Programm schreiben können.
Der .NET x64 Jitter macht TailRecursion auch für C# MSIL.
Wenn man ein Raid system mit redundanz einrichtet, will man seine daten ausfallsicher verfügbar haben. Da ist jede wahrscheinlichkeit, die diese Verfügbarkeit gefährdet schon zu viel.
Ich muss wieder zugestehen (nicht mein Tag heute...), das ich mich unpräzise ausgedrückt habe. Ich hätte schreiben sollen:
Man hat Leidvoll feststellen müssen, dass Festplatten gleicher Bauart und gleicher Charge bei gleicher Auslastung, eine erhöhte Wahrscheinlichkeit haben, nahezu Zeitgleich, teilweise nur in wenigen Sekunden differenz, kaputt zu gehen.
z.b:
Da bei der Neu-Einrichtung eines Raid-5 häufig Festplatten gleichen Herstellers, Modells, sogar Fabrikations-Charge verwendet werden, ist ein Ausfall einer zweiten Festplatte kurz nach dem Ausfall der ersten recht wahrscheinlich.
--> quelle
Wir haben auch in der Ausbildung gelernt, das man bei einem Raid optimalerweise nicht die gleiche Charge verwendet. Gleicher Hersteller und Baureihe ist ok aber nicht die gleiche Charge.
Sry, dass ich das mit der Charge in meinem Beitrag weiter Oben nicht explizit erwähnt habe. Ich hätte mich exakter ausdrücken sollen.
siehe: klick
Es gibt haufenweise Info im Netz.
Eine Datenbank würde auch ich empfehlen. Das Anzeigen so vieler Daten ist ohnehin nicht empfehlenswert, da ein Mensch so viel nicht erfassen kann. Also musst du die Daten vorher Grupperien/Filtern/Sortieren und genau in sowas sind Datenbanken richtig gut.
Man hat Leidvoll feststellen müssen, dass Festplatten gleicher Bauart bei gleicher Auslastung nahezu Zeitgleich, teilweise nur in wenigen Sekunden differenz, kaputt gehen.
Bei einem redundanten Raidsystem sind beide Platten relativ gleich ausgelastet.
Ich habe den Thread sehr wohl gelesen. Ich denke aber das du string.Format(...) nicht verstanden hast.