Testbild zum Einstellen des Monitors

[ari.tao]

Leider keine Verbesserung.
Da fehlen wohl ein paar grundsätzliche Dinge ...

[Count]

Aber welche? Mit Steem ist alles ok, mit Aranym auch, auf meinem Mega STE ebenso. Der Quellcode ist ja dabei. Also, wenn jemand das Problem findet, bitte melden!

[Count]

Ok, ich habe das Ganze als Projekt bei Github angelegt. Dann kann jeder mitarbeiten. 
https://github.com/rosenrost/TESTBILD

[ari.tao]

... Also, wenn jemand das Problem findet ...

Auf den ersten oberflächlichen Blick drei Dinge:
1) Die Setzung & Rücksetzung der beiden AES-Semaphoren scheint zu fehlen.
2) Vor Prg.-Ende muß die Maus wiedereingeschaltet werden.
3) Vor Prg.-Ende muß der Bildschirm restauriert werden.
Weiter kann ich leider nicht helfen (wg. C-Allergie  )

[Count]

Das müsste sich jemand ansehen, der sich mit MagiC auskennt.

[ari.tao]

Das müsste sich jemand ansehen, der sich mit MagiC auskennt.

? ? ? Hat doch mit MAGX _gar_nix_ zu tun! Wenn das Prg. sauber programmiert ist, dann sollte es unter jedem BS laufen (auch unter Geneva, MultiTOS, ...).
Hab´s gerade noch mal auf dem TT unter NAES2 laufen lassen - da kommt zwar der MausCursor zurück, aber die übrigen Macken sind ungefähr die gleichen, bloß, daß das Prg. gar nicht durch Tastendruck beendet wird, sondern im Speicher verbleibt...
Wenn Du willst, daß es als SingleTask überall läuft, mußt Du halt die entsprechenden Blockaden vornehmen und bei Prg.Ende aufräumen. Ich habe eine Reihe solcher Prge. geschrieben, im Anhang ein Beispiel.

[ari.tao]

Eine andere Möglichkeit - aber viel aufwändiger! - wäre, ein ´richtiges´ GEM-Prg. daraus zu machen, das dann auch mit MT perfekt zusammenspielt. Dazu müßte das TestBild in einem Fenster dargestellt werden, mit den nötigen Redraw-Routinen versehen, etc. Als Vorbild bzw. zum Abschreiben müßtest Du an die Quellen eines Mal-Programms kommen...

[Count]

Das müsste sich jemand ansehen, der sich mit MagiC auskennt.

? ? ? Hat doch mit MAGX _gar_nix_ zu tun! Wenn das Prg. sauber programmiert ist, dann sollte es unter jedem BS laufen (auch unter Geneva, MultiTOS, ...).
Hab´s gerade noch mal auf dem TT unter NAES2 laufen lassen - da kommt zwar der MausCursor zurück, aber die übrigen Macken sind ungefähr die gleichen, bloß, daß das Prg. gar nicht durch Tastendruck beendet wird, sondern im Speicher verbleibt...
Wenn Du willst, daß es als SingleTask überall läuft, mußt Du halt die entsprechenden Blockaden vornehmen und bei Prg.Ende aufräumen. Ich habe eine Reihe solcher Prge. geschrieben, im Anhang ein Beispiel.

Wo finde ich denn die entsprechenden Informationen? Ich habe leider null Erfahrung mit Multitasking-Umgebungen auf dem Atari. 

[ari.tao]

Wo finde ich denn die entsprechenden Informationen?

Jede sauber & vollständig als GEM-Prg. ausgeführte Applikation läuft auch unter MT. Willst Du den Aufwand (und die Prg.-Größe) klein halten, wie oben in #25 skizziert, dann mußt Du es als sog. ´modalen Dialog´ einrichten. Dann läuft es auch unter MT - aber nur als SingleTask. Echte MultiTasks dürfen nicht modal sein. Typisch modal sind zB. FormAlerts (weshalb echte MT-Prge. diese vermeiden).
Literatur:
Geiß & Geiß: "Vom Anfänger zum GEM-Profi" Hüthig-Verlag Heidelberg 1990
Weiß nicht, ob das digital verfügbar ist.
Direkt zum Thema MT fällt mir nix ein, such mal in den Gazetten.

