Klotzkopp

Was ist denn das eigentliche Problem, das die Einführung eines solchen Systems notwendig macht?

Du brauchst nicht zu speichern. Es ist alles da. Farbdialog(Color [COLOR="#B22222"]HintergrundFarbe[/COLOR], Color [COLOR="#B22222"]RahmenFarbe[/COLOR]) { InitializeComponent(); // //TODO: Konstruktorcode hier hinzufügen. // LinienBreite = 6; pinsel1 = gcnew SolidBrush([COLOR="#0000FF"]Color::White[/COLOR]); malflaeche = panelVorschau->CreateGraphics(); panelVorschau->BackColor = [COLOR="#0000FF"]Color::Black[/COLOR];[/code] Die [color=#B22222]richtigen Farben[/color] kommen als Parameter im Farbdialog-Konstruktor an. Trotzdem benutzt du sie weder für die Initialisierung deiner Farb-Variablen noch deiner Steuerelemente. Erstere initialisierst du gar nicht, für letztere nimmst du [color=#0000FF]Schwarz und Weiß[/color]. Bring das doch einfach in Ordnung.

Ich meinte das Konsolenprogramm. Die Farben kommen über den Konstruktor in Farbdialog an, du machst nur nichts damit. Was du wo tun musst, habe ich dir bereits erklärt.

So ungefähr. Getter liefern Informationen über eine Eigenschaft eines Objekts, Setter ändern diese Eigenschaft. Was genau in solchen Methoden passiert, kommt auf den Einzelfall an. Oft steht eine Membervariable dahinter, das muss aber nicht so sein. Diese Art Methoden können auch Zusatzaufgaben beinhalten. Getter können Werte berechnen, statt sie direkt aus einem Member zu ziehen. Setter können eine Gültigkeitsprüfung des Parameters enthalten. Was in deinem Programm völlig fehlt, ist ein Modell. In deinem Programm gibt es ja offenbar ein Spielfeld, aber eine Klasse Spielfeld gibt es nicht. Statt dessen speicherst du die Eigenschaften des Spielfelds in einzelnen Variablen und reichst diese hin und her. Diese Vorgehensweise ist bei größeren Programmen fehlerträchtig und erschwert die Wartung. Welches Problem meinst du? Ich verstehe nicht ganz, was das Programm überhaupt tun oder zeigen soll. Auch in diesem Programm hast du mehrfache Variablen mit identischen Namen. Ich bin mir nicht ganz sicher, ob dir klar ist, dass diese Variablen nichts miteinander zu tun haben. Du tust dir selbst einen Gefallen, wenn du deinen Variablen ordentliche Namen gibst, die deren Aufgabe wiedergeben.

Der Code hat mehrere Probleme. Deine Klasse Farbdialog hat zwei Color-Member: Color HintergrundFarbe, RahmenFarbe; Der Konstruktor hat zwei Parameter: Farbdialog(Color HintergrundFarbe, Color RahmenFarbe) { ...[/code] Möglicherweise erwartest du, dass die Farben, die du an den Konstruktor übergibst, in deinen Membern landen. Das passiert hier aber nicht. Die Parameter haben zwar dieselben Namen wie die Member, aber dadurch kommt keine Wertübergabe zustande. Die Parameter [b]verdecken[/b] die gleichnamigen Member im Konstruktor. Wenn du hier die Member mit Inhalt füllen willst, musst du das im Konstruktor-Rumpf ausdrücklich hinschreiben, z.B. so: [code]this->HintergrundFarbe = HintergrundFarbe; Das this-> dient hier dazu, dass der Member als Ziel der Zuweisung der Member verwendet wird, nicht der gleichnamige Parameter. Wenn die Namen nicht gleich sind, kannst du das weglassen. Ein weiteres Problem: Die Namen deiner setze- und liefere-Methoden sind verdreht. Setter sind die Methoden, die die Member verändern. Getter sind die, die die Werte zurückgeben. Das ist ein reines Problem der Namensgebung, aber es ist sehr verwirrend.

Wenn du bezüglich der Wahl der Programmiersprache durch den Bildungsträger festgelegt bist, dann wäre das so ein "sehr guter Grund" Die Frage ist jetzt, welchen Anspruch du an die Lösung stellst. Willst du, dass es nur irgendwie funktioniert, oder willst du lernen, wie man das ordentlich macht?

Dann musst du eben beim Öffnen des Dialogs die neue Farbe aus den gespeicherten Einstellungen auslesen. Du speicherst die ausgewählte Farbe doch hoffentlich in einer Einstellung? Du solltest übrigens nicht ohne sehr guten Grund C++/CLI für GUI-Programmierung benutzen. Eigentlich ist das eine Interop-Sprache, um zwischen Native und .NET vermitteln zu können. Wenn du GUI machen willst, nimm C#. Wenn du C++ machen willst, mach kein Windows Forms. C++/CLI ist nämlich kein C++.

Woran soll man das sehen? Für mich sieht es so aus, als wären die Farben unterschiedlich. Dass die Entwicklungsumgebung unnötigerweise mit auf dem Screenshot ist, macht's nicht übersichtlicher. Allgemein sollte sich Form2 die Farbdaten aus derselben Quelle holen wie Form1, dann kann das gar nicht auseinanderlaufen.

Ich würde die Verarbeitung der eingelesenen Zeilen innerhalb der Einleseschleife machen, nicht danach.

Welches Betriebssystem?

Wie soll mit Fehleingaben umgegangen werden? Muss man Buchungen stornieren können? Soll das jeder Benutzer dürfen?

Woher kommen die Kunden- und Artikeldaten? Oder soll das Programm diese auch verwalten?

Man kann sehr viele Sortierungen "plausibel" begründen. Darunter wird sich jeder von uns etwas anderes vorstellen. So kommen wir nicht weiter. Du hast in deinem Kopf eine mehr oder weniger diffuse Vorstellung von der richtigen Sortierung. Aber die ist eben nur dort. Solange du uns die nicht hinreichend erklärst, wird keine vorgeschlagene Formel "aufgehen". Also bitte: Bring die Liste mit den 27 Kombinationen in die "richtige" Reihenfolge, dann bekommst du deine Formel.

Eine einfache Gewichtung wird dich nicht weiterbringen. Oder sind viele Einser-Bewertungen besser als wenige? Erstell doch mal alle Kombinationen aus Besucheranzahl (100, 200, 300), Bewertung (1, 3, 5) und Anzahl (10, 20, 30) und bring sie in die deiner Meinung nach richtige Reihenfolge. Dann kann man dir weiterhelfen.

Deine CString-Instanz ist namenlos und temporär. Die lebt nur, bis die enthaltende Anweisung (in diesem Fall die Zuweisung an pszText) abgearbeitet ist.

Der Zeiger, den CString::GetBuffer liefert, ist nur solange gültig, wie der dazugehörige CString lebt. Wenn du TreeView_InsertItem aufrufst, ist er also schon ungültig. Den BSTR leakst du übrigens.

HTML ist standardisiert. HTML 4.01 Specification

TOOLS -> Options -> Projects and Solutions -> Build and Run

bool machWasDamit = (from dFiles in dInfo.GetFiles() where dFiles.Name == strFileName select dFiles).Count() > 0;

Die Ausgabe True oder False ergibt sich aus (from dFiles in dInfo.GetFiles() where dFiles.Name == strFileName select dFiles).Count() > 0 Das ist ein bool-Ausdruck, den du so, wie er da steht, auch für ein where oder if benutzen kannst.

Wo liegt denn das Problem? Weißt du nicht, wie man eine Datei verschiebt?

Vermutlich spielt SynonymOfGod darauf an, dass auf ein Case-Label ein Statement folgen muss. Eine Deklaration ist in C aber kein Statement. Dein Code ist also nicht formal korrekt. Das ließe sich aber einfach durch ein leeres oder Compound Statement beheben.

Du kannst mit einer ähnlichen Schleife abzählen, wie lang die Darstellung wird. Oder du machst dein Array einfach "groß genug" (durch den Datentyp von dez gibt es eine obere Schranke), füllst dein Array von 0 beginnend und drehst am Ende das Ergebnis um.

Wenn das Binding fehlschlägt, sollte aber zumindest im Debug-Log eine Ausgabe zu sehen sein. Hat deine UserControl-Klasse denn ein DependencyProperty HJSTValidationType?

Dann sind die Daten vermutlich fehlerhaft oder unvollständig.