Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Portal
  • |
  • Mitglieder
Beiträge von CarstenP
Thema: xml datei per soap übertragen
Am im Forum: Netzwerktechnologien

Wegen SOAP und Webserver: Einigen Systemen, etwa PHP, muss man erst beibringen, dass sie einen POST-Request komplett als "raw data" behandeln können. Falls Dein Server natürlich ein IIS ist mit .NET, hast Du da keine Probleme. Mir ist es jedenfalls passiert, dass der Server, der den Service bereit stellen sollte, mit einem SOAP-Request nix anzufangen wusste und ich erstmal wegen einer Einstellung (php.ini) mit dem Provider verhandeln musste.

Ansonsten kann ich aus der Praxis nur dringend dazu raten, dass Du Dir FZelles Vorschlag zu Herzen nimmst und Deine Daten in einen einzigen String packst (das könnte dann so ähnlich wie eine CSV-Datei aussehen). Alles andere macht einen tierischen Aufwand, der zudem total überflüssig ist. SOAP an sich ist schon umständlich genug.

Thema: CP.PickList
Am im Forum: Projekte

solange es noch in der entwicklung ist (und das ist es, wie man am ToDo sieht, außerdem ist das abfangen von fehlern noch sehr rudimentär, das kommt aber im laufe des wochenendes), ist es freeware. danach werd ichs so handhaben bei "sandbar" und co, sprich: für nichtkommerzielle projekte wirds mit einer erwähnung in der programminfo oder der programm-readme "bezahlt", für kommerzielle projekte ist es dann verhandlungssache.

EDIT: ich habe gerade die beschreibung etwas korrigiert und komplettiert und auch einen passus in sachen lizenz bzw. verwendung reingeschrieben.

Thema: CP.PickList
Am im Forum: Projekte

Okay, okay, auch kein echtes Projekt, nur ein Steuerelement, aber vielleicht guckt ja trotzdem mal jemand:

http://www.clubb.de/private/cp/dotnet/picklist.html

C#arsten

Thema: Wunsch für eine neue Forums-Ecke "Heulen & Zähneknirschen"...
Am im Forum: Wünsche und Kritik

Assembler...
<world.persons.durchgeknallt.Scooter>Ihr seid ja alle wahnsinnig!</world.persons.durchgeknallt.Scooter>

Das kann nur daran liegen, dass Ihr nie die Gelegenheit hattet, nen selbstgebauten (d.h. einen auf einer mit Fädeldraht verdrahteten Platine sitzenden) und maßlos übertakteten Zilog-Z80C-19"-Einschub-Computer per "c't"-EPROM-Brenner binär zu programmieren Mei, das Ding hatte am Ende irre 6 MHz und 128 KByte RAM und konnte unter CP/M Pascal-Programme übersetzen! Gute, alte Zeiten... *g*

Thema: Wunsch für eine neue Forums-Ecke "Heulen & Zähneknirschen"...
Am im Forum: Wünsche und Kritik

*spam* Mei, Kinder, Unsereins schlägt sich noch damit herum, wie er nützliche Controls bauen kann, und Ihr schwadroniert im Geiste schon wieder von Assembler...

Thema: Wunsch für eine neue Forums-Ecke "Heulen & Zähneknirschen"...
Am im Forum: Wünsche und Kritik

Hm, da findest Du sicher viele interessierte Leser, aber gibt's hier auch kompetente Autoren zu dem Thema? Ich will niemandem auf die Füße treten, aber zu diesen Themen wirklich präzise Aussagen findet man ja nichtmal in der MSDN...

Thema: Reflection...
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Zitat
Original von NoOneKnows
Noch zu GC.Collect(). Man sollte es nicht verwenden, weils inperformant ist. .NET kümmert sich selbst darum, wann es notwendig ist aufzuräumen. Und man braucht keine Bedenken haben, noch bevor angefangen wird auszulagern wird .NET einmal den GC laufen lassen
Ja, eben. Genau deswegen verstehe ich es nicht. Aber es ist doch kaum so, dass alle, die unbedingt GC.Collect() machen wollen, ewig-gestrige C-Hacker sind? Ich tippe eher darauf, dass die GC in VB ziemlich miserabel war, in allen Versionen.

Allerdings rate ich trotzdem dazu, statt die GC "überlisten" zu versuchen, lieber mit ein paar Tools der GC in ihrer natürlichen Form bei der Arbeit zuzuschauen. Die ist nämlich verblüffend gut und effizient.

Thema: Frage zum ListView-Control
Am im Forum: GUI: Windows-Forms

*argh*...

mit der "Focused"-Eigenschaft des Items, Du ********!!!

Ach ja, danke, so einfach kann es manchmal sein...

*schnell versteck*

Thema: Frage zum ListView-Control
Am im Forum: GUI: Windows-Forms

Hm, ich hoffe, ich kann mich jetzt verständlich ausdrücken... *räusper*

Ich hab da also so eine ListView auf einer Form, in der ich mächtig rumrühre. Unter anderem hab ich das Ding so aufgebohrt, dass man in allen Spalten nach Einträgen per Tastatur suchen kann (so, wie es sonst nur bei der ersten Spalte geht). Das heißt, ich stelle im Code ein, welches Item "selected" ist (ist immer nur eins).

So, wenn ich die Selection so manipuliere, dann wird das richtige Item zwar als selektiert angezeigt (also so farbig hinterlegt halt), aber offenbar gibt es noch eine zweite "Selection", wohl eher einen Fokus, welcher einen anderen Eintrag mit so einer dotted Linie umgibt. D.h., wenn ich jetzt über die Tastatur suche und anschließend mit den Pfeiltasten manövrieren will, steht der Fokus nicht korrekt, und die ganze Selektiererei war für die Füße. Wie setze ich da bitte den Fokus auf das richtige Item?

Thema: Reflection...
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

*spam* Wieso wollen eigentlich so viele Leute zwanghaft die CG mit der Hand machen?

Thema: Reflection
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Nochmal zum Mitschneiden für mich...

Du hast eine FormIrgendwas : Form. Darauf klebt ein Label...

class myForm : Form
{
   private Label myLabel;
   // <-- diese Stelle bitte merken!
   public void myForm()
   {
      this.InitializeComponent();
   }

   private void InitializeComponent()
   {
      // sonstigen krams a la Form Designer weggelassen
      this.myLabel = new Label();
      this.myLabel.Location = new Point(10, 10);
      this.myLabel.Size = new Size(50, 20);
      this.myLabel.Text = "mein Text";

      this.Controls.Add(this.myLabel);
   }
}
Und jetzt willst Du die Text-Eigenschaft Deines Labels von "außen" ändern? Dann füge einfach an die Stelle, die Du Dir da oben merken solltest, dieses ein...
   public string myLabelText
   {
      get { return this.myLabel.Text; }
      set { this.myLabel.Text = value; }
   }
... und schon kannst Du per
myForm frm = new myForm();
frm.myLabelText = "mein neuer Text";
den Text ändern.

... oder hab ich jetzt was falsch verstanden?

Thema: c# oder VB.Net
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

