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

Donnerstag, 25. Januar 2018, 13:13

Wo ist der Prototype?

Ich würde gern eine spezielle Msg aus GROBJ.GOH anwenden (bei mir Zeile 7407). Neben dem Messagenamen steht /*Needs Prototype*/. Ich denke, dass ich alles abgesucht habe, eine entsprechnede Prototype-Msg habe ich nicht gefunden. Und ohne funktioniert die Parameterübergabe (natürlich) nicht. Kann man wohl nichts machen oder?

Wilfried

2

Donnerstag, 25. Januar 2018, 15:28

Nu ma nich so pessimistisch ;-)

Folgende Messages werden gerufen wenn der Mauspointer ein View betritt oder verlässt.
@importMessage MetaWindowMessages, void MSG_META_RAW_UNIV_ENTER (); /* NEEDS PROTOTYPE! */

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

In irgend einem anderen Header, den ich jetzt nicht gefunden habe, steht auch in welchen Registern du was übergeben musst (in Assembler)

Um sie zu benutzen muss man C-Parameter haben . Das habe ich mit Grossibärs Hilfe so gemacht:

@class PaintViewClass, GenViewClass;
@alias (MSG_META_RAW_UNIV_ENTER) void MSG_PAINT_VIEW_ENTER
(optr inputObj = cx:dx, WindowHandle ptrWin = bp);
@alias (MSG_META_RAW_UNIV_LEAVE) void MSG_PAINT_VIEW_LEAVE
(optr inputObj = cx:dx, WindowHandle ptrWin = bp);
@endc;

Wenn die Message einen Returnparameter in carry übergibt muss du statt "void ...."
"Boolean ... = carry" schreiben.

Vielleicht hilfts ja ;-)

Gruß
Rainer


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

3

Donnerstag, 25. Januar 2018, 17:22

Ich weiß nicht recht, ob ich das verstanden habe :( .
"MSG_PAINT_VIEW_ENTER" ist also deine eigene Creation? Und die Message, die eigentlich einen Prototype benötigt, wird unter einem Alias-Namen verwendet?
In der von mir angesprochenen Message werden die Übergabeparameter einschließlich der zu verwendenden Register genannt.

4

Donnerstag, 25. Januar 2018, 21:37

Im Prinzip ja. Frag micht nicht warum, aber so macht man es wohl ;-)
Welche Message ist es denn? Mach mal bitte einen Auszug aus deiner GrObj.goh.
Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

5

Freitag, 26. Januar 2018, 11:14

Hallo Rainer, hier die Message:
@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

Ich habe es nach deiner Anleitung jetzt so versucht:

@class GCGrObjAttributeManagerClass, GrObjAttributeManagerClass;

@alias (MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT) Boolean MSG_LINIENATTRIBUTE_HOLEN
(word index = cx, GrObjFullLineAttrElement *linienelement = ss:bp)=carry;

@endc

Den Inhalt von index habe ich.
pmake:
error: ss:bp cannot be used with any other register
warning: MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT is not a message for the class being defined now

Ich kann mit diesen Meldungen nicht viel anfangen.

Wilfried

6

Freitag, 26. Januar 2018, 16:52

Hm, das ist doof. Ich hätte es auch genau so versucht. Die Fehlermeldungen sagen mir jetzt auch nichts.
Mail doch mal Marcus oder Falk an, sie sollen mal auf den Thread schauen, vielleicht fällt ihnen etwas dazu ein.

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

7

Sonntag, 28. Januar 2018, 18:49

Ist das wieder so'n Ding, wo man den Code als "Pascal" oder so dekorieren muss?
d[ 0_O ]b

8

Sonntag, 28. Januar 2018, 22:16

Die Übermittlung von Parametern auf dem Stack (ss:bp) und die zusätzliche übergabe vom CX-Register ist in der GOC/C-Message-API nicht vorgesehen, die entsprechenden Messages können mit GOC nicht angesprochen werden. Ggf. kommt man mit inline-ASM weiter.

9

Montag, 29. Januar 2018, 12:50

Hallo Falk,

per Inline-ASM hab ich's versucht, es wird aber nicht compiliert. Ich hab eigentlich auch keine Ahnung, wie Segment und Offset des Array-Elements an ss:bp übergeben werden. Muss bp erst gesichert werden? Das Aufrufen der Message wird jedenfalls nicht akzeptiert (Invalid combination of opcode and operants).

GrObjBaseLineAttrElement *linienattribute;
word index,linienattr_high,linienattr_low;

index=@call objekt::MSG_GO_GET_GROBJ_LINE_TOKEN(); //funktioniert!
linienattr_high=PtrToSegment(linienattribute);
linienattr_low=PtrToOffset(linienattribute);

