[archimedes] Re: [archimedes] Re: [archimedes]RISC OS & C - WIMP-Programmierung - Fragen zum nachträglichen Ändern von Symbolen

  • From: "Anton Reiser" <anton-reiser@xxxxxxxxxxx>
  • To: archimedes@xxxxxxxxxxxxx
  • Date: Mon, 18 Jul 2016 10:17:20 +0200

In message <ff4f30a155.Alex@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
          Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx> 
wrote:

In message <728301415.767465.78429629-7c02-4569-90f9-343476f98d1d.open
-xchange@xxxxxxxxxxxxxxxxxxxxxx>
          Steffen Huber <steffen@xxxxxxxxxxxx> wrote:

ich versuche mich mal an einer Antwort, bin aber schätzungsweise 15
Jahre aus der Übung...

Macht doch nix!

[Teil geschnippt]

Wenn ich nicht die Adressen abändern kann oder möchte, auf welche die
originalen Zeiger des Symbols zeigen, so kann ich noch immer deren
Inhalte abändern oder überschreiben (also das, worauf die originalen
Zeiger zeigen).

So ist es ja auch gedacht, mit den "indirected data"-Geschichten.
Alles, was nicht "indirected" ist, kann inhaltlich nicht geändert
werden, sondern man muss ein neues Objekt generieren.

Auf was dann der Zeiger umgebogen werden muss? Das war meine Frage. Wie
ich festgestellt habe, geht das nachträgliche Ändern dieser Zeiger im
Programmcode erstmals mittels

 window->icons[0].data.indirected_text.text = "Hahaha!\0";

allerdings funktioniert das hier bisher nur vor dem Funktionsaufruf
wimp_create_window (...);

Danach funzt das leider nicht mehr. Heißt das jetzt generell, dass man
das alte Objekt im Speicher überschreiben muss und man auch die Zeiger
in .data... nicht mehr nachträglich ändern kann?

ja, genau das

In C geht's,

nein, ausser Du beweißt das Gegenteil.

aber lässt es RISC OS auch zu (dass die Zeiger nachträglich geändert
werden können, denn die Zeiger selbst sind ja nicht [indirekt]).

Wie finde ich jetzt aber die Größe der reservierten oder benutzten
Speicher heraus?

Du liest die Bufferlänge aus Wimp_GetIconState raus - steht genau 4
Bytes nach der Adresse der Indirektion :-)

https://www.riscosopen.org/wiki/documentation/show/Icon%20Data

Äh - danke für den Hinweis erstmal. Was ist aber, wenn die Größe nicht
richtig gesetzt worden ist? Wenn ich dort von Hand etwas eintrage, kann
ich auch null eintragen. RISC OS interessiert das erstmal gar nicht, was
dort steht - außer bei einem editierbaren Textfeld. Hm.

Prinzipiell sollte es kein Unterschied sein, ob Du die 
Fensterdefinition 'zu Fuß' erstellst oder aus einem Template einliest.

Ein Unterschied besteht, wie Du ggf. auf die Definition zugreifen 
kannst, um sie programmatisch vor CreateWindow zu manipulieren. Aber 
das hat Du ja schon selbst festgestellt.

Bei Wimp_CreateWindow wird die Definition vom Wimp kopiert (d.h. Du 
kannst die Definition danach wegwerfen oder recyclen) und Du hast 
danach nur noch begrenzte Einflußmöglichkeiten.

Die maximale Länge des indirekten Textes kannst Du nachträglich (d.h. 
nach CreateWindow) nicht mehr ändern. (außer Fenster löschen und 
verändert neu erstellen)

Der WindowManager nimmt den Pointer und zeichnet den Text bis zum 
Stringende, interessiert sich dabei nicht für die Stringlänge. 
Deswegen kann der String auch länger sein, wie als Buffergröße 
angegeben.

Verwendest Du Templates, sind die Stringlänge und die Buffergröße 
identisch. Die Buffergröße bestimmt in diesem Fall auch die Größe des 
reservierten Speichers im Datenbereich des Templates!

Wie Du oben schon festgestellt hast, kannst Du diesen dort 
reservierten Speicher auch ignorieren, und vor CreateWindow den 
Pointer umbiegen.

Aktualisieren des Icons, nachdem Du den indirekt adressierten Text 
verändert hast:
Entweder mit Wimp_SetIconState (ohne Flags zu änderen) oder
mit Wimp_GetIconState die Koordinaten des Icons holen und für 
Wimp_ForceRedraw verwenden.

Noch eine Ergänzung zu Deinem Code:
Bei Programmende wird zwar der mit malloc() allozierte Speicher wieder 
freigegeben, es ist aber eine gute Tradition, vorher aufzuräumen. Vor 
allem wenn es ein Beispielcode werden soll ;-)

free(window) kannst Du gleich nach wimp_create_window() machen,
free(data) genaugenommen nach Wimp_DeleteWindow()

Toni



Other related posts:

  • » [archimedes] Re: [archimedes] Re: [archimedes]RISC OS & C - WIMP-Programmierung - Fragen zum nachträglichen Ändern von Symbolen - Anton Reiser