Klotzkopp

Es gibt ein eigenes Unterforum für die Prüfung. Da sind auch schon einige Threads drin. Lies mal

Kann ich dir nicht sagen. Ich kenne die Einstellmöglichkeiten des Borland-Compilers nicht. Anscheinend hast du nicht alle übertragen, sonst würde es funktionieren. Man kann den Standard nicht ändern, aber man kann das Verhalten des Compilers beeinflussen, so dass dieser sich nicht mehr an den Standard hält oder Erweiterungen einbringt. Oder hat dir jemand garantiert, dass dieser Code reines Standard-C ist und nicht irgendwelche compilerspezifische Erweiterungen benutzt?

Das liegt vermutlich an unterschiedlichen Projekteinstellungen.

Es ging mir um den vollständigen Dateinamen, weil ich ausschließen wollte, dass du nur eine Codedatei öffnest.

Ich frag auch gern nochmal: Welche Datei?

Welche Datei hast du denn benutzt, um das Projekt zu öffnen?

Es ist egal, ob das Präprozessorsymbol ID3LIB_EXT_H_INCLUDED oder TINTIN_IST_DER_GROESSTE oder ALLYOURBASEAREBELONGTOUS heißt. Es muss nur eindeutig sein, d.h. du darfst es nirgendwo sonst benutzen, nur für den Includewächter dieser einen Headerdatei. Damit man sofort erkennt, dass es sich um einen Includewächter handelt, ist natürlich die erste Form zu bevorzugen.

Alles mögliche hast du offenbar nicht versucht, sonst wärst du auf mindestens eine dieser Möglichkeiten gestoßen: - Menü: View -> Designer - Rechtsklick im Form1-Codefenster -> View Designer - Rechtsklick auf Form1.vb im Solution Explorer -> View Designer - Doppelklick auf Form1.vb im Solution Explorer

int x = deinbool ? 1 : 0;

Die MSDN Library sagt: Windows Me/98/95: If you are using LoadLibrary to load a module that contains a resource whose numeric identifier is greater than 0x7FFF, LoadLibrary fails. If you are attempting to load a 16-bit DLL directly from 32-bit code, LoadLibrary fails. If you are attempting to load a DLL whose subsystem version is greater than 4.0, LoadLibrary fails. If your DllMain function tries to call the Unicode version of a function, LoadLibrary fails.