asm {
mov cx, index
mov ss, linienattr_high
mov bp, linienattr_low

call MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT
}


Wilfried

10

Mittwoch, 31. Januar 2018, 12:13

Ich habe noch einen anderen Weg versucht:
Der GrObjAttributeManager hat die Instanzvariable GOAMI_lineAttrArrayHandle. Vielleicht hätte man über dieses Handle an das Attribute-Array kommen können. Leider hat dieses Handle immer den Wert 0, egal wieviele Linien mit unterschiedlichen Attributen existieren.
Schade :(

Wilfried

11

Mittwoch, 31. Januar 2018, 16:34

Hallo,
folgendes kam mir dabei in den Kopf:
index=@call objekt::MSG_GO_GET_GROBJ_LINE_TOKEN(); //funktioniert!
ich denken, syntaktisch geht es, der Compiler meckert nicht. Funktionell sollte es nicht gehen, weil die Übergabewerte nicht da sind.

call MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT
Macht man das nicht so?

Quellcode

1
2
3
mov das_richtige_register, MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT
mov andere_register, paramters
call CObjMessage


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

12

Mittwoch, 31. Januar 2018, 17:00

Hallo Rainer,

index=@call objekt::MSG_GO_GET_GROBJ_LINE_TOKEN() funktioniert tatsächlich. Ich erhalte korrekte Indices für das Attribute-Array (objekt ist der optr zum selektierten Grafikobjekt, vom GrBody geholt).

call MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT funktioniert dagegen nicht mal syntaktisch.

Deinen Quellcode verstehe ich nicht. Wo wird hier der Pointer auf das Array übergeben?

Wilfried

13

Donnerstag, 1. Februar 2018, 10:02

Sorry, dein Quellcode sollte ja nur das Senden einer Message verdeutlichen.
Wenn es also so geht, welches sind dann die richtigen Register?

Wilfried

14

Donnerstag, 1. Februar 2018, 21:21

Hallo Wilfried,
call MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT funktioniert dagegen nicht mal syntaktisch.
Natürlich nicht, MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT ist eine Zahl, also eigentlich eine C-Konstante ;-)


Wenn ich dass richtig verstanden haben, geht das mit dem Senden einer Message in Assember so:
- Lade die Message-Nummer in ein Register (AX ?)
- lade die Parameter in anderer Register oder pushe sie auf den Stack
- Rufe eine Asm-Routine, die den eigentlichen Message-Aufruf erledigt.


Die nötigen Parameter hast du oben schon selbst beschrieben:
* PASS
* cx - line token
* ss:bp - GrObjFullLineAttrElement - empty
Für folgendes musst du noch mal die Quellcodes durchforsten, da bin ich jetzt nicht sicher
1. Die Message muss du wahrscheinlich nach AX laden
2. Vielleicht heißt die Routine, die du callen musst nicht CObjMessage sondern nur ObjMessage oder irgendwie ähnlich.

Um den Inline Assembler zu benutzen musst du vor jede Zeile asm schrieben oder du versuchst
asm {
.. code hier
}

Wenn ich komplett falsch liege, lass es mich wissen ;-)

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

15

Sonntag, 11. März 2018, 19:14

Im asm-file habe ich jetzt die folgenden Zeilen:

sub sp, 4Ch ;76 Bytes Richtung Top of Stack, dort liegt lineattr
mov bp, sp
mov cx, linetoken
movdw bxsi, @GCGOAM ;Adresse des Rezipienten
mov ax, MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT ;ID 18441
mov di, mask MF_CALL or mask MF_FIXUP_DS

call ObjMessage

add sp, 4Ch

Swat zeigt, dass die Zeilen bis zu call ObjMessage abgearbeitet werden. Nach der call-Zeile sagt Swat
no source available in ... ,
macht dann aber scheinbar weiter und bricht irgendwann ab, ohne aus ObjMessage herausgekommen zu sein.
Was könnte diese Meldung bedeuten?

16

Sonntag, 11. März 2018, 22:07

Hallo Wilfried,
Was könnte diese Meldung bedeuten?
Wahrscheinlich, dass die Stackmanipulation nicht so funktioniert wie du dir das vorstellst. Das Bachgefühl sagt, das mir der Code nicht gefällt. Wenn ich nicht völlig falsch liege sehe ich mindestens folgende potentiellen Probleme:
1. Der Stack wächst doch nach unten, oder? sub sp, xxx verschiebt den Stack in den Arbeits-Bereich, der von Interrupts überschrieben wird. Wieso liegt da etwas sinnvolles?
2. Du überschriebst diverse Register ohne sie zu retten, insbesondere bp.

Gruß
Rainer

P.S. Nur um Missverständnissen vorzubeugen: SP zeigt doch auf den Top Of Stack, oder? Wieso verschiebts du ihn "in Richtung Top of Stack"?

PPS: Noch zu 1: Hast du "lineattr" vorher gepusht? Dann schiebst du in die falsche Richtung. Du darfts aber nicht sp direkt ändern, sonst überschreibt dir der nächste Interrupt die Daten.
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

17

Montag, 12. März 2018, 13:18

Hallo Rainer,

<<Du überschriebst diverse Register ohne sie zu retten, insbesondere bp.>>
ich habe die uses-Anweisung benutzt: uses ss,si,bp. In Verbindung mit .enter und .leave soll esp laut Doku automatisch die Zeilen push bp und mov bp, sp ins Compilat einfügen.

<<sub sp, xxx verschiebt den Stack in den Arbeits-Bereich,>>
Du hast recht, sp zeigt ja schon zum TOS. Aber in verschiedenen Routinen (GrObj-Library) im Zusammenhang mit dem Zugriff auf das AttributeArray wird es merkwürdigerweise so gemacht.

Bisher hatte ich lineattr als einzige lokale Variable deklariert (aber nicht gepusht). Sp zeigt dann auf den Anfang dieser Struktur. Bp allerdings noch nicht, aber in ss:bp soll die Struktur übergeben werden. Wenn ich nun mov bp, sp einfüge (und call ObjMessage erst mal auskommentiere), meldet swat nach .leave, dass sp nicht auf die Rücksprungadresse zeigt. Muss ich sp händisch zurückstellen?

Und noch eine Sache, die ich nicht verstehe: Ich nehme zwischen .enter und .leave alles raus und füge nur die Zeilen
mov ss:[bp].GOFLAE_base.GOBLAE_width.WWF_int,9h
mov ax, ss:[bp].GOFLAE_base.GOBLAE_width.WWF_int
ein. Tatsächlich enthält ax dann 9h! Wieso kann ich auf die Struktur zugreifen?

Eine letzte Unklarheit: Wenn es heißt, in ss:bp wird die Struktur übergeben und zurückgegeben, wird dann tatsächlich die Struktur auf dem Stack oder nur die Adresse übergeben?

Gruß von einem deprimierten SDK-Programmierer ;)

18

Montag, 12. März 2018, 20:51

Hallo Wilfried,

Fragen über Fragen!
ich habe die uses-Anweisung benutzt: uses ss,si,bp. In Verbindung mit .enter und .leave soll esp laut Doku automatisch die Zeilen push bp und mov bp, sp ins Compilat einfügen.

Mag sein, ich habe nie damit gearbeitet. Es müsste noch ein sub sp, <size_of_local_variables> folgen. Dann wäre es für mich logisch.
Du hast recht, sp zeigt ja schon zum TOS. Aber in verschiedenen Routinen (GrObj-Library) im Zusammenhang mit dem Zugriff auf das AttributeArray wird es merkwürdigerweise so gemacht.
Very seltsam.
Bisher hatte ich lineattr als einzige lokale Variable deklariert (aber nicht gepusht). Sp zeigt dann auf den Anfang dieser Struktur.
Kann sein. Vorausgesetzt .enter schaufelt den Platz frei.

Zitat

Bp allerdings noch nicht, aber in ss:bp soll die Struktur übergeben werden. Wenn ich nun mov bp, sp einfüge (und call ObjMessage erst mal auskommentiere), meldet swat nach .leave, dass sp nicht auf die Rücksprungadresse zeigt. Muss ich sp händisch zurückstellen?
ja, klingt erste einmal komisch. Ich würde das jetzt in swat ganz genau versuchen nachzuvollziehen wann welches Register wohin zeigt und vielleicht sogar .enter und .leave rauslassen, um es zu verstehen. Ich mag keine Befehle, die etwas im Hintergrund erledigen. Das Thema ist recht komplex und ich vermute bin da einfach nicht firm genug um eine endgültige Diagnose zu geben.
Und noch eine Sache, die ich nicht verstehe: Ich nehme zwischen .enter und .leave alles raus und füge nur die Zeilen

mov ss:[bp].GOFLAE_base.GOBLAE_width.WWF_int,9h

mov ax, ss:[bp].GOFLAE_base.GOBLAE_width.WWF_int

ein. Tatsächlich enthält ax dann 9h! Wieso kann ich auf die Struktur zugreifen?
Kannst du vielleicht gar nicht. Du greifst beim Lesen und beim Schreiben auf genau die gleiche Speicherstelle zu. Mehr nicht. Sei froh, dass dein System hinterher noch läuft ;-)

