Ermitteln, ob Fenster eine Konsole ist

hustbaer

modifiziere lieber die SFML fensterklasse so dass du an das handle rankommst

@hustbaer
Ich vermute, dass das nicht geht, weil SFML auch aus einer privaten (closed source) Implementierung besteht.

NES-Spieler

Martin Richter schrieb:

Ein COnsolen Fenster kann man an der Fensterklasse ConsoleWindowClass erkennen.

Wo soll sich die denn befinden? In der WinAPI scheint sie jedenfalls nicht zu liegen.

Martin Richter schrieb:

Dennoch finde ich Dein vorgehen etwas komisch und verstehe nicht wirklich wo Dein Problem ist.

Das Problem ist folgendes: Ich benutze die SFML. Die SFML kann zwar ein Fenster erstellen, hat aber selbst keine Möglichkeit, Menüs und das ganze Zeug hinzuzufügen. Da aber ein Windows-Benutzer, wenn er ein Spiel spielt und dort Optionen festlegen will, nicht mit irgendwelchen Kommandozeilenparametern rumhantieren will, hab ich mir gedacht, daß ich der Windows-Version des Programms ein Menü hinzufüge und von dort aus dann ein paar plattformabhängige Dialogfelder, mit denen er Einstellungen (Steuerung etc.) vornehmen kann, während der Linuxbenutzer eben mit den Kommandozeilenparametern vorlieb nehmen muß. Da es in der sf::Window -Klasse aber keine plattformspezifische Funktion gibt, die mir das HWND zurückliefert, so daß ich das nehmen kann, um ein Menü ranzubasteln, muß ich mir eben sämtliche Fenster manuell ermitteln. Dazu benutze ich EnumWindows , das mir alle Fenster auf dem Bildschirm gibt. Und da filtere ich dann mit GetWindowThreadProcessId und GetCurrentProcessId die Fenster heraus, die zu meiner eigenen Anwendung gehören. Und dann muß ich eben rausfinden, welches dieser Fenster mein Hauptfenster ist. Wenn Du eine bessere Methode hast, das Fensterhandle zu ermitteln, nur her damit.

nwp2 schrieb:

Schon GetConsoleWindow versucht?

Das wäre im Prinzip genau das, was ich brauche. Aber leider geht das erst ab Windows 2000. Und obwohl ich jetzt inzwischen Windows XP auf dem PC hab, will ich trotzdem, daß das ganze noch unter Windows 98 läuft, erst recht, wenn die Kompatibilitätsprobleme nur durch so ein Zusatzfeature zustandekommen würden, auf das man im absoluten Notfall auch verzichten könnte.

hustbaer schrieb:

modifiziere lieber die SFML fensterklasse so dass du an das handle rankommst

Ja, klar, und wenn mir die std::string -Klasse nicht gefällt, modifiziere ich einfach mal den C++-Standard.

Benutzername_ schrieb:

@hustbaer
Ich vermute, dass das nicht geht, weil SFML auch aus einer privaten (closed source) Implementierung besteht.

Doch, das würde schon gehen. Aber ich find's eben scheiße, den bestehenden Quellcode zu ändern. Damit kann das Program ja nur noch mit meiner spezifischen Variante der SFML kompiliert werden.

NES-Spieler schrieb:

Martin Richter schrieb:

Ein COnsolen Fenster kann man an der Fensterklasse ConsoleWindowClass erkennen.

Wo soll sich die denn befinden? In der WinAPI scheint sie jedenfalls nicht zu liegen.

Versuch's mal mit ... http://msdn.microsoft.com/en-us/library/ms633582

Win98 ist
Selbst wir im tiefsten Dschungel haben schon Windows 7.
Mach dir nicht unnötig das Leben schwer, Junge.

NES-Spieler

Balu der Bär schrieb:

Versuch's mal mit ... http://msdn.microsoft.com/en-us/library/ms633582

Das geht leider auch nicht, da ich ja nicht wissen kann, welchen Klassennamen die Fenster haben. Die sind ja auch verdeckt.

Balu der Bär schrieb:

Win98 ist
Selbst wir im tiefsten Dschungel haben schon Windows 7.

Naja, aber die SFML läuft nunmal auch unter Windows 98. Und das Menü ist nur ein sekundäres Zusatzfeature. Wegen dem will ich nicht die Kompatibilität einschränken.

Man kann doch, soweit ich weiß, auch in WinAPI-Anwendungen nochmal zusätzlich irgendwelche extra Konsolenfenster starten. Wie würde man denn bei denen ermitteln, daß es sich um ein Konsolenfenster handelt?

Martin Richter

NES-Spieler schrieb:

Balu der Bär schrieb:

Versuch's mal mit ... http://msdn.microsoft.com/en-us/library/ms633582

Das geht leider auch nicht, da ich ja nicht wissen kann, welchen Klassennamen die Fenster haben. Die sind ja auch verdeckt.

Wieso? GetClassName funktioniert immer wenn Du ein Windows Handle hast!
Was soll da verdeckt sein?
Nimm Spy++ und schau Dir alles an...
Du machst es komplzierter als es das Ganze ist!

