[archimedes] Re: E-Mails von Uwe Kall bzgl. RISC OS & C (C++)
- From: Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx>
- To: Carlos Michael Santillan <carlos2007@xxxxxxxxxx>
- Date: Sun, 21 Aug 2016 14:38:21 +0200
In message <55c505ac55.cms@xxxxxxxxxxxxxxxxxxxxxx> you wrote:
Uwe hat mir einige E-Mails bezüglich der WIMP-Programmierung unter RISC
OS und C (Artikel-Serie) auf Arcsite zukommen lassen, welche näher auf
C++ eingehen. Hast du die ebenfalls bekommen oder möchtest du die sehen?
Ich lege die auf jeden Fall bei mir hier ab und nehme sie auch zur
Kenntnis. Aber was machen wir jetzt damit?
ich habe die Mails auch bekommen. Bei der ersten mit stlib.h/stdio.h hat
Uwe recht und zustäzlich muss das eigentlich mit <stdio.h> eingebunden
werden. Die Standard-Bibliotheken (ANSI C) stdio, ctype, sting, math,
stdlib, assert, stdarg, setjmp, signal, time, limits und float
(mal eben das Buch aus dem Schrank geholt) werden mit #include <***.h>
eingebunden. Die anderen werden mit #include "NAME.h" eingebunden. Ich
habe das eben in
https://www.arcsite.de/magazin/praxis/ro-programmierung-1/ geändert.
Die anderen beziehen sich auf C++ bzw. der Sache xyz.c und xyz im
Verzeichnis c usw. Also den Fehler von Acorn als Trenner für
Verzeichnisse den Punkt zu nehmen.
Ich denke nicht, dass das ein Fehler ist, nur weil es anders
funktioniert. Denn sonst wäre es ja auch ein Fehler, dass bei einem
Doppelklick mit der Maustaste auf ein Verzeichnis ein neues Fenster
erscheint, statt den Inhalt im alten Fenster darzustellen (wie Windows
das macht). Oder dass man bei RISC OS grundsätzlich eine Kopie von der
Datei verschiebt, bei Windows aber das Original. Ich denke, das ist eher
Ansichtssache.
Sicher tritt da RISC OS aus der Rolle. Bei gewissen Portierungen macht
es dann halt Probleme. Weil nicht ganz klar ist, wie man es machen oder
mit dem althergebrachten umgehen soll. Letzten Endes finde ich es aber
gut, dass RISC OS sich abhebt und eigene Wege geht.
Du bist Uwes Anliegen also schon nachgekommen, soweit ich das verstanden
habe.
Das mit dem achten Kapitel - Vorlagen bzw. Templates hat sich aus meiner
Sicht erledigt, wie ich schon einmal geschrieben hatte. Ich weiß nicht,
ob es bei Dir angekommen ist.
Das heißt, in diesem achten Teil werden nur die drei Funktionen
wimp_open_template(...)
wimp_load_template(...)
wimp_close_template(...)
behandelt. Danach ist Schluss. Es gibt keine Ergänzungen mehr in Form
der beiden SWIs Wimp_GetIconState und Wimp_SetIconState.
Denn:
Ich ging damals davon aus, dass es die beiden SWIs Wimp_GetIconState und
Wimp_SetIconState _nur_ wegen den Vorlagen / Templates gibt.
Allerdings ist dem nicht so.
Problem war: Im Buch Wimp-Programmierung unter RISC OS steht auf Seite
169 unter Kapitel 9 - Templates: ... Da der Task selber nicht die exakte
Adresse jedes einzelnen Symbols kennt (wie es der Fall wäre, wenn die
Symbole innerhalb des Programms angelegt werden), müssen Sie
normalerweise Wimp_GetIconState (wie in Kapitel 5 beschrieben) benutzen,
um die Adresse herauszufinden, wenn das notwendig ist.
Dem ist so leider nicht richtig. Oder irreführend geschrieben.
In C kann ich mittels *windows einen Zeiger auf einen Datenblock legen
und mittels Wimp_LoadTemplate den Datenblock in den Speicher laden (und
*windows darauf zeigen lassen):
wimp_window *window;
context = wimp_load_template (window, data, (char const *) data + data_used,
wimp_NO_FONTS, name,0, NULL, NULL);
Punkt.
In C kann ich aber nach wie vor die Struktur von wimp_window (Datentyp)
verwenden. Also z. B. (*windows).icons[0].flags.wimp_ICON_SELECTED =
oder besser windows->icons[0].flags.wimp_ICON_SELECTED = usw. und damit
nachträglich die Symbolzeichen (icon flags) des in den Speicher
geladenen Datenblocks abändern. Das funktioniert, weil der Compiler mit
Hilfe der Struktur, die in wimp_window hinterlegt wurde, die richtige
Adresse berechnen kann. Die Struktur in wimp_window muss dabei natürlich
mit der Struktur des geladenen Datenblocks übereinstimmen.
Wimp_GetIconState und Wimp_SetIconState sind für etwas ganz Anderes gut,
was dank der vielen Hilfestellungen in archimedes@xxxxxxxxxxxxx
herausgekommen ist.
Dazu muss man wissen:
Der Programmierer verwendet einen Datenblock, mit dem er Fenster, Menüs
oder Symbole beschreibt. Mit Hilfe der SWIs Wimp_CreateWindow,
Wimp_CreateIcon und Wimp_CreateMenu werden diese "Objekte" dann von RISC
OS intern angelegt. Dabei werden jedoch nur Teile oder alles von den
schon erwähnten Datenblöcken _kopiert_. Die originalen oder
ursprünglichen Datenblöcke werden von RISC OS nicht angerührt. RISC OS
verwaltet seine eigenen Datenblöcke. Nun ist es aber so, dass man an
diese intern verwalteten Datenblöcke so gar nicht hinkommt. Man weiß ja
deren Adresse nicht. Und RISC OS rückt die so einfach auch nicht heraus.
Was man jetzt aber machen kann: Man kann sich von RISC OS wieder Kopien
von den intern angelegten Datenblöcken ausgeben lassen. Das macht man z.
B. mit Wimp_GetIconState.
Das Abändern der tatsächlich von RISC OS angelegten und intern
verwalteten Datenblöcken ist nur in gewissen Umfang möglich - z. B. mit
dem SWI Wimp_SetIconState.
Mit den Template-Dateien hat das jetzt aber nichts zu tun. Denn sobald
man Wimp_CreateWindow ausführt, ist es irrelevant, ob man den Datenblock
zuvor per Datei extern reingeladen oder intern direkt im Programm von
Hand angelegt hat. RISC OS legt in beiden Fällen interne Kopien von den
ursprünglichen Datenblöcken an.
Was mir ebenfalls aufgefallen ist: Sobald ein geeignetes Ereignis für
ein Programm auftritt, springt RISC OS das Programm an, d. h. gibt die
Kontrolle über das System an dieses eine Programm ab. Gleichzeitig
liefert es eine Ereignisnummer - sowie einen Datenblock wimp_block
block.
Dieser Datenblock wimp_block block ist in C eine Union. Das heißt der
Datenblock wimp_block block kann verschiedene Strukturen beinhalten oder
aufweisen, je nachdem, was für ein Ereignis aufgetreten ist.
Nun ist mir aufgefallen, dass die verschiebenen Strukturen von
wimp_block block teilweise jenen von wimp_window windows usw.
entsprechen. D. h. wenn ein Ereignis auftritt, dann gibt RISC OS (oder
die Wimp) von den intern verwalteten Datenblöcken über wimp_block block
wieder eine Kopie davon heraus. Es wird immer mit Kopien gearbeitet. So
funktioniert das also.
Nun ist es aber so, dass wir im Teil fünf "Wimp_Poll" der
Programmier-Serie den Datenblock wimp_block block leider gar nicht näher
beschrieben, erklärt oder erläutert haben. Sollen wir das noch
nachholen?
Ich weiß im Moment leider nicht recht, wo und wie ich weitergehen soll.
A.
--
http://home.chiemgau-net.de/ausserstorfer/
Other related posts:
