Crush1

Das erzeugt aber keinen "echten" Druckauftrag. Versuch das mal bei Win2k.

Also da gibt´s ein gutes Buch Game-Programming in C++ damit habe ich angefangen - es steht alles gut drin, von 2D bis Pseudo-3D und full 3D sogar bis zu den Insider-Tricks wie Environmental Cube-Mapping und Portal-Rendering, 3D-Clipping, Kollisions-Abfragen. Nach diesem Buch bist Du (wenn Du´s auch alles kapierst) in der Lage Dein eigenes Quake zu programmieren. Hauptthema ist zwar DirectX aber es ist ist auch OpenGL in Grundlagen erklärt! Partikel-, Physik- und weitere Engines werden mit Sourcecode detailliert verklickert. Sogar alles um Net-Play zu integrieren wird in einem Demo-Projekt gezeigt. Mein Geheimtipp! Es kommt zwar MFC ein weng dran, aber nur gaaaanz wenig. Als Ergänzung empfehle ich Dir aber noch einen Blick in ein paar Demo-Sources zu nehmen. Der Quake-Source ist aber nicht zu empfehlen weil der nicht gerade sonderlich übersichtlich gehalten ist.

Du brauchst erst gar keinen pointer zu machen. double d=5.2; int x; x=(int)d; Du meinst, daß Du mit einem Pointer die Typenüberprüfung einfach ausschalten kannst - dabei ist das bei einem normalen cast gar nicht notwendig, der "zwingt" ja zum casten.

Und trotz allem ist der Programmstart mit Strg-F5 immer noch die einfachste Lösungen ohne unnötige includes und Funktionsaufrufe!

Ok, ich habe mir doch die Mühe gemacht, weils doch etwas elementares ist: PRINTDLG pd; // alle Variablen mit 0 initialisieren // dann gibt´s keinen Ärger ZeroMemory(&pd, sizeof(PRINTDLG)); pd.lStructSize = sizeof(PRINTDLG); pd.hwndOwner = hWnd; pd.hDevMode = NULL; pd.hDevNames = NULL; pd.Flags = PD_USEDEVMODECOPIESANDCOLLATE | PD_RETURNDC; // Anzahl Seiten pd.nCopies = 1; pd.nFromPage = 0xFFFF; pd.nToPage = 0xFFFF; pd.nMinPage = 1; pd.nMaxPage = 0xFFFF; DOCINFO di; di.cbSize = sizeof(DOCINFO); di.lpszDocName = "Drucktest"; di.lpszOutput = (LPTSTR) NULL; di.fwType = 0; // Ab hier wird der Druckauftrag gestartet StartDoc(pd.hDC, &di); StartPage(pd.hDC); // das hier wird als Text ins Fenster kopiert // Natürlich sollte der Pen und Zeichensatz/-größe/-farbe vorher eingestellt werden TextOut(pd.hDC, 10, 10, "TestDruck", strlen("Drucker")); // Jetzt könnte man noch DIBs (Bilder) oder sonstwas reinkopieren, wird alles gedruckt // Alles wird als fertig abgeschlossen EndPage(pd.hDC); //Bei mehreren Seiten muß StartPage()/EndPage() mehrfach aufgerufen werden EndDoc(pd.hDC); DeleteDC(pd.hDC);

Ich habs mir mal angeschaut und ich beschreibs lieber nur: Man muß einen Display-Context herstellen diesen mit Items füllen diese mit Text füllen die man aus der Datei rauszieht. Dann einen Drucker-Kontext herstellen. Ein CPrindialog-Objekt erstellen. Dieses mit dem Druckerkontext initialisieren. Den Display-Context in den Print()-Aufruf des Druckerkontexts übergeben und dann sollte theoretisch ein Druckauftrag erzeugt werden - puh! Da ist man vielleicht doch besser bedient den Text im Dos-Fenster mit dem print-Befehl auszudrucken - nur wegen einer Text-Datei lohnt sich der Aufwand wohl kaum.