/******************************************************************** * Get the characteristics of the rowset (the ColumnsInfo interface). ********************************************************************/ HRESULT myGetColumnsInfo ( IRowset* pIRowset, // [in] ULONG* pnCols, // [out] DBCOLUMNINFO** ppColumnsInfo, // [out] OLECHAR** ppColumnStrings // [out] ) { IColumnsInfo* pIColumnsInfo; HRESULT hr; if (FAILED(pIRowset->QueryInterface(IID_IColumnsInfo, (void**) &pIColumnsInfo))) { DumpError("Query rowset interface for IColumnsInfo failed"); return (E_FAIL); } hr = pIColumnsInfo->GetColumnInfo(pnCols, ppColumnsInfo, ppColumnStrings); if (FAILED(hr)) { DumpError("GetColumnInfo failed."); *pnCols = 0; } pIColumnsInfo->Release(); return (hr); } [/code] Quelle:http://msdn.microsoft.com/library/en-us/dnodbc/html/msdn_ole4odbc.asp?frame=true (Abschnitt: Describing Query Results)

Wie man CreateProcess benutzt, steht in der MSDN Library: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecoreos5/html/wce50lrfCreateProcess.asp

Warum startest du das Programm denn über cmd.exe und nicht direkt?

Genauso viel wie ein gleich langes Telefonat. Das kommt natürlich auf die Tarife deines Telefonanbieters an. Und wie lange es dauert, kommt auf den Inhalt der Seite und die Qualität an.

Um das ein wenig zu konkretisieren: "Meistens" bedeutet hier: Bei Microsoft Visual C++.

Wozu brauchst du das denn? Vielleicht gibt es ja einen besseren Weg, das zu erreichen.

Ich glaube, ich kann froh sein, dass du meinen Namen zumindest einmal richtig geschrieben hast Wenn sie nur als Container für die Daten dient, sollte die Klasse eigentlich von gar keiner anderen Klasse abgeleitet sein.

Warum ist deine Datenklasse überhaupt von CDialog abgeleitet? Ist deine Datenklasse ein Dialog? Falls nicht, ist das ein Designfehler. Füg in der Datei, in der dieser Fehler gemeldet wird, hinter der Includedirektive für stdafx.h folgendes ein: #include "resource.h" Falscher Ansatz. Bringen, nicht holen. Schreib deinen Code von dort aus, wo du die Daten hast, nicht von dort, wo du sie brauchst. Das ist doch offenbar ein Teil aus der InitInstance-Methode der App-Klasse: CProgramm2Dlg Dialog1; CDialog2 Dialog2; CParent ParentSheet("Test"); ParentSheet.AddPage(&Dialog1); ParentSheet.AddPage(&Dialog2); m_pMainWnd = &ParentSheet; int nResponse = ParentSheet.DoModal(); if (nResponse == IDOK)[/code] Hier erzeugst du die Propertypages, die den Zeiger auf die Instanz der Datenklasse brauchen. Hier ist der richtige Punkt, um anzusetzen: [code] CProgramm2Dlg Dialog1; CDialog2 Dialog2; [b]Dialog1.m_pData = &Daten; Dialog2.m_pData = &Daten; // oder wie die Variablen bei dir heißen[/b] CParent ParentSheet("Test"); ParentSheet.AddPage(&Dialog1); ParentSheet.AddPage(&Dialog2); m_pMainWnd = &ParentSheet; int nResponse = ParentSheet.DoModal(); if (nResponse == IDOK)

Richtig. Nein. Die Includewächter (#ifndef/#define/#endif) in jeder Headerdatei schützen dich vor Mehrfachincludes. Warum erstellst du eigentlich immer einen Zeiger und ein Objekt? Nein, dann hast du einen Zeiger auf das Objekt, das du da erstellt hast. Das hat mir dem eigentlichen App-Objekt nichts zu tun. Dasselbe Problem, das du auch ursprünglich hast. Sind CProgramm2Dlg und CDialog2 deine Propertypage-Klassen? Dann hast du doch da alles, was du brauchst.

Nein. Wie kommst du darauf? Du kannst die Data.h in Programm2.h einbinden. Ich habe auch geschrieben, dass eine Vorwärtsdeklaration reicht, wenn du nur einen Zeiger oder eine Referenz hast. Das ist hier nicht der Fall. Genau.

Dann fehlt in dieser Datei die Includedirektive für die Datenklasse. Auch nur zur Info. Gut. Dann sollte deine App-Klasse einen CData-Member haben (keinen Zeiger). Dann braucht jede Propertypage-Klasse einen CData*-Member. Der muss beim Erzeugen der Propertypage-Objekte auf die Adresse des App-Members gesetzt werden. Da du vermutlich ein globales Objekt der App-Klasse hast, sollte es nicht weiter schwer sein, da ranzukommen.

HALT! Nicht "also"! Ab hier läuft's schon falsch. Erstens ist es sinnlos, in der App-Klasse einen Zeiger auf die Datenklasse anzulegen. Zweitens: Fang doch nicht immer gleich mit irgendwelchen wilden Workarounds an, nur weil etwas nicht gleich funktioniert. Beim geringsten Problem rennst du in irgendeine Richtung los und wirfst ziellos mit Code um dich. So kommst du auf keinen grünen Zweig. Zeig den Code, der die obige Fehlermeldung erzeugt. "gleich mit deklarieren" hilft nicht weiter. Aber ich denke, wir sollten das jetzt mal richtig machen. Jetzt wird erst mal geplant. Welches Objekt "besitzt" das Datenobjekt, d.h. von wessen Lebenszeit ist das Datenobjekt abhängig? Welche Objekte benötigen Verweise auf das Datenobjekt, beeinflussen aber nicht seine Lebensdauer? Wenn du diese Fragen nicht ganz klar beantworten kannst, solltest du keine einzige Zeile Code erzeugen, denn dann bist du mit der Planung noch gar nicht fertig.

Nein. Es ist nicht so, dass ein Auslandskunde kein Stammkunde sein kann. Bei einem Auslandskunden ist es egal, ob er ein Stammkunde ist. Das ist ein Unterschied. Für jede der 16 Kombinationen der Bedingungen ist die Aktion genau festgelegt. Dass sich manche Bedingungen manchmal nicht auswirken, ist ja überhaupt erst der Grund dafür, dass man konsolidieren kann.

Soll das die ganze Tabelle sein? Dann ist sie nicht vollständig. Das ist irrelevant. Die Entscheidungstabelle berücksichtigt nicht, ob bestimmte Kombinationen von Bedingungen überhaupt möglich sind. Das löst sich dann hinterher bei der Konsolidierung sowieso auf. Was zusammengefasst werden kann, ist von der Bedeutung der Bedingungen unabhängig. Es geht nur noch um den Inhalt der Tabelle. Ich würde das so zusammenfassen: Auslandskunde j j n n n n Stammkunde - - j n n n Betrag <= 25 - - - j n n Kreditkarte OK j n - - j n Lastschrift x Online x Kreditkarte x x Vorauskasse x x [/code]

Wenn man die doppelten Elemente so einfach eliminieren kann wie hier, könnte man das durchaus als unnötige Redundanz werten. Denn wenn ein Programmierer stumpf nach diesem PAP ein Programm schreibt, haben wir doppelten Code. Man könnte z.B. auch ein Unterprogramm draus machen. Ja. Die Rechtecke stellen übrigens Operationen dar, keine Zustände. Das Problem stellt sich doch gar nicht. Du kannst die Frage bei einer einfachen Verzweigung immer so formulieren, dass eine Ja/Nein-Antwort ausreicht. Wenn du "Betrag <= 25 Euro" schreibst, verschwindet das Problem von selbst. Mir fallen zwei Dinge auf: Die Unterscheidung bei der Betragshöhe ist falsch, wenn es um genau 25 Euro geht. Denn dann soll laut Aufgabenstellung auch noch das Onlinebezahlsystem benutzt werden. Zweitens sollten die Zusammenführungen auf den Pfeilen stattfinden, nicht an den Operationen, weil sonst die Richtung des Ablaufs nicht mehr eindeutig ist.