Fullscreen

Ich habe einmal die Vollbild-Funktion aus dem GeoPoint in eine einfache Beispiel-App extrahiert und hier angehängt (Source und Geode).

Gerne würde ich das ein wenig diskutieren.

Erster Punkt, der mir hierzu einfällt ist, dass beim Starten die MSG_META_EXPOSED an den Prozess gesendet wird und ich bei der Funktion WinOpen() den Prozess nicht angeben kann. Somit gibt es im Beispiel zwei mal eine MSG_META_EXPOSED...

Was wären da für Möglichkeiten, alles über einen WindowsHandle / GStateHandle abzuwickeln?

Das habe ich auch genau versucht. Bekam das aber nicht kompiliert.

Ok, werde das am Abend dann mal so versuchen

Beim exposureRecipient scheint es zu funktionieren. Setze ich es beim inputRecipient, dann kann ich nicht einmal mehr die Anwendung per F3 schliessen. Besten Dank trotzdem soweit!

Mal schauen, ob sich das irgendwie in den GeoLadder integrieren lässt.

Und vielleicht kann man in der Zukunft das GenPrimary entsprechend erweitern, so dass eine beliebige Anwendung im Vollbild-Modus betrieben werden kann. Wäre doch etwas, was Gonzo auch gebrauchen könnte...

Quote from Rainer

Wenn du im View

Code

  GVI_content = process;

spezifizierst bekommt natürlich der Process das META_EXPOSED. Das hast du ja so festgelegt. Alternativ legst du ein GenContent oder ein VisConten fest, je nachdem was du willst.

Da kann ich Dir natürlich nur zustimmen. In meinem Code befinden sich diverse Sachen, welche ich so von Anderen übernommen oder vor langer Zeit einmal nachgelesen und dann wieder vergessen habe.

Quote from frehwagen

Klar dann bekommt Du alle Input-Events in den process, wenn das Window den Focus hat. Hier kommt es jetzt natürlich drauf an, was Du machen willst.

Wie wäre es mit :

ATTR_GEN_DISPLAY_MAXIMIZED_STATE

ATTR_GEN_WINDOW_CUSTOM_WINDOW

HINT_WINDOW_NO_CONSTRAINTS

VG, Falk \\ blueway.Softworks

Display More

Die Idee wäre es, die GenView zwischen Fenster- und Vollbildmodus wechseln zu lassen. Das war mal ein geäusserter Wunsch, der an mich herangetragen wurde... Wenn das direkt mit dem Window vom GenPrimary oder das vom GenView ginge, wäre es am einfachsten zu implementieren.

Quote from Rainer

In R-BASIC habe ich ein Gen- oder VisContent. Dort überschreibe ich MSG_META_CONTENT_VIEW_WIN_OPENED

Code