Hmm, habe gerade nachgeschaut: Bei den zwei Geißen steht der Begriff ´modal´ noch gar nicht drin (1990 war für Atari noch keine MT-Zeit). Das macht aber nix... Kurze Erklärung: Modal heißt ein Prg.-Stück, das eine eigene (eingeschränkte) Event-Schleife hat. Im FormAlert ist die implizit, also unsichtbar enthalten - deshalb kommen manche der skizzierten Billig-Prge. ohne weitere Event-Verwaltung aus. Wichtig zur Einrichtung der Modalität sind die beiden AES-Semaphoren. Ach, schon wieder ein Begriff, der nicht im Buch vorkommt: Gemeint sind WindUpdate (zur Regelung der Redraws) und MouseCtrl (zur Reservierung der Maus).
Wie schon angedeutet: Das beste wäre, wenn Du ein C-Skeleton für Deine Zwecke findest. Damit kann ich leider nicht dienen, bin ´nur´ M2-ler.

[Count]

Da waren doch schon ein paar gute Hinweise dabei.

Ich habe jetzt wind_update()-Aufrufe eingebaut, um andere Prozesse zu blockieren, und form_dial()-Aufrufe zum Wiederherstellen des Bildschirms (wie immer bei github). Das ganze sieht in meiner Aranym-Umgebung mit XaAES auch schon ganz gut aus. Allerdings fehlt noch irgendetwas, um nach Programmende die Menüleiste wiederherzustellen.

[ari.tao]

Ich habe jetzt wind_update()-Aufrufe eingebaut, um andere Prozesse zu blockieren, und form_dial()-Aufrufe zum Wiederherstellen des Bildschirms ...

Genau. Auch die Maus-Semaphore solltest Du einbauen. Eigentlich bräuchte auch die Tastatur eine Semaphore - aber die gibt´s nicht, ist wohl schlicht in GEM vergessen worden (was indes selten auffällt); muß man bei Bedarf ´von Hand´ stricken.

Allerdings fehlt noch irgendetwas, um nach Programmende die Menüleiste wiederherzustellen.

Ja, nachdem man die anderen Dinge brav erledigt hat, dann kommt man schließlich an diesen Punkt. Es handelt sich (ich stelle das mal in aller Bescheidenheit fest, auch wenn ich jetzt womöglich wieder mal den Zorn der Götter errege) imho um eine Macke - die XaAES indes mit anderen Zelebritäten wie zB. MAGX gemein hat:
Es ist nämlich so, daß afaik nirgends in den GEM-Unterlagen festgelegt ist, daß ein ´richtiges´ GEM-Prg. eine Menue-Leiste haben muß, aber MAGX & Co.* gehen genau davon aus! Weil dem so ist und es wenig Sinn hat, an dieser Macke herumzukritteln (man möchte ja, daß eigene Prge. überall laufen), bleibt nur ein ´Workaround´:
Grundsätzlich ist der auf zweierlei Art möglich: Entweder muß man die Menue-Zone vor Benutzung retten und bei Prg.-Ende selbst restaurieren, oder aber, imho billiger: Man installiert eine ´triviale´ MenueLeiste (ohne sie je zu benutzen), dann erledigt das AES die Restaurierung selbst.

* In NAES besteht das Problem nur aus einer einzigen PixelZeile (weil iGgs. zu den Konkurrenten fast der gesamte Bildschirm zur Verfügung steht), die auch noch schwarz ist und deshalb kaum auffällt. Warum macht XaAES das nicht genauso?! Ach, das ist ´nicht mein Bier´. Warum die Eitelkeiten reizen...

[Count]

Auch die Maus-Semaphore solltest Du einbauen.

Die Maus-Semaphore ist mit drin (BEG/END_UPDATE und BEG/END_MCTRL).

Es handelt sich (ich stelle das mal in aller Bescheidenheit fest, auch wenn ich jetzt womöglich wieder mal den Zorn der Götter errege) imho um eine Macke - die XaAES indes mit anderen Zelebritäten wie zB. MAGX gemein hat:
Es ist nämlich so, daß afaik nirgends in den GEM-Unterlagen festgelegt ist, daß ein ´richtiges´ GEM-Prg. eine Menue-Leiste haben muß, aber MAGX & Co.* gehen genau davon aus! Weil dem so ist und es wenig Sinn hat, an dieser Macke herumzukritteln (man möchte ja, daß eigene Prge. überall laufen), bleibt nur ein ´Workaround´:

Dass das eine Macke ist, habe ich mir schon gedacht. Der Workaround mit dem Dummy-Menü funktioniert aber prima.

[Count]

Und vielen Dank für die Tipps. Wieder ein bisschen dazu gelernt.