[GELÖST] Wie Fenster auf dem Bildschirm zentrieren?

[Tactive]

Hallo,

ich weiß es klingt vlt. seltsam das ich Nachfrage wie man ein Fenster zentriert, aber ich habe hier ein besonderes problem. Ich habe zwei Monitore und möchte jetzt eigendlich das Fenster auf dem Bildschirm zentrieren, auf dem es sich gerade befindet oder zumindest auf dem Primären Bildschirm zentrieren. Habe da einfach , wie ich es kenne folgendes probiert:

Code: Alles auswählen

void SdlWindow::Center()
{
    RECT desktopRect;
    if (FALSE == GetWindowRect(GetDesktopWindow(), &desktopRect))
        ANEGMA_THROW(ExceptionType::IllegalState, _T("Unable to get desktop rectangle"), NULL);
    
    auto windowDimension = GetDimension();
    int nuXPos = ((desktopRect.right << 1) - (windowDimension.Width << 1));
    int nuYPos = ((desktopRect.bottom << 1) - (windowDimension.Height << 1));
    SetLocation(nuXPos, nuYPos);
}

Zur Zeit wird das Fenster irgendwo in den nicht sichtbaren Raum verschoben, was wohl daran liegt das mir GetWindowRect() die Gesamtgröße des Desktops liefert.

[antisteo]

Die WinAPI bietet eine Funktion EnumDisplaysEx.

[Aramis]

• GetWindowRect fuer das Fenster
• EnumDisplayMonitors mit besagtem Rechteck als Clipping-Rectangle
• Im Callback kriegst du direkt ein passendes Bildschirm-Rechteck, Fenster darin zentrieren und die weitere Enumeration mit FALSE abbrechen.

Alternativ den Mittelpunkt des Fensters nehmen und nacheinander gegen alle Bildschirm-Rechtecke abgleichen. Hat evtl. den Vorteil dass die Auswahl des Monitors damit auf Basis der Fenstermitte vorgenommen wird.

[exploid]

@antisteo Die Winapi hat doch nix mit der SDL zu tun. :)

[antisteo]

Nein ;)

Aber damit kannst du zumindestens unter Windows die Bildschirmausmaße erfahren (unter Linux dann Parallelcode mit der libX schreiben), mit denen sich das Fenster dann auf Position setzen lässt.

Die SDL bietet leider nicht so viele Funktionen, da sie nie so richtig weiterentwickelt wurde. Ich hab zufällig die Sources der libSDL da und es würde bestimmt auch Spaß machen, die SDL weiterzuentwickeln.

[Tactive]

Habs mit einfacher gemacht und zentriere momentan einfach gegen den Primärbildschirm, wenn ich dann später mehr brauche kann ich ja immern och dazuprogrogrammieren. In meinem Quellcode hatte noch den Fehler gemacht, in die falsche Richtung zu shiften - so das die Werte nicht halbiert sondern verdoppelt wurden.

Nein ;)
Aber damit kannst du zumindestens unter Windows die Bildschirmausmaße erfahren (unter Linux dann Parallelcode mit der libX schreiben), mit denen sich das Fenster dann auf Position setzen lässt.
Die SDL bietet leider nicht so viele Funktionen, da sie nie so richtig weiterentwickelt wurde. Ich hab zufällig die Sources der libSDL da und es würde bestimmt auch Spaß machen, die SDL weiterzuentwickeln.

Würde mich bei der SDL auch über eine "offiziell" 64 Bit Version freuen. Habe da vor 1-2 Jahren auch mal mit dem Sam Latinga im Usenet drüber gesprochen. Die SDL stammt ja aus seiner Zeit vor Blizzard, aber seitdem er dort ist, ist quasi Stillstand bei der SDL angesagt - leider. Bugfixes und Anpassungen werden aber weiterhin durchgeführt.

[Tactive]

@antisteo Die Winapi hat doch nix mit der SDL zu tun. :)

Was die SDL nicht hat, muss man halt über die WinAPI rumzubauen. Zwar veliert man dann die Plattformunabhängigkeit aber die ist mir eh nicht wichtig.

[antisteo]

Was die SDL nicht hat, muss man halt über die WinAPI rumzubauen. Zwar veliert man dann die Plattformunabhängigkeit aber die ist mir eh nicht wichtig.

Du kannst ja vorsichtshalber trotzdem ein #ifndef unix drumherum schreiben. (Leider definiert der MS Compiler kein WIN32 oder ähnliches :S).

Check doch einfach mal die SDL Sources aus und schau, ob du dich reinfindest. Ein paar zusätzliche Funktionen geschrieben (SDL_CenterScreen oder so) und dann als Patch angeboten. Hier das Repos:

Code: Alles auswählen

hg clone http://hg.libsdl.org/SDL

Edit:
Hier alle SDL-Unterlibs mit Sourcecode: http://hg.libsdl.org/
Die müssten dann noch mit MinGW gebaut werden, da kannst du gleich für win64 portieren (Option -m64)

[Tactive]

Naja, eigendlich unterstüzt die SDL das Zentrieren des Fensters ja schon, wenn auch etwas unschön gelöst. Dafür muss man in den UMgebungsvariablen der SDL (SDL_putenv) einfach SDL_VIDEO_CENTERED=center setzen. Positionieren geht dann über SDL_VIDEO_WINDOW_POS=x,y. Gilt aber wohl nur für das Erstellen des Fenster und in meiner Fenster-Klasse will ich quasi jederzeit ein Center ausführen können, daher mein drumherum.

Sicherlich könnte man das auch im SDL Source hinzufügen aber dann müsste ich mich noch mit X11 Programmierung beschäftig - was ich momentan nicht will ;)

[antisteo]

Du kannst das Problem ja nur auf Windows-Seite fixen. Es gibt sowieso viele Funktionen in der SDL, die nur auf einer Plattform sind und umgekehrt.
Vielleicht ist das sogar im Source soweit abstrahiert, dass man beim Setzen der Variable eine Rezentrisierung auslösen kann, was das Problem lösen würde.

[Alexander Kornrumpf]

(Leider definiert der MS Compiler kein WIN32 oder ähnliches :S).

Nein.

http://msdn.microsoft.com/en-us/library/b0084kay.aspx

_WIN32 Defined for applications for Win32 and Win64. Always defined.

Hervorhebung von mir.

[antisteo]

(Leider definiert der MS Compiler kein WIN32 oder ähnliches :S).

Nein.

http://msdn.microsoft.com/en-us/library/b0084kay.aspx

_WIN32 Defined for applications for Win32 and Win64. Always defined.

Hervorhebung von mir.

Hey cool! Danke für den Tipp (wir mussten in CG sonst die C++-Files umschreiben, um sie zur Kontrolle mit MS zum laufen zu bekommen)

[kimmi]

Das Symbol heisst auch _WIN32, nicht WIN32. Ich bin da auch schon 1000 mal reingefallen :).

Gruß Kimmi

[antisteo]

Das Symbol heisst auch _WIN32, nicht WIN32. Ich bin da auch schon 1000 mal reingefallen :).

Gruß Kimmi

Naja die Tutorin meinte, der Compiler ist zu keinem vorher bestimmten #define verpflichtet.
Anscheinend wieder mal ne Spätfolge dafür, dass man unerfahrene Studenten als Tutoren verpflichtet.

[Aramis]

Ich verstehe das Problem nicht. Alle Compiler bieten es an Symbole auf der Kommandozeile vorzudefinieren. Dass sie dankenswerterweise standardmaessig welche drinhaben, ist ein Bequemlichkeitsfeature. Aber wenn du willst, kannst du auch LOLCATS Als Windows-spezifisches Token nehmen.

[antisteo]

Ich verstehe das Problem nicht. Alle Compiler bieten es an Symbole auf der Kommandozeile vorzudefinieren. Dass sie dankenswerterweise standardmaessig welche drinhaben, ist ein Bequemlichkeitsfeature. Aber wenn du willst, kannst du auch LOLCATS Als Windows-spezifisches Token nehmen.

Es ging eher darum, festzustellen, welcher Compiler den Code gerade anpackt. Um das nicht in jedem VS-Projekt einstellen zu müssen, wäre es ja gut, dass es der Compiler mir selbst sagt (->was er ja auch tut, wie ich jetzt weiß).

--> Wir sind schon wieder OT.
Die Hauptfrage ist eigentlich beantwortet.

[Krishty]

Es ging eher darum, festzustellen, welcher Compiler den Code gerade anpackt.

So?
_MSC_VER == Microsoft Visual C++ (1600 == 2010; 1500 == 2008; 1400 == 2005; 1310 == .NET 2003; 1300 == .NET 2002; …)
__GNUC__ == GNU Compiler Collection
__INTEL_COMPILER == Intel Compiler Collection

Dass sie dankenswerterweise standardmaessig welche drinhaben, ist ein Bequemlichkeitsfeature.

Naja … es gibt ja auch Makros, die #defined sein müssen … __cplusplus, __FILE__, … aber über die Zielplattform sagen die natürlich nichts.

[eXile]

__GNUC__ == GNU Compiler Collection
__INTEL_COMPILER == Intel Compiler Collection

Man bekommt zu beiden sogar zusätzlich noch die Versionsnummern raus. Eine sehr umfassende Übersicht findet man hier.