CheckBox-Problem unter OS4 - amiga-news.de Forum

amiga-news.de Forum > Programmierung > CheckBox-Problem unter OS4

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

06.11.2005, 22:26 Uhr

malte
Posts: 28
Nutzer

Hallo allerseits,

irgendwie komme ich nicht weiter, ich will bei einer Checkbox nachträglich
den Status ändern:

IIntuition->SetGadgetAttrs(gadgets[GID_POPUP], windows[WID_PREFS],NULL, GA_Selected, CX_popup, TAG_DONE);

(GA_Selected ist gleichbedeutend mit CHECKBOX_Checked)
laut AutoDocs sollte das auch möglich sein, es funktioniert aber nicht,
Wwenn ich GA_Selected direkt beim anlegen mit angeben wird zumindest da der Hacken gesetzt.
Ob ich nun CX_popup oder TRUE oder 1 angebe ist egal.

Hat jemand eine Idee?

Grüße,

Malte

[ Dieser Beitrag wurde von malte am 06.11.2005 um 22:34 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

06.11.2005, 22:49 Uhr

thomas
Posts: 7719
Nutzer

Schick noch ein RefreshGList hinterher, dann funktionierts.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

06.11.2005, 23:51 Uhr

malte
Posts: 28
Nutzer

@thomas:

Vielen Dank - Das war die Lösung.

Ich finde es etwas merkwürdig, das einige Gadgtes das alleine hinbekommen und andere nicht, was solls, jetzt weis ichs....

Vielen Dank,

Malte

[ - Antworten - Zitieren - Direktlink - ]

07.11.2005, 10:47 Uhr

thomas
Posts: 7719
Nutzer

BOOPSI-Klassen sind Programme. Je nachdem, wer sie geschrieben hat, macht das so oder so.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

08.11.2005, 00:20 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von malte:
Ich finde es etwas merkwürdig, das einige Gadgtes das alleine hinbekommen und andere nicht, was solls, jetzt weis ichs....

Ich weiß ja nicht, wie das unter AmigaOS 4 ist, aber unter älteren Versionen liefert die Funktion ein bool zurück, das Dir mitteilt, ob Du einen Refresh benötigst.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

08.11.2005, 16:41 Uhr

Gazelle
Posts: 151
Nutzer

@Holger:

Oder man verwendet gleich RefreshSetGadgetAttrs() (V50)

FUNCTION
Same as SetGadgetAttrs() but refreshes the object when the set
method returns a non-zero value.

[ - Antworten - Zitieren - Direktlink - ]

08.11.2005, 17:00 Uhr

malte
Posts: 28
Nutzer

Zitat:
Oder man verwendet gleich RefreshSetGadgetAttrs() (V50)

FUNCTION
Same as SetGadgetAttrs() but refreshes the object when the set
method returns a non-zero value.

Man sollte die AutoDocs mal richtig lesen - dann wäre mir die Funktion wohl auch aufgefallen.
Aber wäre es nicht sinniger gewesen allen Gadget-Klassen bei der Portierung/Neuentwicklung ein einheitliches Verhalten zu geben (auch wenn unterschiedliche Personen mitentwickelt haben)? An dieser Stelle wäre es leicht möglich gewesen Kosten (Speicher, Rechenzeit, Programmieraufwand, usw...) zu sparen und irgendwie erwarte ich bei einer Gruppe von Objekten, dass sie sich bei grundsätzlich Dingen gleich verhalten.

Gruß,

Malte

[ - Antworten - Zitieren - Direktlink - ]

09.11.2005, 00:36 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von malte:
Aber wäre es nicht sinniger gewesen allen Gadget-Klassen bei der Portierung/Neuentwicklung ein einheitliches Verhalten zu geben (auch wenn unterschiedliche Personen mitentwickelt haben)?

Der Sinn dieser Verhaltensweise ist vermutlich, wie auch früher, daß ein Refresh genau dann nicht automatisch durchgeführt wird, wenn er verhältnismäßig aufwendig ist.

Das eröffnet dem Programmierer die Möglichkeit, mehrere Gadgets zu aktualisieren und dann einen sichtbaren Refresh durchzuführen.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

09.11.2005, 01:39 Uhr

geit
Posts: 332
[Ex-Mitglied]

Zitat:
Original von Holger:

Zitat:
Original von malte:
Aber wäre es nicht sinniger gewesen allen Gadget-Klassen bei der Portierung/Neuentwicklung ein einheitliches Verhalten zu geben (auch wenn unterschiedliche Personen mitentwickelt haben)?

Der Sinn dieser Verhaltensweise ist vermutlich, wie auch früher, daß ein Refresh genau dann nicht automatisch durchgeführt wird, wenn er verhältnismäßig aufwendig ist.

Das eröffnet dem Programmierer die Möglichkeit, mehrere Gadgets zu aktualisieren und dann einen sichtbaren Refresh durchzuführen.

Ich sehe das wie Malte.

Wenn ich SetGadgetAttrs() aufrufe, dann setzte ich das Objekt auf einen neuen Stand und erwarte das die auch entsprechend sofort visualisiert wird.

Die Komplexität des Objekts spielt ja keine Rolle, da nur das eine Objekt neu gezeichnet wird. Umgekehrt wird ein Schuh draus. Wenn ich ein simples Gadget wie eine CheckBox nur via UpdateGList() aktualisieren kann, dann flimmert und flackert alles auf dem Schirm und obwohl eigentlich nur ein triviales Objekt erneuert wurde, müssen auch die komplexen neu visualisiert werden.

Geit

[ - Antworten - Zitieren - Direktlink - ]

09.11.2005, 09:19 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von geit:
Ich sehe das wie Malte.

Wenn ich SetGadgetAttrs() aufrufe, dann setzte ich das Objekt auf einen neuen Stand und erwarte das die auch entsprechend sofort visualisiert wird.

Das mußt Du mit den Entwicklern des OS ausmachen. Ich habe nur gesagt, was möglicherweise die Motivation dahinter ist. Ich habe nicht gesagt, daß ich das toll finde, oder daß es keine besseren Möglichkeiten gäbe.

Zitat:
Die Komplexität des Objekts spielt ja keine Rolle, da nur das eine Objekt neu gezeichnet wird. Umgekehrt wird ein Schuh draus. Wenn ich ein simples Gadget wie eine CheckBox nur via UpdateGList() aktualisieren kann, dann flimmert und flackert alles auf dem Schirm und obwohl eigentlich nur ein triviales Objekt erneuert wurde, müssen auch die komplexen neu visualisiert werden.

Kann es sein, daß Du nur noch postest, um den Satz "Umgekehrt wird ein Schuh draus." irgendwo unterzubringen? Ich weiß nicht, was für ein AmigaOS Du hast, bei meinem gibt es eine Funktion RefreshGList, die einen Pointer auf des erste betroffene Gadget und die Anzahl übergeben bekommt. Damit kann man auch exakt ein Gadget refreshen, ohne daß andere neu gezeichnet werden.
Und die Performance-Betrachtung bezieht sich auf einen Gruppe von vielen, nicht-trivialen Gadget, die in einem Durchgang aktualisiert werden müssen.
Ich habe nie gesagt, daß ein einzelnes CheckBox-Gadget asynchron aktualisiert werden sollte. Aber eine Situation zu konstruieren, die konträr zum Thema ist, hilft natürlich "Umgekehrt wird ein Schuh draus" irgendwo unterzubringen, nicht wahr?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

09.11.2005, 13:02 Uhr

geit
Posts: 332
[Ex-Mitglied]

Zitat:
Original von Holger:

Zitat:
Original von geit:
Ich sehe das wie Malte.

Wenn ich SetGadgetAttrs() aufrufe, dann setzte ich das Objekt auf einen neuen Stand und erwarte das die auch entsprechend sofort visualisiert wird.
Das mußt Du mit den Entwicklern des OS ausmachen. Ich habe nur gesagt, was möglicherweise die Motivation dahinter ist. Ich habe nicht gesagt, daß ich das toll finde, oder daß es keine besseren Möglichkeiten gäbe.

Zitat:
Die Komplexität des Objekts spielt ja keine Rolle, da nur das eine Objekt neu gezeichnet wird. Umgekehrt wird ein Schuh draus. Wenn ich ein simples Gadget wie eine CheckBox nur via UpdateGList() aktualisieren kann, dann flimmert und flackert alles auf dem Schirm und obwohl eigentlich nur ein triviales Objekt erneuert wurde, müssen auch die komplexen neu visualisiert werden.

Kann es sein, daß Du nur noch postest, um den Satz "Umgekehrt wird ein Schuh draus." irgendwo unterzubringen? Ich weiß nicht, was für ein AmigaOS Du hast, bei meinem gibt es eine Funktion RefreshGList, die einen Pointer auf des erste betroffene Gadget und die Anzahl übergeben bekommt. Damit kann man auch exakt ein Gadget refreshen, ohne daß andere neu gezeichnet werden.
Und die Performance-Betrachtung bezieht sich auf einen Gruppe von vielen, nicht-trivialen Gadget, die in einem Durchgang aktualisiert werden müssen.
Ich habe nie gesagt, daß ein einzelnes CheckBox-Gadget asynchron aktualisiert werden sollte. Aber eine Situation zu konstruieren, die konträr zum Thema ist, hilft natürlich "Umgekehrt wird ein Schuh draus" irgendwo unterzubringen, nicht wahr?

Dir ist schon klar, das man RefreshGList() mit limitierter Anzahl von Gadgets nur verwenden darf, wenn man weis aus wievielen Gadgets ein Object besteht, oder?

Die Anzahl der Objekte in der Liste kann durchaus größer sein, als die Anzahl der Gadgets und da es sich um Blackboxen handelt, ist ein RefreshGList() nur über die ganze Liste oder über selbst eingehängte Gadgets sinnvoll.

Ein Listview bekommt man nur geupdatet, wenn man die ganze Liste updatet, also im günstigsten Fall vom Listview angefangen, bis zum Ende aktualisiert. Auch wenn ein CheckBox nicht aus mehreren Gadgets besteht, ist nicht gesagt, das das so bleiben wird. Ein gutes Beispiel ist das Integer-Input Gadget. Das kann auch jeweils ein Up/Down Gadget haben.

Geit

[ - Antworten - Zitieren - Direktlink - ]

09.11.2005, 17:05 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von geit:
Die Anzahl der Objekte in der Liste kann durchaus größer sein, als die Anzahl der Gadgets und da es sich um Blackboxen handelt, ist ein RefreshGList() nur über die ganze Liste oder über selbst eingehängte Gadgets sinnvoll.

Diese seltsame Konstrukton findet man nur bei gadtools. BOOPSI-Gadgets benutzen Kind-Gadgets, wenn sie aus einer Gruppe bestehen. Deshalb stimmt bei BOOPSI-Gadgets auch die Zahl 1 wieder, denn Kinder zählen nicht mit.

Zitat:
Ein Listview bekommt man nur geupdatet, wenn man die ganze Liste updatet, also im günstigsten Fall vom Listview angefangen, bis zum Ende aktualisiert.

Listview ist gadtools, gadtools ist nicht BOOPSI. Deshalb stellt gadtools ja auch seine eigenen Funktionen, z.B. für den Refresh, zur Verfügung, die diese Eigenheiten kennen.
gadtools und BOOPSI zu mischen führt zu Problemen. War halt ne ziemlich blöde Idee von Commodore diese zwei völlig verschiedenen Systeme mit OS2.0 einzuführen, deren Andersartigkeit aufgrund funktioneller Überschneidungen für den Programmierer nicht sofort in's Gesicht springt.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

09.11.2005, 17:41 Uhr

malte
Posts: 28
Nutzer

Ohne eine Grundsatzdebatte vom Zaun brechen zu wollen, stellt sich hier ein wenig die Frage nach (verbindlichen) Entwicklungs-Richtlinien.
Das hier zugrunde liegende Problem ist im OS4 beheimatet und kann wohl jetzt auch nicht mehr geändert werden - es zeigt aber deutlich, das der eine es so macht und der andere ganz anders (ich bin immer noch der Meinung entweder alle Reaction-Klassen refreshen von alleine - oder keine (wobei bei keine der Entwickler dann selbst entscheidet wann er alle updates durchgeführt hat und refresht werden soll)).
Ich erinnere mich dunkel das es mal gewisse Richtlinien von Commodore gab - gibt es derartiges (GUI, Programmier, "Lieferumfang" (Installer, Anleitung (welches Format)), usw...) fürs OS4 bzw. andere "moderne" Amiga-OSe (tolles wort) oder ist da irgendetwas geplant?

Grüße,

Malte

[ - Antworten - Zitieren - Direktlink - ]

09.11.2005, 17:58 Uhr

Holger
Posts: 8116
Nutzer

@malte:
Natürlich sollte es Richtlinien geben. Ich sehe auch nicht, daß es für AOS4 zu spät wäre, solche aufzustellen. Mich würde ach nicht wundern, wenn solche in den Dokumentationen längst zu finden sind.
Die Frage ist wohl eher, ob es sich bei den betroffenen Klassen um AOS4-Entwicklungen handelt oder nur einfache re-compiles. Im ersten Fall würde man erwarten, daß die Richtlinien eingehalten werden, im zweiten Fall sollte es irgendwann mal nachgereicht werden.
Wie auch immer-betrifft Dein Problem nun eine Kernkompente, die bei AOS4 mitgeliefert wird, oder ein 3rd-Party Produkt?
Gibt es überhaupt 3rd-Party Reaktion Klassen, die das betrifft?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

09.11.2005, 22:15 Uhr

malte
Posts: 28
Nutzer

@Holger:
das eigentliche Problem ist gelöst (Checkbox, also Kernkomponente), damit könnte man das ganze Thema jetzt abschliesen.
Vielleicht wäre dies auch sinnvoll gewesen.
Was bleibt ist aber das grundsätzliche Problem, das eine Gruppe von Objekten sich unterschiedlich verhält - was nicht
sinnvoll ist (zudem scheint in den AutoDocs das Verhalten nicht immer dokumentiert zu sein (mir ist klar, daß man dann
das halt Abfragt und einen Refresh einbaut)).
Ich habe jetzt fünf Jahre nicht mehr auf dem Amiga programmiert, davor eine ganze Weile in Assembler (MEReset,
MEExchange, MEAutoStart usw.) und jetzt setze ich meine alten Programme in C auf OS4 um, ich schlage mich also nun mit C
und einem "neuen" Betriebssystem rum und da sind solche Sachen ein wenig nervig - zumal sie einfach zu vermeiden sind.
Ich habe nun wieder einige Dinge gelernt und möchte mich dafür bedanken - die ein oder andere Frage wird aber sicherlich noch kommen...

Grüße,

Malte

[ - Antworten - Zitieren - Direktlink - ]

10.11.2005, 00:06 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von Holger:
Listview ist gadtools, gadtools ist nicht BOOPSI. Deshalb stellt gadtools ja auch seine eigenen Funktionen, z.B. für den Refresh, zur Verfügung, die diese Eigenheiten kennen.
gadtools und BOOPSI zu mischen führt zu Problemen. War halt ne ziemlich blöde Idee von Commodore diese zwei völlig verschiedenen Systeme mit OS2.0 einzuführen, deren Andersartigkeit aufgrund funktioneller Überschneidungen für den Programmierer nicht sofort in's Gesicht springt.

Reicht es nicht darauf zu achten, dass die GadTools-Gadgets hinter allen anderen Gadgets in der Liste stehen?

Tschüß,

[ - Antworten - Zitieren - Direktlink - ]

10.11.2005, 09:37 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von NoImag:
Reicht es nicht darauf zu achten, dass die GadTools-Gadgets hinter allen anderen Gadgets in der Liste stehen?

Erstmal muß man den sog. Context erstellen, der ein Pseudogadgets darstellt. Ob das das erste in der List oder direkt vor dem ersten gadtools Objekt liegen muß, ist nicht eindeutig spezifiziert, jedenfalls nicht in den Dokumentationen, die ich hier habe.
Außerdem mußt Du sämtliche Intuition-Messages durch den gadtools-Filter jagen und die Refresh-Funktionen von gadtools verwenden, deren Seiteneffekte auf die BOOPSI-Gadgets nicht spezifiziert sind, es wird ja nicht mal gesagt, warum gadtools diesen Aufwand benötigt...
Da solche Machwerke aber nicht die grundlegenden Funktionen von BOOPSI bieten, wie z.B. Objekte mit einem Ziel für die Notification zu versehen, sondern eher OS1.x-Programmierung entsprechen, sollte man sich gut überlegen, ob sich so ein Aufwand lohnt.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

13.11.2005, 00:52 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von Holger:

Zitat:
Original von NoImag:
Reicht es nicht darauf zu achten, dass die GadTools-Gadgets hinter allen anderen Gadgets in der Liste stehen?
Erstmal muß man den sog. Context erstellen, der ein Pseudogadgets darstellt. Ob das das erste in der List oder direkt vor dem ersten gadtools Objekt liegen muß, ist nicht eindeutig spezifiziert, jedenfalls nicht in den Dokumentationen, die ich hier habe.
Außerdem mußt Du sämtliche Intuition-Messages durch den gadtools-Filter jagen und die Refresh-Funktionen von gadtools verwenden, deren Seiteneffekte auf die BOOPSI-Gadgets nicht spezifiziert sind, es wird ja nicht mal gesagt, warum gadtools diesen Aufwand benötigt...
Da solche Machwerke aber nicht die grundlegenden Funktionen von BOOPSI bieten, wie z.B. Objekte mit einem Ziel für die Notification zu versehen, sondern eher OS1.x-Programmierung entsprechen, sollte man sich gut überlegen, ob sich so ein Aufwand lohnt.

Ich finde die Aussagen in den RKRMs eindeutig:

Zitat:
(For applications with special needs, custom solutions can be created with Intuition's already-familiar gadgets or its new Boopsi object-oriented custom gadget system; GadTools is compatible with these.)

Da steht, dass man gleichzeitig Intuition-, BOOPSI- und GadTools-Gadgets verwenden darf. Es wäre unter AOS 3.0 sonst auch ziemlich aufwändig, das colorwheel.gadget und das gradientslider.gadget zu nutzen.

Zitat:
When the gadget passed to "FreeGadgets()" is the first gadget in a linked list, the function frees all the GadTools gadgets on the list without patching pointers or trying to maintain the integrity of the list. Any non-GadTools gadgets found on the list will not be freed, hence the result will not necessarily form a nice list since any intervening GadTools gadgets will be gone.

Das heißt, dass die GadTools-Gadgets zwar nicht direkt hintereinander liegen müssen, dass es aber bei der Freigabe Probleme gibt, wenn dies nicht der Fall ist.

Auch zu dem Aufwand bezüglich Messages und Refresh steht in den RKRMs etwas, auch wenn das sicher nicht umfassend ist. Da GadTools aber eine Blackbox sein soll, ist dies auch nicht verwunderlich. Es reicht doch obige Aussage, dass GadTools mit anderen Gadgets gemischt werden darf.

Tschüß,

[ - Antworten - Zitieren - Direktlink - ]

13.11.2005, 18:30 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von NoImag:
Da steht, dass man gleichzeitig Intuition-, BOOPSI- und GadTools-Gadgets verwenden darf. Es wäre unter AOS 3.0 sonst auch ziemlich aufwändig, das colorwheel.gadget und das gradientslider.gadget zu nutzen.

Nicht alles, was man machen kann, muß oder sollte man auch. Die Frage ist nicht, wie aufwändig die Integration von BOOPSI Gadgets, wie gradientslider und colorwheel ist, sondern wie aufwändig das Benutzen von gadtools-Zeug ist, das mit seinem ominösen Kontext und den speziellen Refresh-, SetAttr- und IDCMP- Funktionen daherkommt und den Programmierer bei der Implementierung von Font-Sensitiven Oberflächen oder optisch aufbereiteten Gruppen (Rahmen und Titel, etc) vollkommen allein läßt, während BOOPSI-basierte Toolkits wie ReAction oder MUI einem genau dieses frei Haus liefern und mit den Standard- Intuition- Funktionen zusammenarbeiten.
Welchen Grund gibt es da noch, unter OS3.0 oder höher gadtools zu benutzen?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

14.11.2005, 00:27 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von Holger:
Welchen Grund gibt es da noch, unter OS3.0 oder höher gadtools zu benutzen?

Mir war nicht bewusst, dass dies die Frage ist. Aber um sie zu beantworten: Bei neuer Software keinen, bei alter höchstens der Aufwand die Oberfläche neu zu schreiben.

Tschüß,

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > CheckBox-Problem unter OS4

[ - Suche - Neue Beiträge - Registrieren - Login - ]