Der Sinn geht mir ab..
Du kannst einen Pen nicht speichern, das bleibt auch so. Du willst also ein Framework, dass dir den noetigen Klimmbimm zur Wiederherstellung einer nicht speicherbaren Resource aus speicherbaren Informationen erleichtert bauen?
Statt manuell halt die Penfarbe zu speichern willst du das mit dem Framework machen?

Wo ist der Mehrwert, wenn du doch nach wie vor manuell etwas tun musst (naemlich in diesem Fall die zu speichernden Properties zu definieren), fuer welche konkreten Faelle siehst du da einen Nutzen (Was ausser einem Pen fehlt dir gerade) und findest du nicht Reflection fuer so etwas - uebertrieben?

Fragen ueber Fragen.

Waere mir auch nicht bekannt.
Aber im Zweifelsfall baust du halt einen Timer. Der kann sich ja gerne nahezu beliebig lange schlafen legen (1min, 5min, 20min, 1h - was immer dir vorschwebt) und dann einen Event feuern?

Sowas wie

lowValue = wParam & 0xffff;

vielleicht? Ungetestet, aber..

Edit: Variablennamen geaendert.

Original von dr4g0n76
Gibt es da schon was in C#? hat jemand von euch da schon was gemacht? Ja..

Um das "Konsolen" Thema abzuschliessen: Console.WriteLine schreibt in die Standardausgabe eines Programmes. Ob das Ergebnis damit von einer cmd.exe/Shell angezeigt wird, in deiner IDE im Ausgabefenster steht, einem anderen Prozess als Eingabe dient oder in einer Datei landet ist dabei nicht deine Sorge. Und einen Unterschied zwischen Konsole und Eingabeaufforderung zu machen ist vielleicht moeglich, hier und fuer diese Belange aber unsinnig.

Original von hulkstar
Die Main() ist immer (!) void!

Falsch.

Damit du nicht selbst googlen/suchen musst:

http://msdn2.microsoft.com/de-de/library/0fwzzxz2(VS.80).aspx
Die Main-Methode kann vom Typ void sein:
...
Sie kann außerdem int zurückgeben:
...

Original von liberado
ja aber er würde dies ja auch in die Console schreiben! nur nicht in die Eingabeaufforderung 🙂
sind ja 2 verschiedene dinge!

In diesem Fall muss ich wohl in meinen Ursprungsdialekt zurueckfallen:
Watt?

Kannst du das erlaeutern? So klingt das nach Unfug.

Du sollst auch keinen String zurueckgeben, sondern ausgeben. Auf die sog. Konsole. Die Klasse die das macht, heisst auch Konsole, nur in englisch. 😉

Schoenes Beispiel. Auch wenn dieser Ansatz ggf. durch Rundungsfehler (double ist immer noch ungenau) unschoen wird und der urspruengliche Beitrag scheinbar eine ganzzahlige Aufteilung sucht.

Und ich behaupte mal tolldreist, dass es IMMER eine sehr dumme Idee ist den Garbage Collector steuern zu wollen. Da geht wohl etwas ganz anderes arg schief..

Der Text ist fuer mich eher verwirrend. Das ganze hoert sich nach nicht viel Code an, warum gibst du ihn nicht preis?

Den ganzen Code nochmal zu quoten war jetzt ja nicht wirklich noetig, er war ja verlinkt.

Wie bereits (vielleicht zu subtil) oben beantwortet: Nein, das ist kein Strategie Entwurfsmuster (oder Strategy Pattern), sondern eine simple Komposition (steht auch in den Kommentaren mehrfach).
Einen schoeneren Namen dafuer kenne ich nicht.

Du meinst den Thread wo unten im Kommentar

//Komposition IDestroy-Implementation Explosion

steht?

zum einen enthält Path.GetInvalidFileNameChars nicht alle ungültigen Zeichen, zum anderen sind die ungültigen Zeichen von Dateisystem zu Dateisystem ohnehin verschieden.