Klar könnte man das mit CObjects - die kann man Serializen. Einfach alle Datentypen von CObject ableiten und in eine CList reinsetzen. Aber jeder hier im Chat meckert an mir rum wie speicherfressend und langsam doch C++ und STL wäre. Doch auch hier mußt Du bei jedem Zugriff die Datei kopieren weil sich die Daten genauso überschneiden könnten. STL unterstützt solche pfiffigen Dateioptionen meines Wissens nicht. Ich denke die Geschichte mit den Offsets und dem statischen Teil in einer Datei und der dynamische Teil in einer zweiten Datei wäre die einfachste Lösung (hört sich nur so kompliziert an).

Bestimmt hat MySQL ein eigenes Transport-Protokoll und DB-Schnittstelle. Der Name mySQL ist glaub ein wenig trügerisch. Dahinter verbirgt sich eine R3-Schnittstelle und keine simple Datenbank (glaub ich jedenfalls) die aufgesetzte Datenbank befindet sich "hinter" MySQL. Bestimmt gibt es für Zugriffe auch spezielle C-Bibliotheken von SAP und das bestimmt nicht für jeden Heini. Bei OCI von Oracle ist es dasselbe - Informationen nur für Kunden die Kohle liegen lassen. Die doku in der OCI.h war übrigens fast detaillierter als die über 1000-Seitige Programmier-Anleitung. Such mal MySQL nach cpps hs oder dlls ab die verdächtig erscheinen.

Das sollte eigentlich ausreichend sein: #include <afxinet.h> bool Ping::Ping() { CInternetSession Ping("Ping"); CStdioFile*pFile=NULL; pFile=session.OpenURL(lpszURL); (lesen kann man übrigens mit pFile->Read(szBuf,bufsize) delete pFile; session.close(); if (pFile) return true; return false; } also lpszURL kann entweder eine normale URL sein oder auch eine IP. Die IP muß natürlich auch ein String sein!

Also Unix kenn ich nicht, aber versuche doch eine Dummy-Datei in den zu erstellenden Ordner zu speichern mit normalen File-Routinen und lösche dann die Datei. Vielleicht wird der Ordner dann automatisch mit angelegt. Warum darfst Du keine System-Befehle aufrufen? Ist das ein Intelligenztest oder sowas ob Du´s trotzdem packst?

Arbeite doch mit 2 Dateien. Mach die erste so wie gehabt und laß einfach die Attribute Offset-Werte in Datei 2 sein. Ändert sich dann ein Attribut wird nur hinten rangehängt und der Offset darauf gesetzt. Wenn jetzt noch ein Kennzeichen als Löschkennzeichen auf das alte Attribut gesetzt wird, mußte man halt gelegentlich eine Garbage Collection durchführen und den Müll rausschmeißen. Aber dafür geht´s hurtig wenn sich was ändert! Mit Zeigern zu arbeiten ist bei dynamischen Werten immer von Vorteil. Man könnte das ganze auch mit einer Linked-List (single oder double-ended) genausogut realisieren. Wenn man wollte könnte man Änderungen in freigegebenen Dateibereichen reinschreiben - am besten mit der richtigen Größe falls vorhanden, damit alles möglichst optimal ausgenutzt wird. Aber trotzdem wird hier auch eine GB irgendwann benötigt.

Du braucht nur das Programm mit Strg-F5 starten und das Fenster wartet auf eine weitere Taste.

