Klotzkopp

Eben. Du musst bei jeder Eingabe in den Automaten entscheiden, ob die Priorität der Operation in der Eingabe höher ist, oder die der Operation, die oben auf dem Stack liegt. Könnte im nächsten Schritt noch eine Operation mit höherer Priorität folgen, musst du die Eingabe erst mal auf dem Stack sichern. Wenn nicht, kannst du anfangen, den Stack wieder abzubauen. Ein Tipp: Mach's erst mal ohne Klammern.

Wie kann man denn so etwas vergessen? Bearbeitest du die Message Map etwa von Hand? :confused:

Wenn du nicht weißt, was der Unterschied ist, wie willst du dann beurteilen, ob der Wikipedia-Text falsch ist? Was ist denn falsch an der Beschreibung in der Wikipedia?

Du legst einfach nicht nur die Klammern, sondern auch die Operanden und Operatoren in dem Kellerspeicher ab. Und sobald du etwas hast, das du ausrechnen kannst, tust du das. Sollst du Punkt-vor-Strich o.ä. beachten, oder nur die Klammern?

Wenn das List Control den Style LVS_OWNERDRAWFIXED hat, sendet es WM_DRAWITEM an sein Elternfenster. Soweit ich weiß, kannst du damit aber nicht die Höhe der Items beeinflussen. Schau doch mal hier rein: The Code Project - Free Source Code and Tutorials

Du musst im Elternfenster des List Controls die Nachricht LVN_GETDISPINFO bearbeiten.

Das passt nicht. OFN_CREATEPROMPT ist 8192. Wo kommt der andere Wert her? Bitte mal ganz genau: Welchen Wert haben flags_Temp und DateiMenue.Flags vor und nach dem fehlgeschlagenen Aufruf? Wenn das nicht beabsichtigt ist, bin ich mir sicher, dass du dir den Speicher zerschossen hast. Sag doch einfach, welchen Wert CommDlgExtendedError zurückgibt.

14336 ist OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST | OFN_CREATEPROMPT. Das widerspricht sich doch. OFN_CREATEPROMPT bedeutet, dass der Benutzer bei Angabe eines Dateinamens, der nicht existiert, bestätigen muss. OFN_FILEMUSTEXIST bedeutet, dass der Benutzer gar keine Datei angeben kann, die nicht existiert. Was willst du mit dieser Kombination erreichen? Was heißt "Es kommt"? GetLastError ist für GetOpenFileName nicht zuständig, ich weiß nicht, warum du das immer noch aufrufst. Und CommDlgExtendedError kann diesen Fehlercode nicht zurückliefern. Ich vermute immer noch, dass du dir irgendwo in deinem Programm den Speicher zerschießt, und es sich eben genau da bemerkbar macht.

NetUserAdd. Oder ADSI, wenn es um eine Domäne geht.

Ich würde da eher Dinge wie Determiniertheit, Terminierung und Laufzeitkomplexität anführen. Die Wikipedia bietet da einige Anhaltspunkte.

Was heißt "funktioniert nicht"? Landet die Exception nun in deinem Code, oder wird sie vorher gefangen?

Die Datenstromumleitungen der Shell funktionieren nicht direkt in einem system-Aufruf. Das musst du das Perlskript fragen. Erstell ein Shellskript und führ das mit system aus.

Wird sie denn gefangen, bevor der Aufruf wieder in deinem Code landet? Wenn ja, ist das nicht wirklich ein Problem.

Wenn du von einer zweistelligen Zahl ihre Quersumme abziehst, können nur ganz bestimmte Zahlen herauskommen, es sind immer Vielfache von 9. Alle diese Zahlen haben in der Liste dasselbe Symbol.

Du kannst auch 8 if-Anweisungen hintereinanderstellen, dann brauchst du keine Schleife Du könntest auch eine Lookup-Tabelle mit allen 256 Ergebnissen erstellen, und deinen Bytewert als Index auf diese Tabelle benutzen. Du könntest auch mit dem Logarithmus zur Basis 2 arbeiten. Kommt halt drauf an, was du dir unter "einfacher" vorstellst

Der Richtungsvektor ist einfach Zielpunkt minus Startpunkt, und die beiden hast du doch, oder?

Eben, "scheinbar". Warum hier die MFC benutzt werden, kannst du nicht wissen. Wenn dich deine eigenen Spekulationen erschrecken, kann das auch daran liegen, dass es eben Spekulationen sind. Wenn im einen bestehenden Projekt Portabilität keine Anforderung ist, und überall durchgängig die MFC verwendet werden, ist es Unsinn, eine weitere Bibliothek - Standard oder nicht - hinzuzufügen. Das verschlechtert nur die Wartbarkeit des Codes. Religiöses Refactoring als Selbstzweck lohnt sich nicht.

Hallo caytchen, Willkommen auf dem Board. Offensichtlich, weil man die MFC verwendet. Wenn du etwas dagegen hast, kannst du gerne sachliche und begründete Kritik anbringen. Also reiß dich bitte zusammen. Deine Prüfung auf good in der Schleifenbedingung ist übrigens überflüssig.

C oder C++? Ich würde das gar nicht als zweidimensionales Array machen, sondern als eindimensionales Array einer Struktur mit zwei int-Membern. Denn so wie es aussieht, ändert sich die Größe der zweiten Dimension ja nicht. Ein eindimensionales Array kannst du, wie es mit dynamischen Arrays üblich ist, vergrößern (realloc in C, new und umkopieren in C++ - oder besser gleich std::vector).

Dann vermute ich, dass du dir schon vorher, wahrscheinlich durch eine Bereichsüberschreitung, den Heap zerlegt hast. Benutzt du eigentlich C oder C++?

Weil du etwas geändert hast. Du lieferst nicht annähernd genug Informationen, dass man dir damit helfen könnte. Wie sieht der Callstack aus? Sind die Parameter in Ordnung? Falls ja, hast du dir möglicherweise schon vorher irgendwo den Heap zerschossen, es macht sich nur erst hier bemerkbar.

Wie du an der Fehlermeldung sehen kannst, ist das eine "First Chance Exception". Das bedeutet, dass eine Exception innerhalb eines try-Blocks aufgetreten ist, dessen catch-Teil auf die aufgetretene Exception "passt". Die Exception wird geworfen und im catch-Block behandelt. Ob ein Debugger bei so etwas anhält, ist einer Frage der Einstellungen des Debuggers. Dein lokaler Debugger ist offenbar so eingestellt, dass er bei First-Chance-Schutzverletzungen anhält, der Remote-Debugger aber nicht. Hat dieser try-catch-Block denn an dieser Stelle wirklich einen Sinn, oder war das nur die Symptombehandlung eines Laufzeitfehlers?

Das kann man aus dem Callstack allein nicht ablesen. Sicher. Ist Zeile 197 der CreateWindow-Aufruf?

Die Fehlermeldung lässt auf einen Lesezugriff über einen Nullzeiger schließen. Wenn der Fehler im Debugger auftritt, kannst du über die Aufrufliste (Callstack) prüfen, aus welchem Teil deines Codes der problematische Aufruf kam, und dort prüfen, welcher Zeiger Null ist, der nicht Null sein darf. Dass es beim Debuggen passiert und sonst nicht, legt ein Timingproblem nahe. Hantierst du mit Threads? Wie "übergibst" du diese Struktur?

std::string ist (wie alles, was im Namespace std liegt) Bestandteil des C++-Standards. Wo ist das Problem? Ob du das kannst, weiß ich nicht. Falls du wissen wolltest, ob du das darfst: Ja, wenn du meinen Nick richtig schreibst