Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: GEOS-InfoBase-Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Freitag, 15. Juli 2016, 11:34

Instance Data eines Grafik Objekts

Ich möchte gern auf die Instance Data eines selektierten Grafik Objekts zugreifen. ObjektOD enthält den Objektpointer, mit @call ObjektOD ... kann ich dem Objekt Messages schicken. Um auf die Instance Data zuzugreifen, habe ich mir pself "ausgeliehen", um mit pself=ObjDerefVis(ObjektOD) den Pointer zu den Instance-Daten zu bekommen. Beim anschließenden Zugriff mit z.B. pself->GOI_ lineAttrToken sagt pmake, dass GOI_lineAttrToken nicht bekannt sei, obwohl es ja ein Instance-Datum der GrObjClass ist. Also: Wie gelange ich an die Instance-Daten?

Wilfried

2

Freitag, 15. Juli 2016, 14:00

Hmmm... gab's dafür nicht 'ne Message? MSG_META_GET_FLAGS? MSG_META_GET_VAR_DATA? MSG_VIS_GET_ATTRS? MSG_VIS_GET_GEO_ATTRS? Oder so?
d[ 0_O ]b

3

Samstag, 16. Juli 2016, 10:11

Alles Messages aus dem Assembler-Bereich. Leider bezieht sich keine auf die Instance Data.

Wilfried

4

Samstag, 16. Juli 2016, 17:17

Was heißt ausgeliehen? Welchen Typ hat bei dir pself? Bei falschem Typ kennt er die Elemente nicht. Für xxxClass muss es xxxInstance sein.
Z.b. GenInteractionClass:
GenInteractionInstance *pself;
Außerdem muss natürlich der Block des Objekts objectOD gelockt sein. Sonst geht gar nichts.

Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

5

Sonntag, 17. Juli 2016, 11:20

Ok, ich hatte nur gelesen, dass pself ein Objektpointer ist, und mir den Einsatz von pself in anderen Beispiel-Applikationen abgeguckt (wieder mal weiße Flecken auf meiner Geos-Wissenskarte;-)).
Ich habe jetzt definiert: GrObjInstance *pselbst
Damit geht's. Allerdings weiß ich noch nicht, ob die Werte, die ich mit pselbst->GOI_lineAttrToken erhalte, auch sinnvoll sind. Mit diesen Werten muss ich den GrObjAttributeManager fragen, was er für Attribute (die Liniendicke will ich wissen) für die selektierte Linie hat.
Die Notwendigkeit des Blockens war mir schon klar, obwohl ich auch dort noch zumindest graue Flecken habe;-).

Danke Rainer!

Wilfried

6

Montag, 18. Juli 2016, 10:32

Die Probleme nehmen kein Ende;-).

Mit der folgenden Message wollte ich die linienattribute abrufen:

@message void MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT(); /* Needs Prototype */
/*
* Get line attribute element from element array
*
* Context: GrObjAttributeManager Utility
* Source: Unrestricted
* Destination: GrObjAttributeManager
* Interception: Unlikely
*
* PASS
* cx - line token
* ss:bp - GrObjFullLineAttrElement - empty
*
* RETURN
* carry set if passed token valid
* ss:bp - GrObjFullLineAttrElement - filled
* ax - element size
*
* carry clear if no information retured
*
* DESTROYED:
* ax
*/

Also habe ich definiert:
GrObjFullLineAttrElement LinienAttribute;
Und dann @call DGOAM::MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT(line_token,&LinienAttribute) (line_token hatte ich vorher ja schon bestimmt).
Pmake erwartet einen "extra parameter". Laut obiger Beschreibung wird auch noch die Elementgroesse zurückgegeben. Also habe ich noch ein &size (word) angehängt. Immer noch "extra parameter". Mich irritiert auch die Bemerkung /* Needs Prototype */.
Mir fehlt hier die Erfahrung, wie ich mit dieser Message umgehen soll.

Wilfried

7

Montag, 18. Juli 2016, 10:52