Ist ja klar, daß ein Zeiger kein Array ist ich habe ja ein paar Eigentschaften ausgeschlossen. Aber dann erklärt mir mal das hier: char ax[]="array"; -> character Array ax, im Memory block betrachtet ergibt sich folgendes bild: a r r a y /0 61 72 72 61 79 00 char*px="pointer"; -> pointer auf einen character String bei px steht im Speicher: EC 93 42 00 = Adresse 004293ec ab welcher der String "array" steht. Bis jetzt klar, aber wieso muß ich wenn das Array als Adresse verwendet werden soll nicht referenzieren? Der Beweis: char variable='a'; // normale Variable px=ax; // Zuweisung des Arrays geht so px=&ax[0]; // verlangt den Offset also ist ax ähnlich wie ein Zeiger!!! *px=ax[0]; // Genauso beim kopieren der Inhalte px=&variable; // Die Variable muß referenziert werden damit alles klappt char*py=&ax[0]; // Aber warum muß bei Definition und Deklaration auch referenziert werden? Mir ist es jetzt schon klar, was wann warum verwendet wird, aber rein von der Logik her paßt da irgendwas nicht. Der Offset beim Array muß beim Kopieren verwendet werden, aber beim Zuweisen der Adresse an einen Pointer nicht, und wenn man referenzieren möchte benötigt man den offset aber der *-operator beim Pointer wird verwendet. nochmal: px=ax; px=&ax[0]; macht dasselbe (Adresse kopieren in Pointer) also sollte das hier auch dasselbe machen: *px=&ax; *px=ax[0]; // klappt aber nicht, weil wohl [0] referenziert auch wenn kein & davor steht was bedeutet, daß ax ein Pointer sein muß, der nur nicht im Debugger angezeigt wird, weil man ja ein Array nicht verschieben darf! Also meiner Meinung nach ist ein Array ein Pointer und es wird entweder nur vom Compiler und Debugger verboten auf diesen Array-Pointer zuzugreifen oder es ist das nicht so (was nach dem Assembler-code ja so sein sollte) und man hat wohl einen Design-Fehler in C++ begangen den man bis heute noch nicht ausgebügelt hat! Oder ich bin einfach nur saudoof! Bitte um Stellungnahme ohne Zuhilfenahme von sog. "Fachliteratur" die eh nur zitiert worauf im Register als Quelle verwiesen wird. Ich weiß ja, daß ich nerve, aber ich hab mir C++ nicht ausgedacht und dachte beim Lernen, daß ich wohl nichts kapiert habe weil nicht alles so funktionierte, wie es in der Theorie sein sollte.

Sorry, Tippfehler: HEISST IMMER: #ifndef

Also mit Borland kenn ich mich nicht aus, aber vielleicht könnte es sein, daß sich Deine cpps und hs gegenseitig verschachteln (hört sich ja toll an). Mach mal das vor allen includes: Datei ist irgendeinname.irgendeineendung (ok?) #ifnedf irgendeinname #define irgendeinname #include "irgendwas.irgendneendung" #endif #include alle restlichen normalen Includes, die von anderen Funktionen kommen Der Name bei #define und #ifndef darf natürlich nur einmal im kompletten programm vorkommen - am besten immer den Filenamen verwenden. Damit sollte theoretisch eine Verschachtelung verhindert werden.

Ach so, das geht dann so: Mit Strings: fputs, fputws Write a string to a stream. int fputs( const char *string, FILE *stream ); ACHTUNG: Es werden 0-terminierte-Strings geschrieben!!! Man muß hier falls nicht vorhanden 0er setzen. Oder so mit unformatierten Daten aller Art: fwrite Writes data to a stream. size_t fwrite( const void *buffer, size_t size, size_t count, FILE *stream ); Parameters: buffer Pointer to data to be written size Item size in bytes count Maximum number of items to be written stream Pointer to FILE structure Das ist feiner, so kann man die Schreib-Länge im Aufruf bestimmen. Vielleicht hilft Dir das weiter? Aber auch hier muß ein Pointer auf den double gesetzt werden. Da kommt man einfach nicht rum.

Na das was ich hier so lese finde ich ja genial. Die abgeblasene Prüfung war super - sowas hätte ich selber gerne gehabt - und nun habt ihr so wie´s aussieht den selben Scheiß geschrieben wir wir aus Baden-Württemberg. Die Prüfung hätte ich auch nach dem Berufskolleg durchziehen können ohne auch nur einen blassen Schimmer vom Fach zu haben.

Irgendwie bin ich mir nicht sicher, wie Dein Programm aussehen soll. Ich würde es mir ja gerne mal anschauen. Vielleicht kannst Du´s mir ge-ace-t zuschicken: Crush@bigfoot.de Ich schau´s mir gerne an und versuche dann das Problem zu lösen ok?

Das ist wie mit der Ehe - jede Alternative hat seine Vor- und Nachteile. Es liegt im eigenen Ermessen welches man als das kleinere Übel wählt es sei denn die Umstände legen einen auf was anderes fest. Ist doch super die Qual der Wahl zu haben!

