Forenbeiträge von DarKlajid Ingesamt 386 Beiträge
Grob..
string string1 = "ifsdjik";
string string2 = "ifsdjdik";
int firstDiff = GetDifferencePos(string1, string2);
int diffLength = 0;
if (firstDiff > -1) {
if (firstDiff >= string1.Length) {
diffLength = string2.Length - firstDiff;
} else if (firstDiff >= string2.Length) {
diffLength = string1.Length - firstDiff;
} else {
for (int i = firstDiff+1; i < string1.Length; i++) {
if (string1[i] == string1[i]) {
diffLength++;
}
}
}
}
Komplett ungetestet. Kann off-by-ones enthalten.. Kaffee?
Wenn ich mal ganz frei NiNs Loesung editiere: Ich wuerd's leicht abgewandelt machen.
string string1 = "ifsdjik";
string string2 = "ifsdjdik";
Console.WriteLine(GetDifferencePos(string1, string2));
int GetDifferencePos(string left, string right) {
int hereIsADifference = -1;
if (left.Length < right.Length) {
hereIsADifference = left.Length;
} else if (right.Length < left.Length) {
hereIsADifference = right.Length;
} else {
for (int i = 0; i < left.Length; i++) {
if (left[i] != right[i]) {
hereIsADifference = i;
break;
}
}
}
return hereIsADifference;
}
Original von little_budda
Ja klar.
Danke für die Antwort.
Wusste nicht das nur Wissende das Forum nutzen dürfen.
Nein. Die Antwort als boeswillig zu sehen ist auch falsch. Ich moechte dir vielmehr damit aktiv Hilfe zur Selbsthilfe leisten (Dazu gibt es die schoene Gleichung, dass man jemandem lieber das angeln beibringen sollte als ihn mit Fischen zu beliefern).
Dadurch lernst du deutlich schneller als durch erneute/haeufige Fragen hier und im Umkehrschluss fragst du hier nicht Fragen, die das Buch schon laengst und ausfuehrlich beantwortet.
Was daran kannst du mir jetzt uebel nehmen?
Original von little_budda
Was bitte ist ein Konstruktor?
Mit dieser Aeusserung hast du dich leider fuer die "Lies doch erstmal die Grundlagen, zum Beispiel das hier im Board verlinkte (kostenlose) Buch" Antwort qualifiziert.
Original von blackcoin
Frage: warum CSV Datei in die Datenbank(dann bringt die Datenbank doch kaum vorteile)
Entweder ich verstehe dich falsch oder du den Originalbeitrag nicht, meiner Meinung nach..
Die Idee war Exceldaten als CSV Dateien zu speichern/exportieren und aus diesen die Daten in die Datenbank zu packen (weil das ein 'normales' Format fuer einen Massenimport ist). Damit spart man sich die OleDB Geschichte und die Idee eine Excel-Tabelle als DB anzusprechen..
Bei dir liest sich das so, als wollte der gute Mann CSV Daten in einem Datenbankfeld speichern, was jawohl nicht der Fall ist.
Original von VizOne
Inwiefern soll denn MD5 "geknackt" sein?
Insofern, als dass man (eigentlich seltene) Kollisionen unter gewissen Umstaenden/mit etwas Aufwand erzwingen kann. Resultat:
md5sum DeinProjekt.exe
und
md5sum MeinTrojaner.exe
liefert das gleiche Ergebnis..
z.B. IsolatedStorage.
Nicht boes gemeint, aber kostet es dich mehr als 5min mal eben die 6 Zeichen (einzeln) als values zu testen und damit festzustellen woran es liegt/ob die Hypothese stimmt?
Edit: Ich konnte nicht zaehlen..
Und was genau glaubst du akzeptiert WriteLine() da als Parameter? Siehst du in der MSDN eine Ueberladung von WriteLine() die eine Liste nimmt?
Moeglich, dass du eine Browserkomponente (IE, Gecko#) einbinden kannst und darueber zum Ziel kommst. Ansonsten:
- Die Extraktion wuerde man natuerlich nicht mit .indexOf() machen, sondern in einer einzigen regex
- Verschachtelte <> sind in HTML nicht erlaubt
- Die Methode ist fehleranfaellig, egal wie du daran gehst, aber ich wuerde es so loesen:
Extraktion des Textes innerhalb von <body> (denn du willst ja nur den sichtbaren Text auf der Seite):
body = Regex.Replace(htmlText, @".*?<body.*?>(.*)</body>.*", "$1", RegexOptions.IgnoreCase | RegexOptions.Singleline);
Entfernen aller tags in diesem String:
text = Regex.Replace(body, @"<[^>]*>", "", RegexOptions.IgnoreCase | RegexOptions.Singleline);
Es bleibt ein Problem falls jemand ein unsichtbares Tag mit Inhalt verwendet.. Z.B. <script> oder dergleichen.
Disclaimer: Ungetestet und ich hafte nicht =)
Kannst du mal Auszuege aus der Datei zeigen/die XPath Ausdruecke (vereinfacht) angeben? Oder einen Testcase? So ist es etwas haarig zu lesen und an einigen Stellen ein Ratespiel..
Gruesse,
Ben 😉
- Was hat das mit Datentechnologien zu tun?
- Was genau (im Sinne von exakt) willst du machen? Welche Zeichen zaehlen? Nur Buchstaben? Alles ausser Whitespace Zeichen? Jedes Zeichen (auch Tabs, Spaces)? Interessiert dich nur der angezeigte Text oder auch die Formatierung (newlines) der gerenderten Seite?
Original von MrSparkle
Units sind meiner Meinung nach am ehesten mit Assemblies vergleichbar...
Da bin ich neugierig: Warum das? Oder meinst du dcu Dateien (also kompilierte Units, "Delphi Compiled Units")? Vielleicht muesste man erst verstehen was der OP meinte. Units sind fuer mich erstmal nichts weiter als sowas:
unit Foo;
interface ..
implementation ..
//... Code
Original von no1gizmo
das funktioniert nicht.... auch nicht, wenn -> string kill = " ";
Das Leerzeichen ist dann immer noch in str2, so als wäre die Methode "Trim" einfach kaputt
Nein, nicht kaputt. Nur das falsche Tool fuer das was du machen willst (scheinbar alle diese Zeichen loeschen).
Original von no1gizmo
Bin ich blöd? Ja, ich kümmere mich lieber morgen drum, heute bin ich perplex.
Danke für die Antworten.
Haettest du meinen Text gelesen (aus der MSDN kopiert), dann wuesstest du warum. Fuer diejenigen, die angelsaechsische Texte gern ignorieren hier die deutsche Umformulierung:
Trim() schneidet von vorn und von hinten alle Zeichen des Char-Arrays ab, bis es auf das jeweils erste Zeichen trifft das nicht darin vorkommt.
Der zweite Satzteil ist das, was dich gerade aergert. Und warum hast du nicht die Antwort von marsgk genutzt?
Zitat MSDN
The Trim method removes from the current string all leading and trailing characters that are in the trimChars parameter. Each leading and trailing trim operation stops when a character that is not in trimChars is encountered. For example, if the current string is "123abc456xyz789" and trimChars contains the digits from '1' through '9', the Trim method returns "abc456xyz".
Edit: marsgk hat dir die Antwort geschenkt. 😉
Edit2: Verdammte Axt. Kann man nicht eine Voreinstellung fuer "Ich will keine Smilies" basteln?
Es gibt natuerlich auch die (Mysql-spezifischen)
SHOW DATABASES;
SHOW TABLES;
aber der Weg uebers Schema waere deutlich sauberer (sofern das klappt, ich hatte noch nie den Anspruch).
Aehm.. Meine Delphi-Erfahrung hilft mir jetzt nicht den Unterschied zwischen Unit und Datei (.pas) zu sehen.. Und du kannst auch mehrere .cs Dateien erstellen, ja..
Der Rest (Was fuer Hierarchien gibt es, wie teilt man Code auf und wie kann man Design/Funktion trennen) wurde weiter oben ja schon schoen praesentiert.
Boese Zungen wuerden jetzt einen Zusammenhang zwischen "Kein SP2" und "WGA und Konsorten" vermuten. Aber meine Zunge ist ja nicht boese... 😉
Original von juetho
Du musst unterscheiden:Referenz bezieht sich auf die Assembly, d.h. in der Regel DLL.
using bezieht sich auf einen passenden Namespace.Beide Beziehungen müssen berücksichtigt werden; vielleicht liegt darin Dein Problem. Jürgen
Original von chaosgeist
...obwohl der Namespace doch explizit eingebunden wurde - und auch unter den Verweisen der Projektmappe aufscheint.
Ich hoffe mit dem hier genannten Satz meinte der Threadersteller, dass er eben schon eine Referenz im korrekten Sinne eingebunden hat.
Erneut: Wie lautet denn die genaue Fehlermeldung?
Der Code von dir macht keinen Sinn: Die Formate von denen du redest sind Strings. Eine Datenbank akzeptiert im Grunde genommen immer die ISO-Norm (YYYY-MM-DD) und ansonsten ist es abhaengig vom locale - bei dir nun vom englischen.
Ein .Net DateTime ist eine interne Repraesentation eines Zeitpunktes und hat nichts mit diesen Strings zu tun. Ob du nun "23.03.2007, 15:15:15" oder "um 15:15:15 Uhr am 23. Maerz 2007" schreibst - das DateTime Objekt waere das gleiche. Es ist nur eine Formatierung.
Damit kommen wir auch zur Loesung.. DateTime.ToString() ist ueberladen. Schau dir das mal an..
Hier haben diverse Leute schon gejammert, dass Vista Schreibvorgaenge ins Applikationsverzeichnis umbiegt/verhindert.
Von der Tatsache abgesehen, dass es im Regelfall immer eine schlechte Idee ist ins Anwendungsverzeichnis schreiben zu wollen. Das sollte fuer normale User sowieso nicht beschreibbar sein und kann ggf. auch mal eine (readonly) Netzwerkfreigabe oder dergleichen sein.
Wenn dein Verzeichnis schon so lustig "Temp" heisst, warum gefaellt dir nicht Path.GetTempPath() oder Path.GetTempFileName(), je nach deinen Anforderungen?
Nochmal zum mitdenken:
Du willst fuer die Kombination aus Zahl1 und Zahl2 immer nur eine Zahl3 speichern?
Dann waere es wohl eher eine Zuordnung im Sinne von Dictionary<ZweiZahlen, int>, oder?Falls ich dich oben richtig verstanden hab (und falls bei dir diese Objekte fachlich immer gleich sind, wenn die zwei Zahlen gleich sind), dann koenntest du ggf. ueber .Equals() etc. dafuer sorgen, dass du diese ZweiZahlen Klasse auch als brauchbaren Dictionary Key nehmen kannst..
Normalerweise postet man dann noch woran es lag, um anderen mit dem gleichen Problem eine Loesung zu nennen.
Meine Vermutung ist - wenn ich die eigentlich recht sprechende Fehlermeldung lese - dass deine Tabelle "Speichern" nicht vier Spalten hat(te).
Was ist die Einstellung "Lokale Kopie" dieser Referenz?
Original von Traumzauberbaum
Dein Argument, warum XML nicht als Standardlösung taugt ist also:Binärkodierung ist kleiner
INIs sind hübscherNa dann...
Ich sage ja nicht, dass INIs schlecht sind und eher suboptimal. Aber du sagst, dass XML schlecht ist. Deswegen brauch ich mich garnicht hinstellen und sagen, was an INIs schlechter ist als an XML, aber du müsstest durchaus diesen Weg gehen.
Ich seh keinen Grund, warum ich eine INI Datei einer XML Datei vorziehen sollte. Was genau macht also die INI Datei optimaler als die XML Datei?
Nein, wieder hast du mich nur teilweise verstanden. Ich sage "Das richtige Tool fuer den richtigen Job". XML fuer Konfigurationsdateien ist vermutlich in allen Faellen (zumindest den mir bekannten) mit Atomwaffen auf Ameisen geschossen. Obwohl du genau umgekehrte Argumente hoeren willst: Ja, mein Hauptargument gegen XML ist die Frage "Warum"?
Wenn ich wieder ueberspitze und provoziere, dann ist das fuer mich overengineering und buzzword-compliance, nichts weiter.
Original von DarKlajid
Der Kernpunkt war also: Wenn selberbauen, dann nicht in XML.Die Kernfrage die du nicht beantwortest ist: Warum dann nicht XML?
Dein Einziges Argument warum nicht XML ist bisher die größe von Binärdateien. Ansonsten hast du nur aufgezählt, dass andere Formate das gleiche können wie XML. Also warum nicht XML?
Du sagst auch noch, dass was so großartig hierarchisch an ner Konfigurationsdatei sein soll. Aber wenn wir von ner anwendungsübergreifenden Datei reden, muss doch klar sein, dass man da eine Hierarchie unbedingt braucht. Oder wie umgehst du Namenskonflikte? Wie gehst du mit mehreren Instanzen eines Programms um?
Wie baust du eine Binärdatei auf, die beliebig erweiterbar sein soll? Da steckt dann so viel arbeit dahinter, und am Ende hast du ne passive Datenbank selbstgeschrieben. Da bevorzuge ich doch irgendwie XML. Und wenn dir der Platz so wertvoll ist, dann komprimier die Datei. Gibt ja auch dafür einen Standard, auch wenn der leider nicht sonderlich oft benutzt wird.
Auch hier nochmal die Klarstellung: Es geht nicht um die Groesse. Das ist zwar ein Nachteil von XML gegenueber den anderen genannten Loesungen, aber nicht mein Kernpunkt. Ich finde es einfach widersinnig eine Technologie einzusetzen die man nicht braucht - und die negativen Seiten (da oben stehen mehrere..) wegzudiskutieren/zu ignorieren.
Die Grundaussage ist also: Wenn ich nicht begruenden kann warum ich XML einsetzen muss/will und warum die Nachteile egal sind oder wo die Vorteile liegen, dann nehme ich kein XML. Wie bei jeder Technologie gilt hier das KISS Prinzip und je mehr ich weglassen kann, um so besser.
Mods: Falls die Diskussion hier weitergeht (und ich finde sie interessant), dann koennte man vielleicht einen neuen Thread daraus erstellen?
Original von Traumzauberbaum
Ich will dir ja nicht zu nahe treten aber deine Argumentationsweise zeugt von einer sehr festgefahrenen Meinung.
Huch. Du trittst mir nicht zu nahe. Das ist ein Forum, hier wird diskutiert. Wenn das (festgefahrene Meinung) so rueber kommt: Sorry. Nein, ich denke das ist falsch. Ich sage nicht "XML ist scheisse", ich sage "Es ist fuer Konfigurationen selten die beste Wahl". Selbst dort mag es mal anders sein, aber ich glaube das leider zu selten ueberlegt wird welche Technologie jetzt Sinn macht. Vielmehr wird das einfach mal so als "Loesung" akzeptiert ohne es zu hinterfragen.
Ausserdem gefaellt es mir hin und wieder auch den Advocatus Diaboli zu spielen und die Meinung zu ueberspitzen, um zum Nachdenken anzuregen.
XML ist langsam zu parsen, aber du benutzt es für ein Transportprotokoll ja?
Man braucht XML nicht, wenn es nicht von Menschen gelesen werden soll, aber du benutzt es für ein Protokoll, was letztendlich nur von Programmen jemals gesehen wird?
Uhm?
Mein Client (Java) schickt also was los an den Server (bei mir ebenfalls Java, koennte aber in beliebiger Sprache sein), der transformiert da ein wenig rum, liest etwas darin und schickt es an andere Systeme (die zum allergroessten Teil in C/C++ oder Erlang entwickelt sind).
Was genau daran ist jetzt nicht mit dem oben (mehrfach!) angefuehrten "XML macht fuer Sprach-/Technologieuebergreifende Datenuebertragung als Standard Sinn" abgedeckt? Wo widerspreche ich mir jetzt?
Du baust dir lieber ein völlig neues Konfigurationsmodell als das eingebaute Modell zu benutzen, das eben auch XML verwendet? Du hast dort schon die Unterscheidung von Einstellungen für einen Benutzer (liegt beim Benutzer), Einstellungen für ein Programm (liegt im Programmverzeichnis) und Maschinenweiten Einstellungen (liegt im .NET Framework Verzeichnis).
Nein, hier phantasierst du. Ich baue nichts komplett neues. Ich habe auch nicht gesagt "Verwende nicht das interne .Net Modell". Ja, ich finde es Unsinn, dass dort XML zur Realisierung verwendet wird, aber das ist hier nicht der Punkt.
Urspruenglich wollte jemand in diesem Thread selber eine Konfigurationsmoeglichkeit erfinden (nicht ich..) und dabei habe ich von XML abgeraten. Der Kernpunkt war also: Wenn selberbauen, dann nicht in XML.
Deine Aufzählung von INI und DOC entbehrt nun wirklich jeder Grundlage einer sinnvollen Diskussion. Ich ärger mich schon, dass ich darauf überhaupt eingehe.
DOC war natuerlich provokant. Wenn du dir jetzt die normalen app.config Files anschaust bin ich aber schon interessiert was genau jetzt eine INI ausgrenzt? Nicht, dass ich das Format fuer wundervoll halten wuerde, aber was liesse sich damit nicht abbilden? Wie tief/hierarchisch sind denn deine Konfigurationen in der Regel?
Nenn mal lieber echte alternativen zu XML, statt einfach zu sagen, dass es für Konfigurationen schlecht ist.
Gefaellt dir die Formulierung "XML ist fuer Konfigurationen meistens suboptimal" besser?
Genannt waren schon:
Binaer serlisiert
Property files
Inis
Original von Traumzauberbaum
Noch ein paar Argumente:
- Offene Formate sind ein kaum zu unterschätzender Vorteil. Programme können über offene Formate viel besser zusammen arbeiten.
Ich bin ein starker Verfechter offener Formate. Ich nutze sogar taeglich und fast rund um die Uhr XML (XMPP sei Dank). Fuer den genannten Fall (Zusammenarbeit zwischen Programmen) mag das ja auch noch Sinn machen. Meine Aussage oben enhaelt ja darauf eine Referenz, wenngleich ich da halt von verschiedenen Technologien spreche. Bei gleicher Sprache/Technologie gibt es vermutl. effizientere Alternativen.
- Das eingebaute Konfigurationsmodell löst die Probleme wie "Einstellungen für alle Nutzer gleich" und "Einstellungen für jeden Nutzer individuell" bereits.
Es ging hier aber erstens um eine andere Sache als die Applikationseinstellungen (Naemlich um eine globale Einstellung fuer mehrere Anwendungen, wenn ich den Beitrag richtig verstanden habe) und zweitens hat dieses Modell zweier Einstellungen erstmal grundsaetzlich nichts mit XML zu tun. Das es damit realisiert ist interessiert ja (mich) gar nicht. Es ging mir hier um das Anlegen neuer XML Dateien. Was ich fuer Konfigurationen fuer nicht sinnvoll halte.
- Man kann xml lesen, ohne dazu gezwungen zu sein. Für den Support sehr hilfreich die Konfiguration eines Kunden leicht zu verifizieren, unabhängig von eventueller Lokalisierung.
Das gilt wohl fuer jede Textdatei. Dann gibt es immer noch sowas wie ini files, java properties files oder dergleichen.
- Selbst wenn der Ersteller des Programms kein Tool zur Konfiguration zur Verfügung stellt, oder dieses eher schlecht ist, ist es ein leichtes selbst eines zu erstellen und an einen Endkunden weiterzugeben. Offenes Format eben.
Bist du der Meinung, dass man eine Konfiguration die der Entwickler nicht offenlegt wirklich editieren sollte? Willst du, dass deine Kunden sich denken "XML ist doch einfach zu editieren, ich frickel mal"? Dazu hatte ich weiter oben ja auch diverse Saetze: Wenn/Falls man eine Konfiguration will die auch per Hand (und damit schliesse ich externe allgemeine Werkzeuge ein) aendern koennen soll, dann mag XML eine Alternative sein. Obwohl es nach wie vor auch andere gibt..
- Es ist leicht erweiterbar mit gleichzeitiger Abwärtskompatibilität. Erweiter mal ein binäres Format, da muss man in eine Lösung schon sehr viel mehr Arbeit stecken um das zu erreichen.
Ob das nun wirklich sehr viel mehr Arbeit waere sei dahingestellt. Ich habe auch an keiner Stelle binaere Loesungen als das nonplusultra hingestellt, aber ich finde sie durchaus an einigen Stellen angebracht, ja.
Original von svenson
Sehe ich komplett anders:
- Ressourcenbedarf ist bei Konfigs kein Thema
- App-Configs sind eh zwingend notwendig um Teile von .NET zu konfigurieren, es sei denn man macht es explizit im Code
- ein etabliertes und bekanntes Format
- unterstützt durch Tools, Codegeneration und Funktionen im Framework (Verschlüsselung)
Aber vielleicht verrätst du uns ja die Killer-Alternative....
Bleibt ja dann doch Geschmackssache. Ich koennte jetzt gegen deine Argumente vorgehen (1: XML wird virusartig immer mehr eingesetzt. Man sollte von vorneherein bedenken, dass dieses Format nicht nur Vorteile hat und eben nicht performant zu parsen ist, 2 habe ich weiter oben schon als daemlich aus meiner Sicht abgestempelt, 3 das sind auch Textdateien. Die gibt es schon laenger. Ist nicht auch ein Word .doc ein etabliertes Format? Cool, lass uns doch das fuer die Speicherung von Konfigurationen nehmen.. Bei 4 koennte ich jetzt entweder auch in den Word/Excel Spass abgleiten oder fragen ob man die Tools und Generatoren jetzt nicht eigentlich erst deshalb braucht, weil XML halt "unnatuerlich" fuer Menschen zu schreiben ist)
Aber dein letzter Satz scheint ja eine Diskussion schon auszuschliessen. Daher auch meine nicht ganz ernst zu nehmende Stellungnahme.
XML Checklist:
- Wird die Konfiguration zwischen verschiedenen Systemen/Sprachen ausgetauscht? (Gelesen von Java, Python und .Net z.B.? SOAP?)
- Muss die Konfiguration manuell editierbar sein?
- Soll die Konfiguration einer grobe Syntaxpruefung unterzogen werden (DTD, Schema)?
- Gibt mir mein Manager mehr Geld fuer die Verwendung eines "Enterprise" Wortes/Akronyms?
Falls du nicht mind. 1-2 Fragen von da oben mit "Ja, sicher" beantwortest: Wozu zur Hoelle dann XML? Es ist ein (schlechter?) Kompromiss zwischen Maschinen- und Menschenlesbarkeit. Sicher macht XML Sinn (siehe oben, ein paar Szenarien habe ich aufgezaehlt), aber ich persoenlich finde es ueberaus aergerlich/haesslich/schlecht durchdacht wenn man als Benutzer eine XML Konfiguration manuell pflegen soll (sehr krankhaft schon in der Java Welt vertreten) und finde es noch ungeschickter eine solche XML Konfiguration zu benutzen wenn ich es nicht bearbeiten soll. Warum dann nicht platzsparender speichern und resourcenschonender laden?
Mich verwirrt der Beitrag..
Aber meine persoenliche Einschaetzung, jeweils zu Teilaspekten:
Eine Konfiguration fuer alles?
Halte ich nicht fuer sinnvoll..Eine Konfiguration in einer DB?
Halte ich fuer sinnvoll falls du darin suchst/haeufiger lesend zugreifst oder die Datenmengen recht gross werden. Dann brauchst du aber keinen IsolatedStorage.Konfiguration nicht als XML
Das halte ich fuer den besten Gedanken in dem Beitrag. Wer XML fuer Konfigurationen benutzt ist m.E. boese irre geleitet. Ja, ich weiss welches Format app.config Dateien haben..
Ungetestet:
bool imSubnetz = adresse & subnet > 0;
ThreadPool.SetMaxThreads()..
Ob man ernsthaft 250 Threads gleichzeitig will ist jetzt vielleicht eine Glaubensfrage..
Kannst du auch. Mit mehr Aufwand und m.E. nach keinem Mehrwehrt. Warum willst du das also?
Ich fuerchte ich kann dir nicht folgen.. Zufallszahlen sind gleichverteilt, sicher. Sonst wuerden sie ja ihren charakter als Zufallszahlen verlieren (lassen wir das "Pseudo-" hier mal aus Platzgruenden immer weg).
Wie du die gewichtest/interpretierst bleibt doch dir ueberlassen? Wenn eine Zufallszahl zwischen 0 und 1 fuer dich eine Entscheidung A (bei Zahl ≤ 0.6) oder B (Zahl > 0.6) bedeutet, dann hast du doch gewichtet. Was genau verstehe ich bei dir jetzt nicht?
Das Brett ist wohl zu tief (vor die Augen) gerutscht und hat dich wohl den Hinweis auf den ThreadPool ueberlesen lassen..
Meiner Meinung nach ist eine Konfigurationsdatei fuer mehrere Anwendungen eher nicht sinnvoll, aber das mag eine Geschmacksfrage sein (Vergleiche Unix-Textfiles vs. Windows Registry).
Der von Herbivore verlinkte Artikel spricht gegen Ende viel ueber IsolatedStorage, eine recht nette Sache.. Aber das wird m.E. nach nichts fuer deinen Fall bringen/es dir nicht erlauben Dateien fuer mehrere (verschiedene) Anwendungen ablegen.
Uhm? Wenn du ein Programm auf einer Freigabe/einem Netzwerklaufwerk startest, dann laeuft es trotzdem hier/lokal.
Das waere hier also Unsinn.
Wenn du die Position in der Liste brauchst, dann bleib doch bei einer for Schleife. Genau so wie du sie dort stehen hast funktioniert das Konstrukt schon seit Jahrzehnten und ist immer noch total hipp..
Original von martin_zi
Hallo kann man so eine Schleife auch mit einer
foreach Schleife realisieren ?List<int> list = new List<int>(); for (int x = 0; x < list.Count; x++) { for (int y = x + 1; x < list.Count; x++) { } }Mein Problem ist dabei das ich nicht wüsste wie ich
beim foreach "y" auswerten sollte ?
Dein Problem ist m.E. erstmal, dass du in der zweiten Schleife die Zaehlervariable der ersten Schleife pruefst und hochzaehlst. Ich biete als Vereinfachung:
List<int> list = new List<int>();
int y = 1;
for (int x = 0; x < list.Count; x++)
{
// Was auch immer
}
Hast du dich ggf. verschrieben? Kannst du dein Problem vielleicht klarer beschreiben?
Kannst du mir den Fehler sagen (lies: Was GENAU geht nicht/passiert)?
Ansonsten frage ich mich an welcher Stelle man Euro oder Dollar eingeben kann...
Ne, du drehst es gerade um.. Er will einen double uebergeben. Weil SOAP nunmal auf XML basiert wird es sowieso als String uebergeben ("1234.567"). Dummerweise hat nach LaBamba die .Net SOAP Abstraktion die lustige Idee nur einen double zu akzeptieren und sich selbst um das formatieren zu kuemmern - und da scheint es zu klemmen..
Interessant zu lesen.. 😉
Ich fuerchte bei Detailfragen muss ich passen: Ich habe das selbst erst kuerzlich ueber dieses Forum gefunden und noch nicht benutzt. Ich finde es allerdings sehr nett..
Grundidee ist ja dabei, dass du eine sichere (im Sinne von: Nicht direkt mit dem Filesystem verbunden.. Sandbox fuer unsicheren Code z.B.) Methode hast, Daten abzulegen. Ich wuerde es als "Cookies fuer Webapplikationen auf Speed" bezeichnen.
Wo genau der Store ist siehst du in dem Artikel der hier referenziert wurde (http://www.dotnetdevs.com/articles/IsolatedStorage.aspx) und darauf kann man natuerlich auch von extern zugreifen. Irgendwie..
Herbivore: No offense - und das ist ja deine Sache.. Aber andere Threads mit gleichem Verlauf hast du schon des oefteren mit der Begruendung "Wir machen keine Hausaufgaben" geschlossen
Anderer Vorschlag:
Du gibst deinem Program einen StrongName und benutzt den ebenfalls hier im Forum kuerzlich angesprochenen IsolatedStorage.. Damit duerfte eigentlich (..) niemand sonst an die von dir abgelegten Schluessel kommen.
Original von Underscare
Also ich kann dieses Problem nur bestätigen. Nutze Excel 2003 und greife über PIA's auf Excel zu.Hier mal die Code-Stelle, an der ich Excel schliesse:
if (chkShowExcel.Checked) { excelApp.Visible = true; } else { //Excel schliessen excelWorkbook.Close(false,missing,missing); excelApp.Application.Quit(); excelApp.Quit(); //Variablen nullen excelApp = null; excelSheets = null; excelWorkbook = null; excelWorksheet = null; //Speicher aufräumen lassen (Muss nicht gemacht werden, aber doppelt hällt bekanntlich besser ;) ) GC.Collect(); GC.WaitForPendingFinalizers(); }
Offtopic, aber: Lass die Finger vom GarbageCollector. Ich wette jede Menge Bier darauf, dass dieser Aufruf nicht besser haelt, sondern Unfug ist und nicht das macht was du willst..
Edit: Quoting repariert..
Dann solltest du uns den Fehler auch nennen..
Beide Fehlermeldungen sind komplette, einfache Saetze, die das Problem beschreiben.
Dazu gibt es im Normalfall von herbivore einen Link auf "Compilerfehler selber loesen". Schau mal in die FAQ oder such im Board..