Wegen dem zweiten Punkt gilt ja Punkt eins. Will sagen: Der einzige Punkt ist, dass fuer andere Dateisysteme als NTFS (und ggf. Fat, k.a.) diese Variable unvollstaendig/falsch sein kann.

Fuer die Syntax hatte ich ja die RegExps gebastelt..

Auf unerlaubte Zeichen kannst du es z.B. durch den Zugriff auf Path.InvalidPathChars pruefen. Weitergehend hab ich im Augenblick keine Idee.

Notnagel waere dann vielleicht noch eine (vom OS abhaengige) RegEx fuer absolute/relative Pfade..?

Meine Variable heisst "denkanstoss". Wenn ich das anderes gewollt haette, hiesse sie "komplettloesung".

string denkanstoss = "123456789";
Console.WriteLine(denkanstoss[7]);

Wofuer genau werden die Forms benutzt? Sehen die wirklich alle stark unterschiedlich aus?

Wie waere ein ICustomForm Interface, dass Methoden zur Gestaltung bietet (also das Verhalten eines Dialogs steuert, den du in deiner Hauptanwendung hast)? Zusammen mit einem von dir erstellten (und damit ueber AppDomain-Grenzen uebertragbaren) ICustomFormModel Objekt zur "Datenhaltung" (wo dann die Daten aus dem Formular landen/herkommen)?

Wild geraten, da ich nicht hinreichend viel ueber deine Applikation weiss.

Lange Antwort: Das eine sind die zugrundeliegenden .Net Datentypen/Klassen, das andere sind (C#-/Sprach-)spezifische Keywords/Alias-Definitionen.

Nein

Ich tippe auf Windows Forms und darauf, dass der Timer inzwischen (weil wir ja lustig das Programm anhalten zum Debuggen) halt eine riesige Queue von Messages gefeuert hat und unser Form die dann erstmal abarbeiten will, sobald wir auch nur kurz die Kontrolle zurueck an die WindowProc geben..
Wild geraten...

Danke. 😉

Das ist ja durchaus auch zu einem gewissen Teil persoenliche Praeferenz.

Ich habe Vererbung besonders fuer die "Keine is-a Beziehung" Faelle angekreidet. Is-a koennte man aber durchaus auch durch ein Interface ausdruecken..
Extremfall waere dann ein Interface fuer jede unterschiedliche Funktionalitaet und intern eine Komposition von Implementierungen (oder statische Implementierungen fuer Hilfsfunktionalitaet etc..).

Wie gesagt: Einen Anspruch auf allgemeine Gueltigkeit kann hier ja keiner erheben. Aber je mehr Meinungen man liest, desto besser kann man ueber den eigenen Tellerrand blicken.

Im Java-Umfeld gibt es eine Position/Meinung, dass konkrete Vererbung unnoetig ist.

Gut:

• class A implements I1, I2
• interface I1 : I2

Schlecht:

• class A : B

Konkrete Vererbung, damit meine ich Klassenvererbung (wie sie so gern als das nonplusultra des OO gelehrt wird) im Gegensatz zur Vererbung bei Interfaces, ist haeufig unsinnig (z.B. keine "is-a" Beziehung).

In deinem Fall waere eine Komposition doch ebenso machbar?

http://www.galileocomputing.de/openbook/csharp/kap23.htm

Das klingt so als willst du einen EVENT durchreichen/erstellen. Warum nimmst du dann nicht einen EVENT? 😉

Ich fuerchte ich hab weder das urspruengliche Beispiel noch die Sinnhaftigkeit dahinter verstanden.. Magst du das nochmal erlaeutern, und sei es nur um mich aus meiner Unwissenheit zu reissen? 😉

Ups. Ja, macht Sinn.. Sorry, ich stell mein Hintergrundrauschen direkt ein. 😉

Mich interessiert erstmal, warum du hier "ref" benutzt? Das Array ist ein Referenztyp und als solches wird es sowieso byref uebergeben.
Zum Rest: Nie gebraucht bisher (ich mag es auch nicht, wenn andere Variablen aendern die ich mitgebe). Funktioniert es auch ohne das ref Keyword nicht?

Ein Beispiel (keine Ahnung wie gut) das Google ausspuckt:
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=23F275B1-1A38-4084-834A-6977B5112013

Quoted-Printable ist eine fest definierte Kodierung. Ich wuerde entweder die RFC lesen und implementieren oder die Arbeit anderer verwenden, nicht mal eben was basteln.. 😉

Das unterschreib ich zu 100% und nenn ich eine der besten Definitionen die man dazu bringen kann. Nice.

Niemand lobt bar jeder Realitaet. Ich komme allerdings aus der Java Welt und dort [1] ist der JIT Compiler sehr weit und gut. Das wird auch bei .Net kommen (dass .Net "jung" ist, hatte ich ja weiter oben auch angemerkt) und dementsprechend ist es gut schon jetzt dieses Vorurteil aufzubrechen..
Es gibt Leute die der Meinung sind Java sei langsam. Diese Leute haben
a) keine Ahnung
b) ein Vorurteil aus aaaalter Zeit und sind nicht bereit das zu korrigieren.