Wenn´s nur ums casten ging - das klappt natürlich warum auch nicht - dann ist´s genehmigt und ok! Ich denke auch das das zu Mißverständnissen führen kann. Alles klar!

Ist kein Scherz - solange ID_STATIC drin steht ist alles gesperrt - frag Bill Gates wieso der sowas macht - ich hab´ auch keine Ahnung wieso?!?!?

Noch als Anmerkung: Initialisierte Variablen werden im Data-Hunk abgelegt! Aber außer mir hat sich bestimmt kein Schwein jemals mit Hunk-Loading befaßt. Ich habe mal einen selber programmiert für einen Cruncher - damit das Programm danach im Speicher ausführbar gemacht werden konnte (korrigieren der Adressen, initialisieren der Data-Hunks, reservieren der BSS-Hunks).

Da ist sehr wohl ein Unterschied: char a[5] legt die Variable auf dem Stack an der vom System aus relativ klein ist. Beim verlassen der Routine wird einfach der Stack wieder aufgelöst und der Stackpointer auf die letzte Position des aufrufenden Programms zurückgesetzt. Geht ruckzuck! new char[5] legt die Variable auf dem Heap an, der so groß ist wie der physikalische und virtuelle Speicher. Deshalb muß diese Variable explizit "aufgeräumt" werden. Ausnahme: Deklarationen in der H: Diese werden sofort beim laden des Programms reserviert-> beim Hunk-Loader (jo wos is´n des?) als BSS-Hunk (nur eine Zahl die klarstellt wieviel Speicher für Variablen beim Laden des Programms reserviert werden müssen).

fputc schreibt leider nur ints. Deshalb ist es sinnvoll den double(bei Win98 8 Bytes) in 2 ints(4 Bytes) zu zerlegen. Das geht so: So kann man sehen, wie groß int oder doubles sind: int x=sizeof(int); // int anschauen double y=sizeof(double); // alles klar? und jetzt das Beispiel: double m_ergebniss; int xhi,xlo; double*p1=&m_ergebniss; // Zeiger auf double xlo=*(int*)p1; // lo als int auslesen xhi=*((int*)p1+1); // hi als int auslesen leider muß man den Pointer definieren, da sonst versucht wird den kompletten double auf int zu kürzen. Das heißt der integer-Wert von m_ergebniss wird in den int übertragen und der Exponent in den Gulli geworfen - das wäre falsch (Information geht verloren). Ein double y=5 ist nämlich byteweise nicht 5 sondern: Hi int Lo int 00 00 00 00 | 00 00 14 40 oder am besten gleich in den fputc setzen: int xhi,xlo; double*p1=&m_ergebniss; fputc(*((int*)p1+1), MeineDatei); // lo fputc(*(int*)p1, MeineDatei); // hi Ich hab´s jetzt nicht getestet aber der fputc sollte es so fressen ansonsten halt ein int xhi,und ein int xlo einlesen über als m_ergebniss abspeichern. Das Einlesen muß also auch wieder als xlo und xhi erfolgen und dann muß ein double im speicher so gefüllt werden. Klappt 100%ig! Die Methode ist zwar ein wenig brutal, aber so funktionierts bestimmt. P.S.: Bei STL lassen sich CObjects ganz einfach in Dateien streamen - da ist dann wurst ob´s ints doubles oder strings sind.

Nun nochmal um Euch alle ganz wirr zu machen: Ich lese meist von rechts nach links um dahinterzusteigen was gemeint ist: char * ist ein Zeiger auf einen char, da aber nichts dabei steht handelt es sich nur um eine Typ-Vereinbarung für einen Zeiger und alle Antworten sind falsch weil einfach mehr nicht da steht (es sei denn man will was reininterpretieren). Ob das das erste Zeichen eines Strings ist ist ungewiß. Aber eines ist sicher: Es ist kein Unterschied zwischen einem Array und einem Zeiger außer die Schreibweise und daß der Zeiger austauschbar ist; beide werden vom Compiler gleich behandelt weil beide auf ein Zeichen des definierten Typs zeigen! Das war nur so als Denkanstoß weil´s zum Thema paßt.