Hallo!

Mich irritiert eher das evtl. gesetzte Carry-Flag. Wieso wird hier kein Bool zurückgegeben?

Jörg
d[ 0_O ]b

8

Montag, 18. Juli 2016, 18:15

Hallo Wilfried,

zunächst zur Fehlermeldung: Wenn da steht "extra parameter in..." heißt das, dass du zu viele Parameter übergeben hast. Was auch logich wäre da die Message als void() definiert ist.

Nach einem Blick in die GOH Datei würde ich in folgende Richtung denken:

Quellcode

1
@alias (MSG_GOAM_DEREF_LINE_ATTR_ELEMENT_TOKEN) Boolean MSG_MY_GOAM_MSG(word token = cx, GrObjFullLineAttrElement* = ss:bp) = carry


und dann MSG_MY_GOAM_MSG aufrufen, mit den Parametern von dir. Schönheitsfehler: Wie ich AX verbraten soll, weiss ich nicht. Zu Sicherheit würde ich den aufrud der Meassage auch in

Quellcode

1
2
3
asm pusha
....
asm popa

klammern.


Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

9

Montag, 18. Juli 2016, 18:32

Noch mal zurück zu deinem ursprünglichen Problem:

habe ich das richtig verstanden, du willst von außerhalb des Objekts auf die Instancedaten des Objekts zugreifen? Das ist ja very dirty programming :rolleyes: , völlig vorbei am objektorientierten Konzept ... und folglich auch sehr wackelig.

Wie stellst du denn sicher, das der Block in dem sich dein GrObj Objekt befindet auch gelockt ist? Wenn du das kannst kannst du den Werten die du bekommst auch vertrauen. Halbwegs prüfen kannst du das in swat, wenn du dir dein pselbst vollständig ausprinten lässt.

Quellcode

1
p *pselbst

Dort solltest du "vernünftige" Werte angezeigt bekommen.

Ansonsten: Hast du mal drüber nachgedacht das GrObjAttributeManager Objekt zu überschrieben? Dann hast du direkten Zugang zu den Instance-Daten.

Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

10

Mittwoch, 20. Juli 2016, 10:51

Hallo Rainer,

ich habe deinen Vorschlag noch nicht probiert - weil ihn nicht verstanden habe.
Was bewirkt @alias? Und die Message, die du als Prototype nimmst, übergibt ja nur einen Parameter.
Und was bedeutet die "Klammerung" durch die asm-Zeilen?

Mein "dirty programming" resultiert einfach aus der Tatsache, dass ich keinen anständigen Weg sehe, die Instance-Daten des Grafik-Objekts auszulesen. Wenn ich die GrObjClass überschreibe, dann heißt das ja nicht, dass der GrBody und der GrObjAttributeManager sich der abgeleiteten Klasse bedienen.

Wenn ich das GrObjAttributeManager Objekt überschreibe und damit Zugriff auf dessen Instance-Daten erhalte, dann müsste ich das Array, das die Attribute-Sets enthält, selber nach dem richtigen Set ( das zu line_token gehört) durchsuchen, richtig?

Wilfried

11

Mittwoch, 20. Juli 2016, 12:35

Hallo Wilfried,

vor unendlich langer Zeit, in einem weit, weit entfernten Universum haben wir auf einem Programmieretreffen mal an einem Programm namens PixelPaint gebastelt. Dort haben wir eine Message gebraucht, die MSG_META_RAW_UNIV_ENTER heißt und im Header so definiert ist:

Quellcode

1
@importMessage	MetaWindowMessages, void MSG_META_RAW_UNIV_ENTER();	/* NEEDS PROTOTYPE! */

Jens-Michael Groß hat damals gesagt, man das so machen muss:

Quellcode

1
2
	@alias (MSG_META_RAW_UNIV_ENTER) void MSG_BASIC_VIEW_ENTER
		 (optr inputObj = cx:dx, WindowHandle ptrWin = bp);