NES-Spieler

Martin Richter schrieb:

Wieso? GetClassName funktioniert immer wenn Du ein Windows Handle hast!
Was soll da verdeckt sein?

Na, ganz einfach: Da ich die Fenster ja nicht selbst erstelle, sondern sie durch die SFML erstellen lasse (bzw. das Konsolenfenster wird von Windows selbst erstellt) und somit den ClassName auch nicht selbst angegeben hab, weiß ich ja immer noch nicht, welches Handle jetzt zu meinem Hauptfenster gehört. Beispiel: Ich hab mir alle HWNDs, die zu meinem Programm gehören, geben lassen. Das sind jetzt, sagen wir mal, zwei Stück (Hauptfenster und Konsole). Und von denen laß ich mir nun den jeweiligen Klassennamen geben. Dann bekomme ich meinetwegen zurückgeliefert:
Klassenname 1: "Bla"
Klassenname 2: "Blubb"
Dann weiß ich immer noch nicht, welches von den Dingern jetzt mein Konsolenfenster ist und welches das Hauptfenster.

Doch, weil der Klassenname eines Konsolenfensters "ConsoleWindowClass" ist.
Aber du kannst den Namen eh nicht holen, da du auf Win98 beharrst

NES-Spieler

Balu der Bär schrieb:

Doch, weil der Klassenname eines Konsolenfensters "ConsoleWindowClass" ist.

Und Du bist Dir sicher, daß das in jedem Fall und überall garantiert ist? Auf Windows 98 lautet der Name zum Beispiel "tty" und wer weiß, ob da in der nächsten Version von Windows nicht schon wieder was ganz anderes steht. Ich müßte zumindest irgendwo nachlesen können, daß der Name von nun an immer "ConsoleWindowClass" ist, ansonsten ist mir diese feste Abfrage des Strings etwas unsicher.

Balu der Bär schrieb:

Aber du kannst den Namen eh nicht holen, da du auf Win98 beharrst

Doch, diese Funktion läuft unter Windows 98. (Wenn die MSDN sagt, daß man für die Funktion minimum Windows XP braucht, ist das eine schlichte Lüge.)

nwp2

NES-Spieler schrieb:

Mit EnumWindows hol ich mir alle Fenster, mit GetWindowThreadProcessId ermittle ich die Prozeß-ID des jeweiligen Fensters und mit GetCurrentProcessId gleiche ich ab, ob das Fenster zu meinem eigenen Programm gehört. Jetzt hab ich also wieder sämtliche HWND-Variablen meines Programms zur Hand.

Du könntest genau das machen, aber noch bevor du Fenster öffnest. Damit gibt es nur ein einziges Fenster was dir gehört und das ist die Konsole.

BTW Win98SE ist mein Lieblingswindows, aber nachdem selbst Microsoft den Support dafür seit Jahren eingestellt hat solltest du dir nochmal überlegen ob dein Programm unbedingt Win98-kompatibel sein muss.

NES-Spieler

nwp2 schrieb:

Du könntest genau das machen, aber noch bevor du Fenster öffnest. Damit gibt es nur ein einziges Fenster was dir gehört und das ist die Konsole.

Leider ist mir eben noch etwas anderes aufgefallen: Wenn man irgendwas mit Fenstern macht, erstellt die SFML ein Dummy-Fenster, um einen gültigen OpenGL-Kontext zu haben, auch wenn man das eigentliche Fenster erst später erstellt. Das heißt, ich hab am Anfang auf jeden Fall schonmal zwei Fenster: Die Konsole und das Dummy-Fenster. Deshalb bräuchte ich wirklich irgendwas, um die Konsole selbst zu identifizieren.
Wenn ich mich recht erinnere, gibt es doch in der WinAPI eine Möglichkeit, aus einer Fensteranwendung heraus eine Konsole zu erstellen. (Nicht AllocConsole , was ja die Hauptkonsole des Programms erstellen würde. Ich rede von der Möglichkeit, irgendwelche beliebigen Konsolenfenster zu erstellen.) Und für deren Fensterhandles müßte man doch auch die Möglichkeit haben, zu ermitteln, ob es ein Konsolenfenster ist. Wie würde denn das gehen?

nwp2 schrieb:

BTW Win98SE ist mein Lieblingswindows, aber nachdem selbst Microsoft den Support dafür seit Jahren eingestellt hat solltest du dir nochmal überlegen ob dein Programm unbedingt Win98-kompatibel sein muss.

Wenn es um wesentliche spielrelevante Dinge gehen würde, könnte man darüber reden. Aber ich würde es für eine Farce halten, wenn der einzige Grund, Windows 98 auszuschließen, der wäre, daß irgendeine sekundäre Funktion zum Erstellen des Menüs unter Windows 98 noch nicht vorhanden ist. Das hat mich immer bei anderen Anwendungen angekotzt: "Hallo, dieses Programm läuft ab der aktuellen Version nicht mehr unter Windows 98, weil wir jetzt auf Unicode umgestiegen sind. Gut, das Programm ist auf englisch und wir benötigen nichtmal die popeligen ASCII-Zeichen von 128 bis 255, geschweige denn irgendwelche Unicode-Sonderzeichen. Aber wir haben's trotzdem getan, weil Unicode so cool ist."

