Fullscreenwindowing

[Zaphod]

in purebasic gibt es bisher glaube ich keine beispiele. für anderen sprachen hab ich soetwas schon gesehen. ist wahrscheinlich ne menge arbeit, aber sicher nicht wirklich schwer soetwas zu realisieren.

[FGK]

Hallo Hroudtwolf,

guggst du hier - ist zwar ein VB Beispiel aber das werden die
Jungs hier im Board sicher unmsetzen können.
Damit kannst du ein Window mit Buttons und Zeugs auf nem
DXScreen anzeigen. Ev. ist das ja was für dich.

http://www.vb-fun.de/cgi-bin/loadframe. ... 0194.shtml

Gruß

FGK

[Danilo]

Ich suche dringend nach einer guten Möglichkeit(Code) für ein
Windowing im DX-Fullscreen(OpenScreen).
Also quasi Fenster darstellen.

Ich hatte sowas mal getestet, einen ScreenManager für PB-Screens.
War wie gesagt nur ein Test, aber schau es Dir trotzdem mal an -
um vielleicht eine Idee zu bekommen.

Das System beim selber zeichnen ist recht einfach:
Du brauchst Sprites, die Mausfunktionen, und evtl. noch die
Tastatur (für Shortcuts).

In meinem Beispielcode siehst Du folgende Funktionen:

InitScreenManager()
Interne Initialisierung + InitSprite, InitMouse, InitKeyboard

smOpenWindow()
Erstellt ein Fenster. Dazu wird einfach ein Sprite erstellt und
ein Fenster darauf gezeichnet, je nachdem ob mit oder ohne
Titlebar, mit oder ohne Border usw.
Intern wird das erstellte Fenster/Sprite an eine LinkedList
angehangen.

smHideWindow()
Versteckt ein Fenster. Dazu wird in der LinkedList nur ein
Flag gesetzt, so daß dieses Fenster nicht mit dargestellt wird.
Außerdem wird gecheckt welches Fenster nun das aktuelle
ist, und entsprechend neu gezeichnet.

RunScreenManager()
Das ist die Hauptfunktion die alles managt. Diese Funktion
macht folgendes:
1. Internen MouseManager aufrufen
2. Alle Fenster darstellen, d.h. einfach die LinkedList durchgehen und alle Sprites anzeigen
3. MouseCursor-Sprite darstellen

Der MouseManager hat hier die meiste Arbeit:
ExamineMouse() aufrufen.
MouseX() und MouseY() aufrufen und Punkte speichern.
MouseButton(1), MouseButton(2) und MouseWheel() aufrufen
und Zustand speichern.
Danach wird eine Funktion sub_smFindWindowByMouseXY()
aufgerufen, die in der LinkedList (von hinten angefangen, also
vom obersten Fenster aus) das Fenster sucht, welches sich
unter MouseX/Y befindet.
Wenn Du dieses Fenster hast, dann checkst Du weiter was
zu tun ist: Wenn MouseButton(1) gedrückt, schaust Du ob
er neu gedrückt wurde, oder schon vorher gerückt war.
Wenn neu gedrückt: Message an Fenster, wenn innerhalb
der ClientArea - ansonsten Statusflag für TitlebarMove oder
per Border resizen setzen. Dazu das letzte aktivierte Fenster
deaktivieren (d.h. neu zeichnen mit Style Titlebar disabled),
das neue aktivierte Fenster neu zeichnen mit aktiver Titlebar
und in der LinkedList ans Ende setzen (also OnTop bringen).

Dazu kommen noch Checks ob der Cursor sich direkt auf
der ClientArea des Fensters befindet, oder z.B. am Rand
(wenn das Fenster einen Border hat). Je nachdem welche
Situation zutrifft, setzt Du ein entsprechendes Sprite für
den MouseCursor.

Das System ist also im Prinzip recht simpel - ist halt nur
ein WindowManager.
Die Fenster laufen damit. Gadgets kannst Du auch recht
einfach hinzufügen - das sind wieder nur Sprites auf die
Du zeichnest.
Jedes Fenster hat dann noch eine Sub-LinkedList, in der die
Gadgets eingetragen sind. Wenn ein Mausklick in der ClientArea
des Fensters war, dann suchst Du danach einfach welches
Gadget es war, und sendest an dieses eine Message oder
rufst eine Funktion OnClick für das Gadget auf.

Ein Button hätte z.B. den Status 1, wo er normal gezeichnet
wird, und den Status 2, wo er bei gedrückter Maustaste als
gedrückt gezeichnet wird.

Im Prinzip nur Fleißarbeit sowas zu machen - und in ein paar
Tagen kann man da schon ein nettes kleines System zusammenbasteln.

