Klotzkopp

Das liegt aber nicht am Code. Kommt gleich wieder der Eingabeprompt, oder hängt das Programm?

Woraus folgerst du, dass main nicht ausgeführt wird? Doch, genau das ist ein massives Problem. Dadurch hast du irgendwann einen Unterlauf in einem der Vectoren, wenn du versuchst, auf das Kennziffer-Element zuzugreifen, das gar nicht da ist.

Hast du einen Algorithmus für das Problem?

Das Ding heißt Destruktor, nicht Dekonstruktor. Und das Problem ist, dass der Parameter von charger::chargeAccu ein handy ist. Das ist "Call-by-value", da wird eine Kopie des handy-Objekts erzeugt, und diese Kopie wird natürlich auch wieder zerstört. Das bedeutet auch, dass charger::chargeAccu den Parameter in keiner Weise verändern kann, weil die Methode nur mit einer Kopie arbeitet. In deinem aktuellen Code wird das handy zwar nicht verändert, sinnvoll wäre es aber schon. Wenn es also irgendwann mal ein handy::setAccuCapacity geben sollte, wirst du bemerken, dass es in charger::chargeAccu nichts bewirkt. Die Lösung ist, den Parameter hier als Referenz zu übergeben.

Das reicht, aber die Klassen sind im Namensraum std. Du musst da also schon std::istream und std::ostream hinschreiben. Und dann gleich Operatorüberladung? Das ist nicht gerade ein Einsteigerthema. Du hast nicht den ganzen Code gezeigt. Ich habe vermutet, dass da irgendwo eine using-Direktive steckt: using namespace std;Mit dieser Direktive sollte dein Code funktionieren, wenn <iostream> eingebunden ist. Allerdings ist das keine gute Idee. Es ist besser, wenn du den voll qualifizierten Namen hinschreibst (also mit std:.

Wahrscheinlich sind an dieser Stelle std::ostream und std::istream nicht bekannt. Im Header wäre es sowieso besser, den Namensraum voll zu qualifizieren. Ansonsten brauchst du entweder eine using-Direktive im Header (schlechte Idee), oder die einbindende Quellcodedatei muss eine solche enthalten (noch schlechtere Idee).

Was da in schaltePfeile drinsteht, ist erstens falsch (wegen der lokalen Variablen) und zweitens unnötig kompliziert. Wirf diese halbfertige if-else-Orgie raus, und setz da einfach die 9 Zuweisung wie in meinem Beispiel rein.

Wieso nicht? Letztendlich ist es egal, worauf du es setzt, anbieten würde sich natürlich ein leerer String. Du musst dann nur am Ende darauf prüfen, und gegebenfalls ein anderes SQL-Statement zusammensetzen, in das du dann eben nicht Temp_fehler, sondern "NULL" einsetzt.

Damit wäre aber der Geradeauspfeil in der obersten Etage unnötig. Naja, egal. Für jeden der acht verbleibenden Pfeile kannst du also eine Bedingung formulieren, wann er angezeigt werden soll. Beispiel: bpfeillinks0 = iEtagennr == 0 && iParkplatznr <= 4; Die anderen kannst du genauso aufbauen.

Damit sollte klar sein, was die Pfeile nach links und rechts bedeuten. Allerdings frage ich mich, wann jemals ein Geradeauspfeil angezeigt werden soll.

Und das heißt konkret? Wie ist das Parkhaus aufgebaut? Wo ist die Einfahrt überhaupt? Was bedeuten die einzelnen Pfeile? Wie bemisst sich die Entfernung von der Einfahrt? Hier fehlen wichtige Informationen.

Was heißt denn "ohne"? Leerer String oder NULL? Das liegt doch ganz offensichtlich daran, dass du weder die Variablen in der Schleife zurücksetzt, noch für "PDU overtemperature" irgendetwas tust, wenn der Schlüsselstring eben nicht gefunden wird. So übernimmst du einfach den Wert des vorhergehenden Datensatzes.

Du kannst dir meinetwegen gern selbst alle Diagnosemöglichkeiten nehmen. Und du kannst auch in deinem Auto die Musik ganz laut aufdrehen, damit du das Klappern nicht mehr hörst. Bedenke aber, dass diese Informationen, die du da absichtlich ausfilterst, für Andere wichtig sein können. Ich vermute mal, dass der Reader mit "max(spielernr)" nichts anfangen kann. Versuch's doch mal mit der int-Variante: SqlDataReader.Item Property (Int32) (System.Data.SqlClient)

Das heißt, es tritt eine Exception auf? Und du löst das Problem, indem du die Meldung entfernst? So kann man's natürlich auch machen. Dir ist schon klar, dass die Exception dann immer noch auftritt, und du nur nichts mehr davon mitbekommst?

Und die MessageBox im Catch-Block? Ist die auskommentiert, um die Diagnose zu erschweren?

Was gibt's denn da groß zu erklären? Spiel doch einfach mal in Gedanken durch, welche Werte schleife annimmt, und welche dadurch zkette->Length-schleife-1 hat.

http://forum.fachinformatiker.de/net/128679-problem-zeichenkette-umgedreht-ausgeben.html

Ist die Zeile mit der #define-Direktive so vorgegeben? Dann wirst du das Programm überhaupt nur zum Laufen bringen können, wenn du FORMAT nicht benutzt. Denn da stecken mehrere Fehler drin.

Das finde ich aber unnötig kompliziert. Wenn diese Stringklasse den Arrayoperator überlädt, warum ihn dann nicht benutzen? Wenn man die Leerzeichen im String zählen will, kann man aber besser gleich std::count benutzen.

feof liefert erst dann nicht mehr 0, wenn fgetc bereits einmal fehlgeschlagen ist. Darum liefert fgetc auch int zurück, nicht char, denn dadurch kannst du den Rückgabewert EOF abfangen. Du musst die Prüfung mit feof (oder auf den Rückgabewert von fgetc) direkt nach dem Aufruf machen, sonst verarbeitest du ein Byte zuviel.

Und was ist das Problem? Dass beim Verschlüsseln kein lesbarer Text herauskommt? Du verschlüsselst übrigens jedes fünfte Byte mit 0 (also gar nicht), weil du die Nullterminierung in V auch zum Verschlüsseln benutzt.

COBOL ist nicht C++. Ich habe bereits deinen ersten COBOL-Thread ins Sonstige-Forum verschoben, diesen werde ich auch verschieben. Bitte beim nächsten Mal selbst darauf achten.

convert_eingabe gibt doch sowieso nichts raus, also stellt sich dort diese Frage nicht. Ich meine ganz konkret, dass du diese komische Klasse rauswerfen solltest. Objektorientierung bedeutet nicht, alles irgendwie in Klassen zu packen. Das habe ich doch schon geschrieben. Wenn du einen System::String^-Parameter hast, dann wirken sich Änderungen an diesem Parameter nicht auf den Aufrufer aus. C_Konvertieren::convert_ausgabe bewirkt gar nichts, dasselbe gilt für den letzten Parameter deiner Berechnungsmethoden.

Du kannst deine Variablen nennen, wie du möchtest. Du kannst aber daran erkennen, dass du wichtigen Code nicht gezeigt hast, nämlich den, aus dem man den Typ von lb_Ergebnis_Anzeige erkennen könnte. Wenn du CLR-Objekthandles als Funktionsparameter benutzt, ist das ein "call by value", d.h. die Funktion kann die Werte nicht ändern, weil sie mit lokalen Kopien arbeitet. Benutze System::String^% als Parametertyp. Ich möchte mich aber Amstelchens Kritik anschließen. Stringparameter für Berechnungsfunktionen sind Blödsinn, und statt Referenzparametern wären Rückgabewerte besser. Die ganze Klasse C_Konvertieren wäre damit überflüssig. Überhaupt kommt es mir immer sofort komisch vor, wenn eine Klasse eine Tätigkeit beschreibt, und kein Objekt.

Dem Namen lb_Ergebnis_Anzeige nach zu urteilen, liegt es daran, dass du versuchst, das Ergebnis in einer Listbox anzuzeigen. Das Text-Property eines Listbox-Steuerlements verhält sich aber anders als das Text-Property eines Eingabefeldes. Siehe ListBox.Text Property (System.Windows.Forms)