Mehr war gar nicht in meinen Aussagen zu finden.

[1] http://en.wikipedia.org/wiki/HotSpot

Edit:

Es werden nichtmal MMX oder SSH Befehle benutzt

Du meinst SSE? Oder wie?

Juchee.. Noch jemand auf meinem Boot. 😉

Ich empfehle bei Recherchen englisch, da ist alles deutlich einfacher zu finden. Wenn man Wikipedia bemuehen will:

http://en.wikipedia.org/wiki/Just-in-time_compilation

Dort ist recht ausfuehrlich und gut ausgefuehrt wie's aussieht. =)

Danke, endlich recherchiert jemand selbst.. 😉
Das ist ja der Punkt: Je laenger die Applikation laeuft, desto geringer ist der Anteil des Overheads an der Laufzeit. Wenn der durch JIT erzeugte Code schneller ist, dann wird er (eine hinreichend lange Laufzeit vorausgesetzt) irgendwann den Abstand durch den nachtraeglichen Kompiliervorgang aufgeholt haben und ist ab da faktisch schneller als nativer Code.
Wie gesagt: Ich propagiere gar nicht, dass es dauernd der Fall waere. Aber man darf sich halt nicht einreden, dass JIT kompilierte Programme immer langsamer sind.

Edit: Smilies aus.. Bah.

Der Punkt war ja (siehe oben), dass JIT mehr Optimierungsmoeglichkeiten aufgrund von mehr Kontext-Informationen hat. Der Overhead den du nennst bleibt. Bei langlebigen Applikationen (Webapplikation, Serverapplikation) ist dieser fixe Kostenpunkt jedoch irgendwann relativiert und es geht nur noch um die reine Performanz von JIT-Resultat gegen native Code.
Ansonsten hast du natuerlich recht..

Und ich habe den Eindruck, du bist auf dem veralteten "native ist immer schneller" respektive "Bytecode-Sprachen sind immer langsamer" haengen geblieben. 😉
Wir koennten jetzt natuerlich drueber streiten oder eine Studie dazu in Auftrag geben..

Original von Traumzauberbaum
Das halte ich für sehr spekulativ. Welche Informationen hat man denn zur Laufzeit, die man zur Installationszeit nicht hat?
Ok, es könnte jemand die Festplatte in einen anderen Computer stecken...

Das ist nicht spekulativ. Du haettest ja vor dieser Aeusserung Google bemuehen koennen. Die meisten Aussagen zu diesem Thema betreffen Java (gibt es nunmal deutlich laenger und ich wuerde argumentieren, dass dort auch noch immer der Markt groesser ist), aber das aendert nichts an der Kernaussage.
Vorher kompilieren kann gar nicht das gleiche leisten wie JIT (ich sage nicht, dass es langsamer sein muss. Fuer schnelle/kurze/nicht interaktive Operationen ist AOT vermutlich immer besser), da es nicht den Context kennt (Denk an Applikationen die Events bekommen. Dein Compiler weiss vorher nicht, dass ein Event davon 3 Mal insgesamt und der andere 42 Mal pro Minute rennt) und auch auf Ausseneinfluesse nicht reagieren kann. JIT kann das gleiche leisten wie AOT und mehr. Man halt als Drawback halt natuerlich die Latenz des kompilierens selbst, aber das gleicht sich je nach Anwendung mehr als aus und hier ist eben auch das Feld der Zukunft (will sagen: Hier kann man noch cleverer werden, bei statischen Analysen geht es nicht viel weiter und alles was da passiert kann JIT dann direkt auch..).

