[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@Der_Wanderer:

> Letztendlich ist ja aber auch alles das gleiche.

Eben.

(auch slider und scroller)
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 22.07.2011 um 16:38 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von AGSzabo:
@Der_Wanderer:

> Du kannst ja auch kein Draw(Object) oder SetAttr(Object) machen, bevor das Object existiert, warum sollte das bei einem Bind anders sein?

Weil ich es umständlich finde, daß

- man sich das binding merken muss bis nacher

---

code:

---

<object id="a" ...>
<object id="b" bind="a" ...>

---

code:

---

<object id="a" bind="b"...>
<object id="b" bind="a" ...>

---

code:

---

<object id="a" bind="b" ...>
<object id="b">

---

Zitat:

---

- dass man den objekten eine id geben muss, bzw nach dem Erzeugen eine Funktion aufrufen muss.

---

code:

---

Object *a = CreateObject(...);
Object *b = CreateObject(...);
Bind(a,b);

---

Zitat:

---

Naja, geschmackssache. Dem einen erscheint das eine umständlich, dem anderen das andere. Wenn ich mir bis nacher die pointer auf die objekte irgendwie merken muss um zu binden kann ich auch nen pointer auf nen pointer merken.

---

code:

---

Object *a = CreateObject(...);
Object *b = CreateObject(...);
Bind(a,b);

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von AGSzabo:
edit: ah ja, das ist, damit elemente miteinander kommunizieren können, die verschiedene verhältnisse haben.

---

code:

---

<vgroup>
  <hgroup>
    <button action="back"/>
    <button action="forward"/>
    <button action="home"/>
  </hgroup>
  <text-pane content="main-document"/>
</vgroup>

---

[ - Antworten - Zitieren - Direktlink - ]

@Holger:

> Die Wertebereiche sind ja gerade deshalb unterschiedlich, weil Du einem bestimmten Gadgettypen den willkürlich gewählten Bereich von 0-0xffff aufzwingst. Mir fällt absolut kein Praxisbeispiel ein, bei dem es sinnvoll wäre Objekte mit unterschiedlichen Wertebereichen zu koppeln.

Sicher? Ein Slider bzw Scroller mag ja schon vom Haus aus vielleicht eine andere Pixelgröße als die Listview selber haben. Da muß man sowieso was umrechnen? Aber wahrscheinlich hast du recht.

ps: ich habe jetzt sowohl das Notify als auch das Bind eingebaut. ...so wie es sich mir im moment erschließt. Sind blos noch wenig Events (= Methoden) definiert. Ein Notify könnte auch einen callback-hook aufrufen..., nur um das mal zu standardisieren anstelle von dem daß jedes widget die option eines hooks selber herstellen muss und um zu vermeiden dass ein widget bei werteänderungen mehrere funktionen aufrufen muss, also zB das Notify UND den hook. Der Hook im Notify würde einfach mitgehen bei dem einen Notify-Aufruf und parallel dazu können andere elemente direkt informiert werden.

--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 23.07.2011 um 06:10 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von AGSzabo:
edit: ah ja, das ist, damit elemente miteinander kommunizieren können, die verschiedene verhältnisse haben.

---

Warum sollten sie das tun wollen?

---

Zitat:

---

Mir fällt absolut kein Praxisbeispiel ein, bei dem es sinnvoll wäre Objekte mit unterschiedlichen Wertebereichen zu koppeln.

---

Zitat:

---

@Der_Wanderer:

Mir ist ja schon bei Deinen Beispiel-XML aufgefallen, dass da nirgendwo schlüssig erkennbar ist, wie denn eigentlich die Anwendungslogik zum GUI kommt (oder umgekehrt). Da dachte ich noch, es läge an der Vereinfachung des Beispiels, aber jetzt bei der Binding Diskussion fällt es mir wieder auf.

---

code:

---

<button onclick="ping!">

---

code:

---

<button ontouch="ping!" onrelease="pong!">

---

code:

---

<slider id="mySlider" min="0" max="100" value="5">

---

code:

---

int value = GetAttrByID("mySlider",ATTR_VALUE);
SetAttrByID("mySlider",ATTR_VALUE,value+1);
SetAttrByID("mySlider",ATTR_VISIBILITY,VISIBILITY_INVISIBLE);

---

code:

---

Slider *myslider = GetObjectByID("mySlider");
int value = GetAttr(myslider,ATTR_VALUE);
SetAttr(myslider,ATTR_VALUE,value+1);
SetAttr(myslider,ATTR_VISIBILITY,VISIBILITY_INVISIBLE);

---

Zitat:

---

Wenn ich GUIs mittels XML erzeuge, dann definiert die Anwendung mögliche Aktionen und Daten und natürlich deren IDs. Diese werden von der XML-Datei referenziert, z.B.

code:

---

<vgroup>
  <hgroup>
    <button action="back"/>
    <button action="forward"/>
    <button action="home"/>
  </hgroup>
  <text-pane content="main-document"/>
</vgroup>

---

---

Zitat:

---

Da jedes GUI-Element an irgendeine anwendungsspezifische Logik gekoppelt ist, entfällt die Notwendigkeit, GUI-Elemente an andere GUI-Element zu koppeln, komplett.

---

Zitat:

---

Alle GUI-Elemente, die an dasselbe logische Feature gebunden sind, sind implizit zusammengebunden. Und Regeln, die zwischen unterschiedlichen logischen Elementen bestehen, sind Teil der Anwendung, nicht des GUIs.

---

Zitat:

---

So kann z.B. die Aktion "back" aus dem Beispiel dazu führen, dass der Status der Aktion "forward" zu <enabled> wechselt. Aber das tut er dann in jedem Fall, egal, wie das GUI aussieht, egal, ob die Aktion an einen Menüpunkt, einen Button oder ein Tastatur-Shortcut oder alles zusammen gebunden ist.

---

code:

---

<button onclick="back">
<menuitem onclick="back">
<key vanilla="b" onkeyup="back">
<arexx message="back" onreceive="back">

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Sicher? Ein Slider bzw Scroller mag ja schon vom Haus aus vielleicht eine andere Pixelgröße als die Listview selber haben. Da muß man sowieso was umrechnen? Aber wahrscheinlich hast du recht.

---

Zitat:

---

ps: ich habe jetzt sowohl das Notify als auch das Bind eingebaut.

---

Zitat:

---

...so wie es sich mir im moment erschließt. Sind blos noch wenig Events (= Methoden) definiert. Ein Notify könnte auch einen callback-

---

[ - Antworten - Zitieren - Direktlink - ]

.i code:

---

; object interconnection for use with oxNotify() / oxNotifyAttr()
; ---------------------------------------------------------------
;
; the difference between OX_BIND and OX_NOTIFY is, that one object may
; have multiple notifys but only one binding and that oxNotifyAttr()
; yet only works with notifys.
;
; OX_BIND makes a chain, where every object in the chain will get the
; message sent with oxNotify(). you must make a ring with OX_BIND in
; order to get a message read by all objects in the chain regardless
; of where you start it.
;
; OX_NOTIFY makes multiple destinations, but the message or attr is not
; sent further.
;
; you can use both the OX_BIND and the OX_NOTIFY(s) on one object, but
; OX_BIND works only once.

	XITEM	OX_NOTIFY		; generate notify from one object to annother, tag_data should
					; point to a taglist as shown below

	XITEM	OX_BIND			; bind one object to annother and back, the OX_BIND tag must be
					; followed by a pointer to a pointer where the address of the
					; destination object is stored with OX_PUTPTR or OX_RELPTR.

OX_REL		EQU	$00000001	; odd pointers in tag_data are offsets to current userbase  that
					; is active at the moment of creation (odd bit masked out)

; attributes for OX_NOTIFY:

	ENUM	$1000

	EITEM	oxNA_Target		; pointer to a pointer to destination object

	EITEM	oxNA_MatchAttr		; attribute to catch
	EITEM	oxNA_NewAttr		; attribute to send in place of the catched one
					; if this is not given, match attr is sent as is

	EITEM	oxNA_Hook		; attach a callback-hook to a widget to receive
					; everything that is sent through Notify() / NotifyAttr()
					; hook gets: a0/a3 object, a1 message, a4 base, a6 oxbase
					; the message is allways a method. if it comes from
					; NotifyAttr(), the message is OXM_SET and (a1) is attr, value

---

[ - Antworten - Zitieren - Direktlink - ]

.i code:

---

STRUCTURE	oxObject,0
	STRUCT	oxO_node,MLN_SIZE
	STRUCT	oxO_list,MLH_SIZE
	APTR	oxO_parent
	APTR	oxO_binding
	STRUCT	oxO_notifys,MLH_SIZE
	APTR	oxO_class
	UBYTE	oxO_flags
	UBYTE	oxO_hotkey
	APTR	oxO_prev		; for connection when pressing tabulator to focus next or prev object
	APTR	oxO_next		; ..
	APTR	oxO_drawinfo
	APTR	oxO_userbase		; the create() function takes a parameter in a1 that is a pointer to
					; a custom space where f.e. the app has its globals and it is needed
					; to have a pointer to them in the hook functions of the objects ...
					; but the main purpose of this field is that XUI stores pointers here
					; via the OX_PUTPTR and OX_RELPTR tag-commands

	APTR	oxO_userdata		; custom pointer or value set to what ever by the app
	ULONG	oxO_id			; custom field intended for search

	UWORD	oxO_left
	UWORD	oxO_top
	UWORD	oxO_width
	UWORD	oxO_height

	LABEL	oxO_SIZEOF

	BITDEF	oxO,INITIALIZED,0
	BITDEF	oxO,VISIBLE,1
	BITDEF	oxO,GHOSTED,2		; clickable?
	BITDEF	oxO,SLEEPING,3		; get no intuimessages like in ghost mode but stay fully visible,
					; sleeping widgets are skipped in the tabulator chain
	BITDEF	oxO,ACTIVE,4
	BITDEF	oxO,REFRESH,5		; refresh this gadget in next refresh run ..all childs of this gadget
					; are also refreshed

---

code:

---

ENUM	OX_METHODS

	EITEM	OXM_SET	; a1 oxm_set
	EITEM	OXM_GET	; a1 oxm_get

	EITEM	OXM_ADD	; a0 dest, a1 member		allow custom add-function for class
			;				example: window adds members to inner frame

	; ox objects are created and freed from central,
	; dispatchers do private work on them

	EITEM	OXM_SETDEF	; do this before tags are read to set default values

	EITEM	OXM_INIT
	EITEM	OXM_DEINIT
	EITEM	OXM_ACTIVATE
	EITEM	OXM_INACTIVE

	EITEM	OXM_INTUIMESSAGE

	EITEM	OXM_GETLAYOUT	; a1 oxLayoutInfo
	EITEM	OXM_SETLAYOUT	; ..  ..
	EITEM	OXM_setprop
	EITEM	OXM_DRAW	; draw (no sizes calculations)
	EITEM	OXM_DROPGFXBUFFERS
	EITEM	OXM_WINDOWOPEN
	EITEM	OXM_WINDOWCLOSING

   	EITEM	OXM_TABCHAIN	; link all interactive elements in a ring for
				; prev/next selection via tab
	EITEM	OXM_INVISIBLE
	EITEM	OXM_VISIBLE

	EITEM	OXM_APPWINMESSAGE
	EITEM	OXM_REFRESH

	EITEM	OXM_NEWPENS
	EITEM	OXM_INHERIT

	EITEM	OXM_ATTRSDONE	; this message (method) is sent after all
				; inital attribute tags have been set
				; this is usefull for example for creating co-objects,
				; like for example the grid, image and text in a button 

	EITEM	OXM_NEXT	; step to next/prev object in tabulator-chain
	EITEM	OXM_PREV	; this is required if a gadget hast multiple active areas,
				; like the multiple handles of a tabs gadget
	EITEM	OXM_ISCHILD

	EITEM	OXM_GETCLIP

	EITEM	OXM_HOTKEY	; if the class attribute oxCA_autohotkey is set to FALSE,
				; this method is sent to objects when their hoteky is pressed
				; (see class attributes)

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Total, Visible und Top != Max, Min, Value.

Die Logik die dahintersteckt ist eine ganz andere.

Und um nochmal zur Frage zurückzukehren, woher das Bedürfnis die interne Repräsentation auf 0..0xFFFF zu normalisieren?

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Definiert werden die im XML als String:

code:

---

<button onclick="ping!">

---

Die App wurde in dem Fall, wenn der Button erfolgreich gedrückt wird, das Notify "ping!" erhalten. In deinem Beispiel hast du es "action" genannt.

---

Zitat:

---

Zum Anderen kann die App auf GUI Elemente über die ID zugreifen, wenn sie die GUI Elemente manipulieren will.

code:

---

<slider id="mySlider" min="0" max="100" value="5">

---

---

Zitat:

---

Jain. Man kann alles über die App Logik machen.
ABER: in vielen Fällen will man das nicht.
Z.b. ein ListView mit einem Scroller. Das ist eine klassiche Kombination. Da willst du dich als App Entwickler nicht wirklich drum kümmern.
Also legt der ListView gleich noch selbst einen Scroller als Kind mit an, und macht ein "Binding", dass die App Logik gar nicht mitbekommt.

---

Zitat:

---

Es gibt aber auch durchaus Situationen, wo der GUI XML Schreiber das gerne hätte, um sich das Leben einfacher zu machen. Z.b. wenn ich die Auswahl eines TabViews an einen Cycle Button knüpfen will, oder einen Scroller für einen View nicht direkt daneben, sondern woanders haben will. Oder den Text einer Option eines Cycles in einen StringGadget kopieren will etc.

---

Zitat:

---

Eben nur ein Jain von mir. So simple Verknüfpungen wie die Arrows mit dem Scroller willst du bereits im GUI Code abfrühstücken, ohne den App Programmierer damit zu belästigen.

---

Zitat:

---

Richtig. Das schlägt sich im Konzept meiner "Notify"s wieder.
Z.b.

code:

---

<button onclick="back">
<menuitem onclick="back">
<key vanilla="b" onkeyup="back">
<arexx message="back" onreceive="back">

---

Die App Logik kennt nur das Notify "back", muss sich also nur EINMAL darum kümmern an EINER Stelle. => robusterer Code.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von AGSzabo:
Ich hab jetzt geändert so dass der scroller direkt mit den pixelwerten der view arbeitet. Nachteil, wenn der slider mehr pixel hat als die view, dann hoppelt er.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]