Eine letzte Unklarheit: Wenn es heißt, in ss:bp wird die Struktur übergeben und zurückgegeben, wird dann tatsächlich die Struktur auf dem Stack oder nur die Adresse übergeben?
ss:bp ist ein pointer. Er sollte auf die Struktur zeigen. So verstehe ich das. Da ss im Spiel ist, ist der einzige Vernünftige Platz der Stack.

Soviel zu meinen Ferndiagnosetipps. :-)

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

19

Dienstag, 13. März 2018, 17:14

Das Thema ist in Gänze etwas komplexer zu lösen und zu erklären. Ich habe mal eine interne Verwendung eines Aufrufs an
MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT

rausgesucht:


Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
COMMENT @%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   	 GrObjGetGrObjFullLineAttrElement
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

SYNOPSIS:    Return GrObjBaseLineAttrElement for object

CALLED BY:    INTERNAL

PASS:   	 
   	 *ds:si - object
   	 cx - element number
   	 ss:bp - GrObjFullLineAttrElement - empty

RETURN:   	 
   	 stc - element exists
   		 ss:bp - GrObjFullLineAttrElement - filled
   	 clc - element
   		 ss:bp - garbage

DESTROYED:    
   	 nothing

PSEUDO CODE/STRATEGY:
   	 none

KNOWN BUGS/SIDE EFFECTS/IDEAS:
   	 This routine should be optimized for SPEED over SMALL SIZE
   	 because it is used during drawing

   	 Common cases:
   		 none


REVISION HISTORY:
    Name    Date   	 Description
    ----    ----   	 -----------
    srs    4/28/90   	 Initial version

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%@
GrObjGetGrObjFullLineAttrElement   	 proc    far
    uses    ax,dx,di
    .enter

EC <    call    ECGrObjCheckLMemObject   			 >

    mov    di,mask MF_FIXUP_DS or mask MF_CALL or mask MF_STACK
    mov    dx,size GrObjFullLineAttrElement
    mov    ax,MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT
    call    GrObjMessageToGOAM

    ;	Error check the the line attributes if data was
    ;	actually returned
    ;

EC <    jnc    errorDone   				 >
EC <    pushf   						 >
EC <    push    ds   					 >
EC <    segmov    ds,ss   					 >
EC <    call    GrObjCheckGrObjBaseLineAttrElement   		 >    
EC <    pop    ds   					 >
EC <    popf   						 >
EC <errorDone:   						 >

    .leave
    ret


Zwei Punkte lassen sich erkennen:

  1. In DX muß man die Größe der Struktur übergeben.
  2. MF_STACK muß man mit angeben, damit das System weiß, das ss:bp auf eine Strukur zeigt, die ggf. bei der Message-Verarbeitung in einem anderen Thread in den Stack des anderen Threads kopiert werden muß
Wenn man jetzt den Ansätzen folgend von C kommt, dann sollte man die Struktur, deren Pointer man übergibt, auf dem Stack halten (also als lokale Variable), dann ist tatsächlich nur noch bp anzupassen (nicht SP verändern wie in einem Beispiel weiter oben versucht).
So nun bin ich gespannt wieviel das weiterhilft :)

20

Dienstag, 13. März 2018, 19:08

Hallo Falk,

schön, dass du zu helfen versuchst :) .
Deine Vorschläge hatte ich schon alle versucht.
In deinem Quelltext wird call GrObjMessageToGOAM verwendet, was ja nur intern in der GrObj-Library möglich ist. Ich muss also den Empfänger extra angeben, was ich mit movdw bxsi, GCGOAM tue. Laut ESP-Doku soll das in den Registern bx und si gemacht werden, aber ist das wirklich so korrekt?
Wenn ich im Einzelschrittmodus durch die Prozedur gehe, dann meldet swat nach der Zeile call ObjMessage immer no source available in ..., bricht dann aber nicht sofort ab, sondern erst nach einigen hundert Schritten innerhalb des Codes, der in ObjMessage gefunden wurde, dann meist mit illegal handle.
Hier der aktuelle Stand meiner Prozedur:

LA proc far linetoken:word, GCGOAM:optr

lineattr local GrObjFullLineAttrElement

.enter

mov cx, linetoken ;linetoken nach cx
movdw bxsi, GCGOAM ;Adresse des Rezipienten
mov bp, sp

mov dx, size GrObjFullLineAttrElement ;Anzahl der auf dem Stack übergebenen Bytes

mov ax, MSG_GOAM_GET_FULL_LINE_ATTR_ELEMENT ;ID 18441
mov di, mask MF_CALL or mask MF_FIXUP_DS or mask MF_STACK

call ObjMessage
;no source available in

mov ax, ss:[bp].GOFLAE_base.GOBLAE_width.WWF_int

.leave
ret

LA endp

Thema bewerten