Was hat das GAC mit (native) vorkompilieren zu tun?

Zum Thema:
Die Grundpfeiler wurden oben ja schon genannt:

Der JIT Compiler hat mehr Optimierungsmoeglichkeiten (weil er die Anwendung live baut, d.h. er sieht das Ding in Aktion), vorkompilieren reduziert vielleicht die anfengliche Geschwindigkeit, faellt danach aber vermutlich zurueck (weil der Compiler dort einfach nur statische Analysen des Codes fuer Optimierungen nutzen kann).

In dem Fall (ohne Sinn und Hintergrund, mit Bordmitteln nicht einfach machbar) wuerde ich ohne boesen Unterton vielleicht raten, eine andere Uebung zu suchen 😉

Die einzige mir bekannte Loesung steht in meinem Beitrag.

Den "Ich haeng mich in den Explorer" Ansatz schliesse ich aus, weil dein Beispiel nach einer Art "Verzeichnisschutz" klingt. Dementsprechend interpretiere ich wild und vermute, dass es unlustig ist wenn ich mit dem Total Commander, mit irgendeinem Java Programm (hat eigene Filedialoge) oder der cmd.exe diese Warnung/Nachfrage nicht erhalte.

Andererseits (weil meine Loesung mit dem Minifilter wohl etwas uebertrieben waere): Was ist denn der ZWECK der ganzen Sache?
Sicherheit kann es nicht sein, dafuer hat NTFS ja recht fein granuliert setzbare Rechte..

Klar kann man das machen..

Musst nur einen Minifilter (quasi einen Dateisystemtreiberfilter) fuer Windows schreiben und schon ist das Ganze kein Problem mehr..

Weil du scheinbar die Bedeutung von Parse nicht verstehst.

Parsen bedeutet einlesen/interpretieren. Wenn du einen String hast wie

01.01.2002

und dann C# versuchst zu erklaeren, dass dort ein Datum im Format

Vierstelliges Jahr, Bindestrich, zweistelliger Monat, Bindestrich, Zweistelliger Tag

steht, dann zeigt dir die Runtime keinen Vogel, aber eine Exception.

Wie herbivore schon gesagt hat: Du willst erst eine interne Repraesentation eines Datums (indem du ein DateTime von einem String erzeugst, wie genau das geht hast du eigentlich schon gesehen) und dann dieses Datum in einer anderen Form/Darstellung ausgeben.

Einlesen: Alles was "Parse" im Namen hat ist dein Freund.
Ausgabe: ToString() - siehe erneut herbivores Beitrag - ist dort deine Antwort.

Edit:
Stell es dir wie ein Dreisatz vor.

User -> String
String -> DateTime
DateTime -> String (DB oder was auch immer)

Original von herbivore Verwende besser Cnt\_Data.[i] = i;

Vorausgesetzt, es waere ein Array:
Entweder
Cnt_Data[]
oder
Cnt_Data.SetValue()

Das oben ist (wenn auch nur ein Tippfehler) eine komische Mischform.

Original von MrSparkle
DirectX 10 ist eine gute Sache, was auch immer John Carmack dagegen sagt. Wenn es erstmal von den Grafikkarten unterstützt wird, kann man damit Sachen machen, von denen man echtzeitmäßig bisher kaum zu träumen gewagt hat.

Ohne einen Flamewar starten zu wollen: Voraussetzung dafuer ist

a) das deine Zielgruppe sich komplett mit neuen Grafikkarten eindeckt (teuer..), sonst werden die tollsten/neusten Features nicht unterstuetzt.