Wenn du nur zum Spaß versuchst, Win98 kompatibel zu sein, höre ich hier mit meiner Hilfe auf.

NES-Spieler

Was soll jetzt dieser Spruch?

Fedaykin

Für mich besteht wohl eher die Frage warum du jetzt unbedingt ein Windows menü zu deinen Spiel hinzu fügen möchtest? Die Sauberste möglichkeit wäre wohl für deine Spielengine eine Menüklasse zu implementieren und den rest selber zu übernehmen anstatt irgendwie über die Windowsapi ins Windows da irgendwas zu bauen. Generell vermute ich sogar das du probleme bekommst wenn du es schaffst menüs ins Windowsfenster hinzu zu fügen. Da das Applicationfenster eine eigenes Draw und Eventhandling verfügt. Wenn du da jetzt mit irgendwelchen Windowsevents reinhackst könnte die Darstellung nicht mehr korrekt funktionieren (Entweder die Spieldarstellung oder die Menüdarstellung).

NES-Spieler

Fedaykin schrieb:

Für mich besteht wohl eher die Frage warum du jetzt unbedingt ein Windows menü zu deinen Spiel hinzu fügen möchtest?

Weil ich das in einem Spiel, das ich mit DirectX programmieren würde, ebenfalls so machen würde.

Fedaykin schrieb:

Die Sauberste möglichkeit wäre wohl für deine Spielengine eine Menüklasse zu implementieren und den rest selber zu übernehmen anstatt irgendwie über die Windowsapi ins Windows da irgendwas zu bauen.

Ich finde, daß generelle Interface-Einstellungen nicht direkt in den Spielbildschirm gehören. Die Frage, welche Tasten man für Oben, Unten, Rechts, Links und Springen verwendet oder die Frage, welche Auflösung das Fenster haben soll oder ob es im Vollbild oder mit oder ohne Grafikfilter dargestellt werden soll, das sind alles so Sachen, die meiner Meinung nach in ein Menü gehören, das außerhalb des Spielebildschirms steht. Das gibt dem Benutzer dann auch gleich das richtige Look & Feel als wie wenn man sich da erst durch irgendwelche Spielemenüs hangeln muß. Ich weiß, sowas gibt's in richtigen Spielen, aber ich finde das nicht so prickelnd.

Fedaykin schrieb:

Generell vermute ich sogar das du probleme bekommst wenn du es schaffst menüs ins Windowsfenster hinzu zu fügen. Da das Applicationfenster eine eigenes Draw und Eventhandling verfügt. Wenn du da jetzt mit irgendwelchen Windowsevents reinhackst könnte die Darstellung nicht mehr korrekt funktionieren (Entweder die Spieldarstellung oder die Menüdarstellung).

Ja, das Problem ist hier tatsächlich das Eventhandling. Ich hab so ein Menü vor einer Weile mal mit der SDL gebastelt. Da konnte man es so machen:

SDL_EventState(SDL_SYSWMEVENT, SDL_ENABLE);

switch (event.type)
{
case SDL_SYSWMEVENT:
	switch (event.syswm.msg->msg)
	{
	case WM_COMMAND:
		if (LOWORD(event.syswm.msg->wParam) == ID_MENU_ITEM)
		{
			// ...
		}
		break;
	}
	break;
}

In der Zwischenzeit ist mir gar nicht mehr in den Sinn gekommen, daß SFML sowas unter Umständen gar nicht liefert. Könnte also sein, daß ich tatsächlich die Arschkarte gezogen hab.

hustbaer

NES-Spieler schrieb:

hustbaer schrieb:

modifiziere lieber die SFML fensterklasse so dass du an das handle rankommst

Ja, klar, und wenn mir die std::string -Klasse nicht gefällt, modifiziere ich einfach mal den C++-Standard.

Benutzername_ schrieb:

@hustbaer
Ich vermute, dass das nicht geht, weil SFML auch aus einer privaten (closed source) Implementierung besteht.

Doch, das würde schon gehen. Aber ich find's eben scheiße, den bestehenden Quellcode zu ändern. Damit kann das Program ja nur noch mit meiner spezifischen Variante der SFML kompiliert werden.

Tu doch was du willst

Fedaykin

Dann geh doch den umgekehrten weg. Anstatt von der SFML ein Fenster erzeugen zu lassen und dann per WINAPI raus zu finden ob es eine Console ist. Erzeuge per WINAPI deine Fenster und erzeuge darauf deine RenderWindow. Damit hast du dein Handle.

Ne, das will er glaube ich auch nicht.

Aus einem anderen Thread:

NES-Spieler schrieb:

Nein, das ist nicht gut. Das Komfortable an der SFML ist ja, daß man einfach nur eine Fenstervariable erstellt und damit hat sich's. Nun will ich ja nicht erst ein komplettes Fenster mit der WinAPI zusammenbauen, sondern das SFML-Fenster nehmen und nur die Teile nativ programmieren, die SFML nicht unterstützt (sprich: Das Menü).