@NoOne: Auch Geschmacksache Ich würde mir wünschen, man könnte dem VS-Editor beibringen, die öffnende { in der vorigen Zeile zu lassen, ohne dass es dann bei der Formatierung durcheinander kommt. Ich lasse dem Ding also seinen Willen und nehme die einzelne { in einer extra Zeile in Kauf. Mir persönlich wird Code dann teilweise ZU luftig, zumal ich auch Einzeiler nach "if"s einklammere, statt mich dieser Unsitte hinzugeben, Einzeiler oder Folge-"if"s direkt an die Zeile davor zu kleben. Es soll sogar in alten Linux-Kerneln aus diesem Grund zu Abschmierern gekommen sein, weil der Programmierer anders "dachte" als der Compiler

Thema: c# oder VB.Net
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Ich denke, die Frage lässt sich am leichtesten dadurch beantworten, dass man sich

if (foo) {
   for (int i = 0; i < 10; i++) {
      ...
   }
}
else {
   ...
}
anschaut und im Vergleich dazu
If foo Then
   Dim i As Integer
   For i = 0 To 9
      ...
   Next i
Else
   ...
Endif

Ich persönlich mag Kleinschreibung und geschweifte Klammern. Ich finde "next", "endif" und Co. hässlich. Das ist der einzige Grund, weswegen ich nach VB6 mit Freuden zu C# statt zu VB.NET gewechselt bin: (zu) viel PHP und C++ und JScript in der Zwischenzeit, sodass meine Augen einfach an geschweifte Klammern und die "luftigere" Optik von C-ähnlicher Syntax gewöhnt sind.

Fazit: bis auf ein paar wenige Prozent mehr Performance für C# (die mit .NET 2.0 vermutlich behoben sein werden) ist das eine reine Geschmacksfrage.

Thema: Wunsch für eine neue Forums-Ecke "Heulen & Zähneknirschen"...
Am im Forum: Wünsche und Kritik

Zitat
Original von alexander
Hallo,

finde die Idee grundsätzlich nicht schlecht.
Das wird intern bei uns diskutiert werden.

Hui, klasse! Was kann ich mehr erwarten!

Thema: XP-Style Icons - Freeware-Tools?
Am im Forum: Smalltalk

Zitat
Original von UserNeo
Falls du ersters suchst, dann siehe meinen ersten Beitrag, dort gibt es die Standard Version kostenlos .
Jau, das Teil ist nicht schlecht, nur kann es das Wichtigste nicht: Bilddateien laden.

Thema: XP-Style Icons - Freeware-Tools?
Am im Forum: Smalltalk

Jau, Günni, aber es geht ums Selbermalen. Illustrator und Photoshop sind gute Freunde von mir, aber sowas wie (System.CastTo.Freeware)Microangelo; fehlt mir

Thema: Wunsch für eine neue Forums-Ecke "Heulen & Zähneknirschen"...
Am im Forum: Wünsche und Kritik

Ja, gerade zur Projekt-Planung und zum -Management fallen mir spontan viele Themen ein... Zum Beispiel:

"Wir sind eine kleine Software-Firma, unsere Programmierer sitzen aber verteilt zwischen Buxtehude und Ibiza, wie synchronisieren wir unsere Sourcen und beliefern unsere Kunden mit einem vernünftigen, einheitlichen Stand?"

"Unser Key-Account hat eine neue Software angefordert. Wie können wir einen Prototypen vorführen, den wir nach der Präsentation nicht komplett in die Tonne treten müssen? Wie finden wir also einen goldenen Mittelweg zwischen 'rapid prototyping' und 'reusability'?"

"Wo liegt das sinnvolle Mittelmaß zwischen 'Schnell reingehackt' und 'literarischem Programmieren'? Wie schreibt man also selbst-dokumentierenden Code, ohne 2/3 der Zeit mit Dokumentation zu vergeuden? Zeit ist Geld..."

"Wie sorgt man dafür, dass die neue Kollegin sich an die bisher von mir im Schweiß meines Angesichts durchgesetzten Coding-Standards hält? Wie definiert man für sich Schwellenwerte, hinter denen neue Ideen zum Redesign des eigenen Codes führen sollten?"

usw...

Thema: Was bedeuten eure Nicknames/Avatare?
Am im Forum: Smalltalk

Der Vollständigkeit halber, aber nur deswegen... Ich heiße so, das "P" ist der erste Buchstabe meines Nachnamens

Thema: Wunsch für eine neue Forums-Ecke "Heulen & Zähneknirschen"...
Am im Forum: Wünsche und Kritik

Zitat
Original von Code-Hacker
War das eine Anspielung auf mich und darauf wie mein entwickelter Code aussieht?
*schmunzel* Nee, war keine Anspielung auf irgendwen hier, und Hacking gehört zum Programmieren sowieso dazu. Man kann nämlich bei allzu viel Dogmatismus auch mit Kanonen auf Spatzen schießen

Aber ich finde es schön, dass meine Anregung so viel Anklang findet. Ich verfeinere meine Idee mal ein wenig:

Forum-Name: Software-Entwicklung allgemein
Unter-Foren:
1. Software-Projekt-Planung und -Management
Was gehört in ein Pflichtenheft? Wie definiert man Milestones? Wie verwaltet man ein Mehr-Personen-Projekt? Wie hält man Termine ein? Wie erklärt man den GAU seinem Chef und seinen Kunden? Wie hält man sich die Vertriebsfritzen vom Leib?

2. Vom Fehler zur Lösung
Erfahrungsberichte aus der Praxis zu typischen Problemstellungen; welche Ansätze sich als problematisch erwiesen haben und warum -- und bewährte Alternativen.

3. Patterns & Practises
Erprobte Ansätze zum Entwurf und zur Entwicklung von Software, zur Lösung typischer Aufgaben und zum Umschiffen alltäglicher Klippen.

4. Philosophisches
Static? Singleton? Instanz? Erfahrungsaustausch und Diskussion über Software-Entwicklungs-Strategien.

2 und 3 überlappen sich natürlich. Meine persönliche Idealvorstellung wäre, wenn Leute, die Lust drauf haben, erstmal in (2) einen kurzen, knappen Erfahrungsbericht schreiben und erzählen würden, was sich so alles als problematisch bis total besch...eiden erwiesen hat, und dann in (3) eine gute, erprobte Lösung vorstellen.

Thema: Wunsch für eine neue Forums-Ecke "Heulen & Zähneknirschen"...
Am im Forum: Wünsche und Kritik

... oder so ähnlich.

Ein Forum, in dem man sich über typische Programmier(er)fehler austauschen kann. Ich finde solche Beiträge, die in vielen Programmier-Foren immer wieder mal irgendwo auftauchen, sehr lehrreich. Man könnte es auch à la MS "Patterns & Practises" nennen und ähnlich wie in den FAQ, aber eben spezifischer, vom Fehler zur Lösung arbeiten. Dabei solls nicht so sehr um ganz spezielle Dinge gehen ("Wie zeige ich meine MySQL-Tabelle in einem DataGrid an?"), sondern eher in der Art "Wie entwerfe ich grundsätzlich eine Multi-User-Datenbank-Anwendung, und worauf muss ich achten?"

Interessant sind dann zwar auch Tutorials (aber die gibts ja teilweise schon zuhauf), aber vor allem Erfahrungsberichte der Sorte "Ich habe es erst so und so gemacht, aber das war totaler Mist, weil: 1., 2., 3.". Wer dann vor einer solchen Aufgabe steht und sich vielleicht ähnliche Gedanken macht, wie der Autor zu Beginn, und somit in dieselben Probleme rennen würde, kriegt dann kein "mach es mal so, Kleiner!" um die Ohren, sondern eine Erklärung und einen "Denk-Weg", den er entlang gehen kann, um an Ende (hoffentlich) so schlau zu sein wie der Autor, ohne dessen Fehler selbst machen zu müssen.

In so einer Forums-Ecke könnte man außerdem ein bisschen über Entwurfsmuster (Singleton? static? oder doch eine normale Instanz?) und Vorgehensweisen (Top-down? Bottom-up? Kraut-und-Rüben?) philosophieren. Ich persönlich mag solchen Austausch jedenfalls, weil es gegen Betriebsblindheit hilft ("ich hab das gestern so gemacht, also mach ichs heute auch wieder und morgen erneut, bis mir einer erklärt, warum meine Idee dämlich ist!").

Für n00bs hätte diese zweite Abteilung vielleicht eher Unterhaltungs- als praktischen Nährwert, aber auf jeden Fall dürfte es den einen oder anderen aufmerksamen und geneigten Leser dazu animieren, sich damit auseinander zu setzen, dass es eben doch einen grundlegenden Unterschied zwischen Code-Hacken und Software-Entwicklung gibt

Thema: Datentransfer über TCP Socket
Am im Forum: Netzwerktechnologien

Warte, habe ich Stuss erzählt? Ich hasse sinnfreie Verneinung in logischen Ausdrücken. Moment...

while(!(nReceived<byteReceived.Length))

<=>

while (nReceived ≥ byteReceived.Length)

(">" kann nicht sein, also...)

<=>

while (nReceived == byteReceived.Length)

d.h.: Solange immer der gesamte Buffer beim Lesen gefüllt wird, geht es weiter. Der Socket kriegt also z.B. 1518 Bytes - 14 Bytes Ethernet-Header - 4 Bytes Prüfsumme - 40 Bytes TCP-Header = 1460 Bytes Nutzdaten.

Davon werden 1024 an den Buffer übergeben, und asynchron wird der Socket wieder auf 1024 aufgefüllt usw., bis über den Socket alles geholt ist. Der letzte Block ist dann < 1024, und die while-Schleife endet.

Zur Prüfung meiner o.g. "Theorie" sollte man im Code die 1024 mal auf was richtig Großes verändern und mit dem localhost testen. Das kann dann fehlschlagen, muss es aber nicht, weil die Daten lokal ja huschhusch übertragen werden. Deswegen sollte man noch einen zweiten Test fahren mit einer sehr kleinen Paketgröße (64 Bytes oder sowas) und dann übers Netz probieren.

Schlauer wäre es natürlich, den Unfug zu lassen und das Auslesen des Sockets gleich richtig zu schreiben, also darauf zu prüfen, ob der Socket noch Daten kriegt.

Thema: Wozu C#, wenn es C/C++ gibt?
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Zitat
Original von NoOneKnows
Eins bleibt trotzdem immer: Man muß auch Aufwand und Nutzen abwägen. Wenn ich die Wahl habe eine Control komplett neuzuschreiben oder ein vorhandenes abzuleiten und per Reflection auf ein geschütztes Member zuzugreifen um meine neue Funktionalität implementieren zu können entscheide ich mich natürlich für letzteres. Von daher is Reflection ein gutes Werkzeug, aber man sollte es mit Bedacht einsetzen.
Das ist richtig. Und mit Reflection, wenn man sich einmal durch das Thema durchgewühlt hat, sind wirklich abartig scharfe Sachen möglich. Ich will nicht behaupten, dass alles davon Lehrbuch-OOP ist, aber schmuck ist es trotzdem
Zitat
Zitat
(Carstens Schimpf auf DataBinding)
Okay, soviele Gedanken hab ich mir bis jetzt noch nicht dazu gemacht
Genau deswegen schimpfe ich ja so auf die VS-Vorlagen: Weil sie auf den ersten Blick das Nachdenken überflüssig erscheinen lassen. Sorry, das ist jetzt nicht persönlich gemeint. Diese Dinger verführen halt zu "ich probiere es einfach mal schnell aus"; und bekanntlich haben solche "mal schnell ausprobierten" Sachen, eben weil sie schnell gehen, eine magische Anziehungskraft und eine fatale Neigung dazu, zu einer dauerhaften Einrichtung zu werden.

Später aber, wenn es um die Erweiterung eines Projekts geht, steht man dann vor der Frage, ob man was drumrum programmiert oder neu entwickelt. Nostalgisch, wie man ist, programmiert man lieber drumrum, und schon hat man absolut unwartbaren Code geschaffen, der zwar funktioniert, aber manchmal, manchmal so ganz komische Effekte hat... aber nur, wenn man hier darauf klickt und vorher dort jenes ausgewählt hatte und es zufällig 13:02 ist, quasi niemals never ever auftreten kann... und zwei Tage später klingelt das Telefon, und ein verärgerter Kunde fragt, was denn dieser Mist nun soll. Alles schon erlebt.

Thema: XP-Style Icons - Freeware-Tools?
Am im Forum: Smalltalk

Hallo Forum,

beim Rumstöbern bei MS und bei Google bin ich auf viele Tools gestoßen, mittels derer man aus schicken Grafiken XP-Style-Icons erstellen kann, aber die kosten alle ziemlich bis abartig viel Geld. Gibt's da nicht auch was von Ratioph... aus der OpenSource-Gemeinde oder schlicht als Freeware?

Thema: Kleines Backupprogramm
Am im Forum: Projekte

Afaik möchte der Entwickler von der Sandbar (übrigens sehr empfehlenswerte Seite, er hat noch mehr so schicke Spielsachen) bei kostenlosen, d.h. nichtkommerziellen Programmen nur irgendwo in der Programminfo erwähnt werden.

Thema: Wozu C#, wenn es C/C++ gibt?
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

Zitat
Original von NoOneKnows
Nenene... Also Mehrvererbung braucht man absolut nicht. Es macht die Dinger meistens komplexer und unverständlicher. Deshalb verzichtet man in den modernen OOP-Sprachen wie Java und C# darauf. Man muß die Sachverhalte nur anders durchdenken um sie mit linearer Vererbung und Interfaces zu lösen.
Man kann allerdings durch Mehrfach-Vererbung manche Dinge extrem elegant lösen. Möglich, dass sie fast völlig überflüssig wird, wenn C# mal Templates beherrscht (wobei ich Templates eher als Fast-Ersatz für Interfaces ansehe). Der Sinn von Interfaces ist mir schon klar, und an manchen Stellen sind sie auch praktisch und notwendig. Aber oft erzeugen sie einfach nur die Notwendigkeit, per ^C^V + ein paar Änderungen zum 20. Mal denselben Code irgendwo reinzupacken.
Zitat

Und bei der Reflection sollte man ja weitesgehend vermeiden damit auf nicht verfügbare Member zuzugreifen. Zumindest durchbrichts du damit ja das Konzept der Objektorientierung. Wie darf man sich das denn bei dir vorstellen?
Weitestgehend? Also, wer per Reflection auf nicht verfügbare Member zugreift... Prost, Mahlzeit!
Zitat
Zitat
und das übelste Verbrechen ist für mich nach wie vor das "Data-Binding" von Controls. Wer sich da einmal dran gewöhnt hat, dem dürfte es schwer fallen, mal eine N-Tier-Anwendung sauber zu programmieren.
In VB6 hatte es leider noch nicht richtig funktioniert, aber es ist schon der richtige Schritt. Warum sich arbeit machen, wenns auch ohne geht. Mit DataBindings zu arbeiten ist das beste was man tun kann um sich ein Teil des stupiden Codings zu ersparen.

DataBinding widerspricht aufs Diametralste dem N-Tier-Konzept, indem es eine Business-Logik-Schicht völlig verhindert. Wie validierst Du eine Eingabe in ein Control, wenn die Validierung sich auf ein zweites Control bezieht (z.B. Ort und PLZ)? Wie validierst Du die Eingaben in eine Form, wenn die Validierung dabei auf die Datenbank zugreifen muss (z.B. "Peter Müller, verheiratet mit Jutta Müller", aber in der DB steht, dass Jutta Müller von Peter Müller geschieden ist)?

Und was tust Du, wenn Dein Kunde, der bisher mit den 4 Arbeitsplätzen und der Access-Datenbank auf dem Fileserver zufrieden war, plötzlich eine C/S-Lösung will? Oder gar Web-Zugriff? Theoretisch geht das natürlich per DataBinding...

Thema: Code-Unabhängigkeit
Am im Forum: GUI: Windows-Forms

Kleine Ergänzung zu dem Thema...

Man kann imho eine ziemlich klare Grenze ziehen, bis wohin die Verzahnung zweier Forms noch legitim ist, und zwar genau bis dorthin, wo eine Form eine Unter-Form einer anderen Form darstellt, d.h. solange die Unter-Form "form-modal" zur anderen Form ist.

Beispiel: Ich habe ein Programm zur Verwaltung von Kontakten. Im Formular zur Anzeige eines Kontakts zeige ich Ort und Postleitzahl an. Diese beiden Informationen stehen in zwei TextBoxen. Ich kann also beides einfach per Eingabe ändern. Um den Komfort zu erhöhen, setze ich daneben einen Button mit einer Ellipse ("...") drauf. Wenn der Anwender darauf klickt, kriegt einer eine Unter-Form angezeigt, in der er nach Orten und Postleitzahlen suchen kann. Wenn er auf dieser Unter-Form nun auf "OK" klickt, werden die beiden Daten "Ortsname" und "PLZ" direkt in die Hauptform übernommen, als hätte ich sie dort mit der Hand eingetragen.

Das hat gleich mehrere Vorteile:
1. muss ich die Hauptform nicht über eine Änderung benachrichtigen.
2. muss ich keine Änderungen im Datenbestand rückgängig machen, wenn der Anwender sich entscheidet, den neuen Ort / die neue PLZ nicht zu übernehmen, den Dialog also mit "Abbrechen" verlässt.

Natürlich müssten hier in die Hauptform entsprechende Get/Set-Paare rein. Die Unter-Form darf nicht direkt auf die Steuerelemente zugreifen.

Thema: Einstellungen speichern usw.
Am im Forum: GUI: Windows-Forms

Zitat
Original von VizOne
Zitat
Original von CarstenP
Hm, Deinen letzten Satz lasse ich so stehen, weil ich ihm prinzipiell erstmal zustimme. Das mit der Anzahl der Options-Objekte ist wohl eher Geschmacksache. Die Notwendigkeit des Klonens vermeide ich in meiner Options-Klasse schlicht dadurch, dass ich die Optionen erst dann aktualisiere, wenn im Optionen-Dialog auf "OK" oder "Übernehmen" geklickt wird. Bis dahin gelten die alten Werte.
Naja, so geht es auch. Aber die temporären Werte müssen dann wieder irgendwo zwischengelagert werden. Was dann eleganter ist (ein Bündel temporärer Werte oder ein temporärer Klon), möge jeder selbst entscheiden.
Die sind in den Controls des Dialogs zwischengelagert. Da sind sie auch gut aufgehoben. Wenn Du natürlich Dialoge überhaupt nicht als temporären Speicher ansiehst und die Daten bei jedem Tastendruck synchronisieren willst, bist Du mit zwei Instanzen natürlich besser bedient. Auch das ist wohl Geschmacksache.

Wäre übrigens mal interessant zu schauen, wie MS das bei deren Patterns & Practises in Sachen Options handhabt. Da gibts ja auch einen Entwurf, der angeblich sehr gut sein soll.

Nebenbei bemerkt würde mein Options-Modell als "normale" (d.h. nicht-statische) Klasse auch problemlos in meine Programmier-Philosophie passen, weil es ja im Zweifel mein Fehler wäre, wenn ich zwei Instanzen davon erstelle. Ich gehöre ja zu den Leuten, die prinzipiell keine Relationen in eine Datenbank reinentwerfen, sondern das schön im Code erledigen

Thema: NeuroNet.dll?
Am im Forum: Basistechnologien und allgemeine .NET-Klassen

thx, werde ich mir mal reintun

Thema: Einstellungen speichern usw.
Am im Forum: GUI: Windows-Forms

Zitat
Original von VizOne
Zitat
Original von CarstenP
Ich behaupte einfach mal, dass die Optionen einer Anwendung anwendungs-global sein sollten. Auf ein Singleton könnten wir uns einigen
Dann ist dir offensichtlich der Sinn eines Singletons entfallen (wir behandeln statische Klassen an dieser Stelle einfach als Pseudo-Singletons). Singletons stellen sicher, dass es nur eine Instanz einer Klasse geben kann. Dass diese Instanz global verfügbar ist, ist lediglich ein Nebeneffekt (und nicht einmal zwingend nötig). Leider sehen manche die Globalität des Objekts als Hauptkriterium für ein Singleton, was zu "seltsamen" Softwaredesigns führt.
Okay, präziser: die Optionen sollten erstens in meinen Augen einmal existieren und dann möchte ich sie zweitens noch anwendungs-global haben. Sprich: Singleton (oder Pseudo-) wegen der Einmaligkeit, und dann hänge ich das Ganze noch direkt unter das oberste Objekt meiner Anwendung.
Zitat
Warum sollte ein Options Objekt nur einmal existieren? Ich sehe da keinen Grund. Oder anders gesagt, mir fallen Gründe ein, warum es mehrfach existieren soll, Beispiel: wenn man in den Options-Dialog geht, könnten die aktuellen Optionen geklont werden (als Backup), wenn auf abbrechen geclickt wird, werden nun die alten Optionen benutzt statt der neuen. Mit einem Singleton/statische Klasse wäre das nicht so elegant möglich. Vor allem in einer Bibliothek sind Singletons in mindestens 95% der Fälle eine falsche Entscheidung.
Hm, Deinen letzten Satz lasse ich so stehen, weil ich ihm prinzipiell erstmal zustimme. Das mit der Anzahl der Options-Objekte ist wohl eher Geschmacksache. Die Notwendigkeit des Klonens vermeide ich in meiner Options-Klasse schlicht dadurch, dass ich die Optionen erst dann aktualisiere, wenn im Optionen-Dialog auf "OK" oder "Übernehmen" geklickt wird. Bis dahin gelten die alten Werte.
Zitat
Die Klasse MyApp in meinem Beispiel hingegen ist ein legitimes Beispiel für ein Singleton:
- es existiert tatsächlich immer nur eine Anwendung zu einem Zeitpunkt
- das Singleton befindet sich in Client-Code, nicht in einer Bibliothek

Schleichwerbung: http://gentlestorm.de/blog/articles/180.aspx
Zitat
Warum ich das ganze nicht über ne vererbte Klasse mache, hat einfach den Grund, dass ich es "mag" (hm, sehr professionell ausgedrückt *g*), wenn ein Objekt sich den Daten anpasst, nicht andersrum -- quasi "poor man's reflection". Ich mache das auch bei Daten-Objekten (data tier) oft so, dass ich die Objekte erst "in die Tabellen-Definition gucken" lasse und sie sich danach selbst aufbauen, statt irgendwo im Code die Felder einer speziellen Tabelle fest zu verdrahten. Ich ändere einfach lieber Daten und deren Definitionen, statt am Code rumzuhacken. Eine Stelle vergisst man schließlich immer dabei...
Ehrlich gesagt habe ich den Abschnitt nicht verstanden. Wen oder was meinst du damit?
Hm, Beispiel. Gehen wir davon aus, dass wir eine N-Tier-Anwendung haben, in der Data-Tier und DataIO-Tier getrennt sind. Im DataIO-Tier lungern die üblichen Verdächtigen (DataSet, xxxConnection, xxxCommandBuilder usw.) rum. Im Data-Tier gibt es nur Objekte, die Datenbestände aus Was-für-einer-Quelle-auch-immer repräsentieren. Diese Objekte kennen nur Methoden wie "SyncMe()" oder "UpdateMySource" und haben keine Ahnung, woher sie eigentlich stammen oder wie man sie wieder speichert.

Wenn ich jetzt eine Tabelle "MiniKontakte" habe, die zum Beispiel aus den Feldern "ID", "Name", "EMail" besteht, könnte ich also eine Klasse "MiniKontakte" mit den Eigenschaften "ID", "Name", "EMail" entwerfen. Komme ich jetzt auf die Idee, dass die "ID" nicht mehr "UInt32" sein soll, sondern ein 38 Zeichen langer String, weil ich auf GUIDs umsteigen möchte, muss ich diese Anpassung in meiner Klasse vornehmen. Habe ich aber eine "blinde" Object-Factory (oder Class-Factory, die wiederum... usw.), die bei der DataIO-Ebene anfragen kann: "Hallo, ich möchte ein Objekt vom Typ "MiniKontakte" erstellen, sag mir mal, was für Felder da drin sind und welchen Typ sie haben!", ändert das nix an meinem Code (natürlich nur, wenn ich nicht irgendwo implizit mit der "ID" was anstelle, was nur mit UInt32s möglich ist).
Zitat
Zitat
Um bei den Optionen zu bleiben: Wenn mir während der Entwicklung einer Anwendung einfällt, dass es umheimlich toll wäre, wenn ich aus der Anwendung heraus eine Option hätte, die mir den Pfad zu Word verrät, dann bastle ich in meine XML-Datei halt eine Option "PathToMSWord" rein, setze die entsprechenden Parameter und kann dann überall, wo es sinnvoll erscheint, einfach per

TolleFunktion(doc, CP.Application.Options["PathToMSWord"]);

auf die Option zugreifen, ohne dafür irgendwas am Code zu ändern.

Und was ist, wenn dir einfällt, dass du den Pfad doch nicht mehr brauchst? Dann stehen überall "PathToMSWord"s im Code herum, die ins Nirvana führen. Hättest du stattdessen eine string-Konstante PathToMSWord definiert, würdest du schon zur Übersetzungszeit Compilerfehler bekommen, wenn du diese Konstante wieder entfernst - und somit blieben keine fehlerhaften Referenzen zu PathToMSWord unentdeckt. Alles in allem änderst du WENIGER im Code, wenn du auf Literale verzichtest und stattdessen Konstanten benutzt.

Nun, das ist aber genauso "böse", sich auf Compiler-Meldungen zu verlassen in so einem Fall, und erinnert mich schwer an all die CERT-Advisories mit dem Shock-Word "buffer overflow", ausgelöst durch "C"s geliebtes strcpy(). Wenn ich sowas entferne, dann lasse ich das VS selbstverständlich über alle Dateien nach diesem Begriff suchen. Wer sowas nicht macht, frisst auch kleine Kinder

Thema: Datentransfer über TCP Socket
Am im Forum: Netzwerktechnologien

Auf dem localhost dürfte es deswegen funktionieren, weil dort keine Leitungsprobleme (Collisions, Delays, Timeouts) auftreten. Das sieht in einem realen Netz ganz anders aus.

Wenn die MTU < 1024 steht, dann kommen nie 1024 Bytes auf einmal an, sondern immer maximal das, was in der MTU definiert ist. (MTU = maximum transmission unit, dazu eine gute Erklärung von D. Ruf.) Das ist zwar nicht üblich, aber aus welchem Grund auch immer kann das durchaus so sein. Außerdem beachte man das "M", sprich: trotz MTU von 1518 oder 1492 kann es passieren, dass IP-Pakete fragmentiert werden.

Die Lösung besteht also darin, den Socket so lange auszulesen, bis nix mehr kommt bzw. bis die Gegenstelle die Verbindung schließt bzw. bis man ein Timeout auslöst bzw. er eine Ausnahme wirft. Ansonsten Zustimmung zur obigen Aussage, dass Streams "böse" sind.