b) deine Zielgruppe zu Vista migriert (teuer, rel. unnoetig und zumindest ausserhalb von Eyecandy- und vielleicht ein paar Gamer-Kreisen wohl kaum dieses oder naechstes Jahr zu erwarten. Im Business-Bereich vermutlich auch darueber hinaus nicht. Der XP Support von MS wurde nicht umsonst deutlich - bis 2012 - verlaengert), sonst gibt es kein DX 10.

Insofern ist m.E. nach DX 10 erstmal Unsinn, ausser bei Spass an Bastelei.

DX 10 ist imho fuer gar nichts gut. Wenn du das Netz mal durchsuchst, wirst du u.a. auch dergleichen Kommentare von Jon Carmack lesen. [1]
Es sollte recht safe sein, DX 9 zu verwenden. Zumal ich kein Verstaendnis fuer eine Migration auf Vista habe und damit sicherlich nicht alleine darstelle (dementsprechend glaube ich nicht daran, dass DX 10 zeitnah fuer die Massen verfuegbar sein wird).

YMMV

[1] http://www.dailytech.com/John+Carmack+Speaks+on+DX10+Vista+Xbox+360+PS3+Wii/article5665.htm

Ich wuerde das nicht aufschieben.
Dein Weg ist definitiv unuebersichtlicher und schlechter zu lesen/testen.

Zumal das "einlesen" in regulaere Ausdruecke fuer diesen Fall wohl hinreichend einfach sein sollte. Quasi ein Aufwand im Minutenbereich.

Bei konkreten Fragen (mit Angabe deines aktuellen Versuchs/Fehlers/Problems) kannst du sicher auch mit Hilfe bei derartigen Ausdruecken rechnen. Im Normalfall kann man nach wenigen Minuten die ersten Ausdruecke bilden. Mehr lernen hilft nur bei komplexeren Szenarien und beim "Lesen" der Ausdruecke anderer.. 😉

Und genau darauf hat dir der Bernd liebevoll und detailliert geantwortet.. 😉

Es ist etwas schwer zu lesen, ehrlich gesagt..
Abgesehen von dem Tipp von Borg (wuerde auf jeden Fall sehr viel uebersichtlicher) haette ich erstmal drei Tipps um das ganze aufzuraeumen:

strDir02 = strDir01 + "\\" + DirArr02[i].ToString();

koennte auch

strDir02 = Path.Combine(strDir01, DirArr02[i].ToString());

sein. Damit sparst du dir die ganzen haesslichen + Geschichten und bist immer sicher, dass da auch nur ein \ zwischen landet.

Ansonsten wuerde ich vorschlagen Variablen dann zu deklarieren, wenn du sie brauchst. Vorher sind sie unnuetz und maximal zusaetzliche Fehlerquellen. Einen Benefit gibt es nicht.

foreach (object str01 in DirArr01)

und

for (int i = 0; i < DirArr02.Length; i++)

sollten eigentlich das gleiche machen (ueber ein Array von DirectoryInfo zu laufen) und machen es dabei komplett anders und beide Male recht seltsam. Was spricht gegen

foreach (DirectryInfo dir in DirArr01)

Sorry, ich will dir nicht auf den Schlips treten. Aber auf Anhieb seh ich in dem Gewusel den Fehler nicht und nachstellen kann ich eine 30minuetige Kopiererei auch gerade schlecht. Bau das doch mal uebersichtlicher, vielleicht stoesst du dabei auf die Ursache.

Original von Programmierhans

Original von kleines_eichhoernchen
oder probier mal Application.Exit

Also mit dem kleinen Holzhämmerchen.... Es gibt da auch noch den grossen Holzhammer ... Environment.Exit

Aber nicht dass jetzt jemand daraus schliesst ich fände es eine gute Idee Anwendungen mit dem Hammer zu schliessen. 8)

Environment.Exit ist was fuer Bluemchenkinder.
Environment.FailFast() ist das richtige Werkzeug..