Klotzkopp

Prinzipiell gibt es da keine Unterschiede. Hast du ein konkretes Problem? Bitte nur ein 'r'.

ono, lass das mit GetMessage. Du scheinst nicht genug von Windowsprogrammierung zu verstehen, als dass dich das weiterbringen würde. Zu CreateProcess findest du hier im Forum jede Menge Beispiele. Benutzer aber bitte nicht eine Schleife mit GetExitCodeProcess, um das Ende des Prozesses abzuwarten. Dafür gibt es WaitForSingleObject.

Eine reine Lese-API kenne ich nicht. Ich glaube auch nicht, dass es so etwas gibt. Warum würde sich jemand die Mühe machen, eine API zu implementieren, die nur Lesezugriffe bietet? Niemand zwingt dich, die Klassen zu benutzen. Zu deinen persönlichen Erfahrungen kann ich natürlich nichts sagen. Eigenschaften wie "unfreundlich" und "aufgebläht" lassen sich nicht objektiv bewerten. Das sollte aber IMHO auch keine Entscheidungsbasis für oder gegen eine API sien. Da würde ich klare und messbare Kriterien aufstellen und vor allem auch messen. Lass dir ein Datenbankprojekt vom Assistenten erzeugen, und übernimm nur die Recordset-Klasse (ODBC/MFC) bzw. den Accessor (OLEDB/ATL). Den Rest kannst du dann so schlank halten, wie du möchtest.

Das ist hoffentlich nicht ernst gemeint. Wenn du hier auf Hilfe hoffst, solltest du etwas mehr Eigenleistung erkennen lassen. Denn wie du sagtest: Du musst schreiben. Das Forum ist kein Hausaufgabenservice. Wir helfen dir gern, wenn du konkrete Probleme hast, aber wir machen nicht deine Aufgaben.

Was ist für dich Overhead? Hast du das gemessen , oder weißt du das vom Hörensagen, oder ist das ein Bauchgefühl? Kommt auf deine Erfahrungen an. Ich kann hier lang und breit von der Geschwindkeit von OLEDB erzählen, wenn du Probleme mit der Anwendung hattest, bringt das nichts. Den Satz habe ich nicht verstanden. "Elegant" sind Datenbankzugriffe mit C++ grundsätzlich nicht. Wenn du elegant willst, nimm C# oder PHP oder was ganz anderes. Was genau verstehst du unter "Umfang" und "Overhead" und "und so"?

Wieso? Was hat die Datenbankanbindung mit der Darstellung zu tun? ODBC geht auch ohne MFC, ist aber nicht schön. Warum sträubst du dich so gegen die üblichen Datenbank-APIs? Das liest sich in etwa so, als ob du von A nach B willst, aber nicht mit dem Fahrrad, mit Bus oder Bahn, Auto, Flugzeug oder Schiff. Dann bleibt dir nur, zu laufen. Das ist mühsam und langwierig, aber wohl kaum "schlank".

Ein paar mehr Details wären nett. Wie lang ist denn die "Wartezeit"? Wie sieht dein Code aus? Der Wortlaut der "anschließenden Meldung" wäre auch interessant gewesen.

In welcher Form hast du dein Hintergrundbild denn vorliegen? Als Bitmapressource? Als externe Datei?

http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/reference/functions/shellexecute.asp Da steht alles, was du wissen musst.

Zeig uns deinen Code, sag, was genau nicht funktioniert, und wir helfen dir. Wir geben gern Verständnishilfe, fertige Lösungen zum Abschreiben nicht so gern. Bitte nur ein 'r'

ShellExecute mit "print" als Operation sollte die Datei auf dem Standarddrucker ausgeben. Zu ShellExecute solltest du genügend Beispiele im Forum finden können.

Mal davon abgesehen, dass du einen std::string ganz einfach in einen Zeiger auf const char umwandeln kannst: Warum benutzt du fputs?

Die Handles für STDOUT und STDERR dürfen nicht gleich sein. Nimm DuplicateHandle. Außerdem dürfte es dem Prozess nicht gefallen, wenn ihm sein eigener Output wieder als Input vorgesetzt wird. Du brauchst mindestens zwei Pipes.

Um eine Funktion aufrufen zu können, muss sie weiter oben im Code zumindest deklariert werden. Deine Funktion steht weiter hinten, darum klappt das nicht. Einfachste Lösung: Schieb die Funktionsdefiniton vor den Aufruf. Bitte gib immer die Fehlermeldung an. Auch wenn mir hier das Problem klar ist: Die genaue Fehlermeldung ist immer sehr hilfreich. Zum Problem: Eine Threadfunktion darf keine nichtstatische Memberfunktion sein, weil dann der Funktionzeigertyp wegen des verdeckt übergebenen this-Zeigers nicht mehr passt.

Dann solltest du die Finger von der WinAPI im Allgemeinen und diesem Tutorial im Besonderen lassen. Die WinAPI ist eine reine C-API. Damit lernst du die native Windowsprogrammierung, aber ganz sicher kein sauberes C++.

Soweit ich mich erinnere, musst du alle drei Handles angeben, sonst funktioniert das nicht. Das STDERR-Handle kannst du allerdings mit DuplicateHandle aus dem STDOUT-Handle erzeugen.

EnumDisplayDevices gibt es nicht für NT und Windows 95. Daher ist die Deklaration in einen #if-Block eingeschlossen: #if(WINVER >= 0x0500) WINUSERAPI BOOL WINAPI EnumDisplaySettingsExA( IN LPCSTR lpszDeviceName, IN DWORD iModeNum, OUT LPDEVMODEA lpDevMode, IN DWORD dwFlags); [/CODE] Du musst also vor dem #include WINVER entsprechend definieren.

Numelle, genau die gleiche Frage hattest du erst gestern in diesem Thread gestellt. Wenn du mit den Antworten in diesem Thread nicht weiterkommst, dann schreib das bitte dort. Einfach einen neuen Thread mit derselben Frage zu erstellen, ist hier nicht gern gesehen und den Helfern im anderen Thread gegenüber sehr unhöflich. -> Thread geschlossen, im verlinkten Thread geht's weiter.

Ich verstehe das Problem nicht. Was meinst du damit, du findest den passenden Parameter nicht?

Das liegt aber eher daran, dass du C# wie C zu benutzen versuchst. Viele erprobten Vorgehensweisen sind nicht von einer auf eine andere Sprache übertragbar.

CreateProcess ist da genau richtig. Du kannst in der STARTUPINFO-Struktur drei Handles angeben, die dann für den erzeugten Prozess STDIN, STDOUT und STDERR ersetzen. Beispielcode habe ich leider gerade nicht. Und da das nichts mit Standard-C++ zu tun hat: Verschoben nach C++: Compiler, IDEs, APIs

Schau dir mal EnumDisplayDevices, EnumDisplaySettings und ChangeDisplaySettingsEx an.

Für welches Betriebssystem? Du willst darauf Einfluss nehmen, was für einen Monitor du hast? Das geht wohl nur dadurch, dass du einen anderen Monitor anschließt

Hier ist es noch egal, wenn man nur das Ergebnis betrachtet. Aber sobald du Zahlen mit mehr als 15 Stellen hast, bist du mit double am Ende der Genauigkeit angekommen. Mit __int64 hast du immerhin fast 19 Stellen. Allgemein solltest du auf Fließkommatypen verzichten, wenn es mit Ganzzahltypen auch geht.

if(_atoi64(s) > 8000000000 && _atoi64(s) < 10000000000) cout << s << endl;[/CODE] Der Cast bei cout ist unnötig.