@method BasicBitmapAndContentClass, MSG_META_CONTENT_VIEW_WIN_OPENED {
    pself->BOI_viewGState = GrCreateState(viewWindow);

Das GState merke ich mir und da kann ich jederzeit hineinschreiben. Das landet dann direkt auf dem Schirm.

Vernichten tue ich das dann in MSG_META_CONTENT_VIEW_WIN_CLOSED

Code

    if ( pself->BOI_viewGState ) {
		GrDestroyState(pself->BOI_viewGState);
		pself->BOI_viewGState = 0;
		}

Bei dir wäre dass dann statt pself->.. eine globale Variable

Rainer

Genau das mache ich imGeoLadder auch. Mit einer VisContent. War sogar, wenn ich mich recht erinnere, ein Tip von Dir

Den GStateHandle erhält man ja anhand des WindowHandle. Wenn ich für das Vollbild die Funktion WinOpen() verwende, dann sollte ich doch ein neues WindowHandle bekommen? Und somit erwarte ich, dass der davon abgeleitete GStateHandle sich ändert. Jetzt kommt aber das Spannende. I meinem Testprogramm bleibt der GStateHandle immer gleich, egal ob MSG_META_EXPOSED beim Starten im Fenster oder durch OpenWin im Vollbild aufgerufen wurde... Wäre ja zu schön, wenn das wirklich so funktionieren würde.

Habe mal die aktuelle Version des Test-Programmes angehängt.

VideoTest-20240807-2.zip

Quote from frehwagen

Versuch es mal mit ConstructOptr(GeodeGetProcessHandle(), NullChunk).

Falk \\ blueway.Softworks

So funktioniert es, besten Dank!

Bin am weiter experimentieren, aber noch nicht am Ziel.

Ich kann die VisContent um ein FullScreen window erweitern. Das funktioniert soweit relativ gut. Vielleicht kann dies ein Experte mal anschauen und ein Feedback geben.

FullTest-20240808-VisContent-2.zip

Da ich schlussendlich verschiedene VisContent-Instanzen brauche, welche ich einfach bei Bedarf dem GenView mittels MSG_GEN_VIEW_SET_CONTENT einpflanze, müsste die FullScreen-Funktionalität höher in das GenView rücken. Da habe ich aber kein WindowHandle gefunden, obwohl es einen haben müsste.

Den Weg über ATTRS und HINTS habe ich auch mal versucht, aber dann fürs Erste aufgegeben. Müsste hierfür wohl die gesamte SDK-Doku lesen...

Quote from Rainer

Hallo Andreas,

hier drei Anmerkungen zum Code

1. local.mk: Die Empfehlungen zu XCCOMFLAGS stammen von mir, so von 1995 und sind veraltet. Insbesondere XCCOMFLAGS += -2 würde ich heute nicht mehr machen.

2. local.mk: Mit Watcom muss der Linkflagstext in Anführungszeichen
LINKFLAGS += -N "Dat ist meins! Klaro?"
Deswegen compilierte das Programm bei mir zuerst nicht.

3. Es ist immer relativ schwer, bei einem vollständig unkommentierten Code zu sehen, worauf du hinauswillst. Ich sehe nichts, was ich als problematisch ansehen würde. Für ein Spiel wie Ladder würde ich aber direkt die VIS_DRAW vom VisContent nehmen, nicht den Umweg über ein extra Vis-Objekt. Das Objekt "FullText" und die dazugehörige Klasse ist im Beispielcode nicht zwingend erforderlich.

Rainer

Display More

Hallo Rainer

Zu 1.:

Dann soll ich das -2 einfach weglassen?

Zu 2.:

Danke für den Hinweis. Schön zu wissen, dass es im aktuellen SDK wieder mit Anführungszeichen und ohne die \20 für Leerschläge geht

Zu 3.:

Ja, Du hast bezüglich den Kommentaren absolut recht! Mir ging es generell darum, ob die Art und Weise bezüglich dem Wechsel zwischen Fenstermodus und Vollbildmodus grundlegende Probleme bereiten könnte. Das Ziel werde ich im nächsten Eintrag versuchen zu erläutern.

Andreas

Auf dem Weg zum Vollbildmodus habe ich einige weitere Experimente gemacht. Dazu vielleicht erst einmal die Objekt-Hirarchie und der Grundlegende Plan.

Die Haupt-Objekte, ganz normaler Standardaufbau:

GenApplication -> GenPrimary -> GenView

Dann habe ich mehrere VisContent-Objekte, welche wiederum verschiedene Vis-Objekte als Kinder haben:

VisContent1 -> Vis1, Vis2, Vis3

VisContent2 -> Vis4, Vis5

VisContent3 -> Vis6, Vis7

und so weiter.

Das entsprechende VisContent-Objekt setze ich dann bei Bedarf mit der Nachricht MSG_GEN_VIEW_SET_CONTENT als Content von der GenView.

Die VisContent-Objekte wiederum verwalten ein globales GStateHandle auf das GState, welches mit dem WindowHandle der Nachricht MSG_META_CONTENT_VIEW_WIN_OPENED erzeugt wird. In MSG_META_CONTENT_VIEW_WIN_CLOSED und MSG_META_CONTENT_VIEW_CLOSING wird dieses GState wieder zerstört. Soweit meiner Meinung nach Standard und das funktioniert auch sehr gut.

Wenn wir nun in den Vollbild-Modus wechseln wollen, wird es etwas trickier:

(a) Eine einfache, grundlegende Möglichkeit vom System aus habe ich nicht gefunden. Der Weg über Attribute und Hints scheint ziemlich steinig und ich habe keine Ahnung, ob dieser auch zum Erfolg führen kann.

(b) GeoPoint erzeugt ein eigenes Window und hat da dann die volle Kontrolle. Der Anwendungsfall ist da etwas anders. Die im Vollbild angezeigten Objekte werden meiner Meinung nach nicht 1:1 wie im Fenstermodus gezeichnet.

(c) Die Vollbild-Funktionalität auf der Ebene von VisContent-Objekten habe ich schon ausprobiert. Aber beim Wechsel des aktiven VisContent-Objektes wird das Window jeweils neu erzeugt. Ich kann da einfach das GVI_window auf das erzeugte Vollbild-WindowHandle setzten und beim Beenden des Vollbildes dieses wiederum mit der Nachricht MSG_GEN_VIEW_GET_WINDOW zurück auf dasjenige der GenView setzen.

(d) Aktuell bin ich am Versuch, die Vollbild-Funktionaliät auf der Ebene der GenView zu implementieren. Dies hat eine ganze Reihe von neuen Herausforderung gebracht. Die Grösste ist, dass die GenView selber keine Instanz-Variable für das WindowHandle zu besitzen scheint. Auch kann ich zwar in der WinOpen() dann den Empfänger für die MSG_META_EXPOSED auf die GenView-Instanz GVI_content setzen. Aber sobald ich dem GenView ein neues VisContent setze, dann bekomme ich den Zugriff auf das Window, WindowHandle und GState nicht mehr korrekt hin. Es wird auf jeden Fall ziemlich wild, denn das VisContent muss in den Nachrichten MSG_META_CONTENT_VIEW_* zuerst überprüfen, ob sein GenView ein WindowHandle für den Vollbild-Modus hat.

Wenn man an etwas zu lange herum-doktert, dann kann es ja gut sein, dass man auf dem Holzweg ist.

Meine nächsten Schritte sind in etwa folgende:

1) Herausfinden, woher das WindowHandle stammt, welches man über die Nachricht MSG_GEN_VIEW_GET_WINDOW bekommt. Wenn da jemand eine Idee hat, darf er sich gerne melden

2) Anstatt ein neues Window zu erzeugen, sollte man auch einfach das Bestehende mit WinResize() vergrössern können. Dazu müsste man aber auch wissen, wo dieses WindowHandle her kommt und wo es genau gespeichert ist. Denn in dem Fall müsste man wohl die Koordinaten und Flags des alten Window sichern und beim Zurückkehren in den Fenstermodus wiederherstellen.