Das funktioniert prima, deswegen habe ich das 1:1 auf dein Problem übertragen. Learning by looking.
Und die Message, die du als Prototype nimmst, übergibt ja nur einen Parameter.
Scroll mal nach rechts, es sind 2 Parameter :)

Wenn ich die GrObjClass überschreibe, dann heißt das ja nicht, dass der GrBody und der GrObjAttributeManager sich der abgeleiteten Klasse bedienen.
Ja, das ist des Pudels Kern. Theoretisch müsstest du bei GrObjBody eingreifen und ihn überreden die das Objekt in deiner abgeleiteten Klasse zu erzeugen. Ich kenne mich in den Mechanismen aber nicht aus und ein kurzes überfliegen der Messages bringt auch keine Klarheit. Nur MSG_GB_INSTANTIATE_GROBJ ist mir aufgefallen. Ich fürchte aber, die wird direkt vom Controller gesendet, dann hast du da wieder keinen Zugriff.

Wenn ich das GrObjAttributeManager Objekt überschreibe und damit Zugriff auf dessen Instance-Daten erhalte, dann müsste ich das Array, das die Attribute-Sets enthält, selber nach dem richtigen Set ( das zu line_token gehört) durchsuchen, richtig?
Das wäre zumindest eine Möglichkeit.

Und was bedeutet die "Klammerung" durch die asm-Zeilen?


Pusha pusht alle Register auf den Stack. Popa holt sie wieder runter. Das Problem ist, dass der C-Compiler natürlich die Register verwendet. Konkret könnte sich z.B eine lokale Variable in einem Register befinden. Das Problem hatte ich schon mal, allerdings hab ich da auch den Stack manipuliert ;-) Wenn wir jetzt eine "manipulierte" Methode aufrufen ist es denkbar, dass diese die Register versaut. Womit die Routine dann evt nicht funktioniert, obwohl der Mehodenaufruf an sich geklappt hat. Deswegen mache ich bei wackligen Tests (oder "wenn es gehen müsste, aber trotzdem nicht geht") manchmal sowas.

Gruß
Rainer


P.S.
Ich hab gestern gesehen dass Falk hier mitliest, evt. hat er ne Idee?
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

12

Mittwoch, 20. Juli 2016, 19:12

Scroll mal nach rechts, es sind 2 Parameter


Ich meinte den ersten Teil:
@alias (MSG_GOAM_DEREF_LINE_ATTR_ELEMENT_TOKEN)

Wie auch immer, vielen Dank für die Infos. Ich probier das jetzt einfach mal :)

Wilfried

13

Mittwoch, 20. Juli 2016, 23:22

Ist ja so (ohne Parameter) definiert ...
@message void MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT(); /* Needs Prototype */
Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

14

Donnerstag, 21. Juli 2016, 10:10

In meiner GrObj.goh steht :

@message Boolean MSG_GOAM_DEREF_LINE_ATTR_ELEMENT_TOKEN(
word token = cx) = carry;

Und diese Message soll ja dann wohl das Format von MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT() vorgeben. Das ist, was ich nicht verstehe.

Wilfried

15

Donnerstag, 21. Juli 2016, 10:50

Das liegt daran, daß in Assembler der Eingabewert "ss:bp" nicht benötigt wird, da er immer leer zu sein hat (sprich: da diese Speicheradresse immer einfach nur beim Aufruf überschrieben wird). In C muß hier aber ein Pointer übergeben werden, der später das Ergebnis von "ss:bp" aufnimmt.

PASS
* cx - line token
* ss:bp - GrObjFullLineAttrElement - empty

RETURN
* carry set if passed token valid
* ss:bp - GrObjFullLineAttrElement - filled
* ax - element size
d[ 0_O ]b

16

Donnerstag, 21. Juli 2016, 12:15

Danke Jörg!:-)

Zur Zeit ist neben Ihnen 1 Benutzer in diesem Thema unterwegs:

1 Besucher

Ähnliche Themen

Thema bewerten