Vielleicht hilft es Dir als kleine Anregung. Viel Spaß!

[MVXA]

Könntest du den Sourcecode der Userlib frei legen? Wäre echt nett. Danke . Ich hab sowas ähnliches schon mal gebraucht. Hab mich nur davor gescheut sowas zu Programmieern weil ich dachte, dass es so aufwändig ist. Aber als ich dein Post gelesen hab wurde mir die Theorie klaerer .

[Danilo]

Könntest du den Sourcecode der Userlib frei legen? Wäre echt nett. Danke .

Der Source darf nur zum lernen und für den persönlichen
Gebrauch verwendet werden: ScreenManager_SRC.zip (95k)

Geschrieben in C ohne Verwendung der C-Runtime/C-Befehle.

Kompilieren:
1.) Path zu LccWin32 in LCCINIT.BAT anpassen.
2.) lcclib.exe nach COMMANDS\ kopieren
3.) LibraryMaker.exe nach COMMANDS\ kopieren
4.) MAKE.BAT ausführen


(C) Copyright/Urherberrechte: Danilo Krahn, 2003 - 2005

Aber als ich dein Post gelesen hab wurde mir die Theorie klaerer .

Ich dachte auch die Erklärung reicht, so daß ihr eine Idee
bekommt und es dann selbst machen könnt.

Vielleicht kann ja niemand meinen Code lesen, so wie Fred + freak.
Naja, einen Versuch ist es ja Wert... *ICH* finde meine Codes
jedenfalls recht übersichtlich...

[MVXA]

Danke. Ich habe keine Probleme den Code zu lesen. Ich muss mich nur etwas ein arbeiten, da ich lange nichts mehr mit C gemacht habe . Ich war dabei etwas ähnliches zu schreiben und wollte nur prüfen ob es auch ein einfacheren Weg gibt .

[edit]
Hab eine kleine/kurze Frage. Was hast du damit versucht zu bezwecken o_O?

Code: Alles auswählen

  if (PB_ExamineKeyboard())
  {
  }

reicht das nicht einfach nur PB_ExamineKeyboard() hin zu schreiben? Ich frag nur...

[Danilo]

Hab eine kleine/kurze Frage. Was hast du damit versucht zu bezwecken o_O?

Code: Alles auswählen

  if (PB_ExamineKeyboard())
  {
  }

reicht das nicht einfach nur PB_ExamineKeyboard() hin zu schreiben? Ich frag nur...

Im momentanen Zustand würde das schon reichen, aber da
sollte ja der KeyboardManager reinkommen, um auch Tasten
und Zeichen an Fenster, Gadget und an den Desktop/GameScreen
zu senden.

Das ganze System ist komplett geplant mit Fenstern, vielen
Gadgets, Menus, Toolbars, Tooltips usw.
Das ganze mit Skinning, d.h. die Zeichenroutinen für Rahmen,
Titlebars usw. sollen zur Laufzeit ausgetauscht werden können,
so daß man also auch z.B. einen MacOS-, Amiga-, GNOME-
oder eigenen Style wählen kann.
Das gleiche für die SystemFarben, geregelt über den ColorManager.
Damit kann man die Farben mit einem Befehl zur Laufzeit
ändern. Entweder komplett, oder für einzelne Fenster und
Gadgets.

Geeignet wäre es für Fullscreen-Anwendungen, genauso wie
für Spiele und Spiele-Menus.
Beispiel Spiele-Menu: 1 Fenster, 5 ImageButtonGadgets drauf
und ein Hintergrundbild/Animation dazu, fertig.
Spiel: Auf der rechten Seite ein nicht verschiebbares Fenster
ohne Rahmen und Titlebar, darauf Gadgets zur Spielsteuerung.
Links davon ist dann der GameScreen.

Auch hatte ich größere GUIs wie bei diversen "MusicMaker"
usw. dabei im Kopf, wie auch Fullscreen-Grafikbearbeitungsprogramme usw.

Aufgehört habe ich damals weil die Linux-Version bei 2D-Drawing
(was ja hier für alles benutzt wird) einfach noch nicht auf dem
Windows-Stand war und es scheinbar noch einen Bug mit
Sprites gibt, für den sich aber absolut niemand interessiert
(habe es mehrmals gemeldet - absolut keine Reaktion).
Aktuelle Linux-Version habe ich noch nicht gecheckt (habe noch 3.91 drauf).
Das System basiert ja nur auf PB-Befehlen, so daß es komplett
platformunabhängig sein sollte, so wie auch AnimSprite.
Wenn PB/Linux da nicht 100% richtig funktioniert und einige
Befehle anders arbeiten (z.B. DrawText), dann ist das bissl
blöd, nervt ungemein, und macht keinen richtigen Sinn.