code:

---

dumpRP% = -1	'generic failure

	' Create private messageport
	  pmp& = CreateMsgPort&()
   	  IF pmp& <> NULL& THEN
		' Allocate Printer IO block
		pio& = CreateIORequest&(pmp&, IODRPReq_sizeof%)
                IF pio& <> NULL& THEN
			' Open the printer.device
			r% = OpenDevice&(SADD("printer.device" + CHR$(0)), 0, pio&, 0)
			IF r% = 0 THEN
	  	         IF PEEKL(PEEKL(pio&+IODRPReqio_Device%)+pd_OldStk%+8)<>TPMATCHWORD& THEN
				' Fill in the IODRPRequest
				POKEW pio& + IODRPReqio_Command%, PRD_DUMPRPORT&
				POKEL pio& + io_RastPort%, rp&
				POKEL pio& + io_ColorMap%, cm&
				POKEL pio& + io_Modes%, modeID&
				POKEW pio& + io_SrcX%, x%
				POKEW pio& + io_SrcY%, y%
				POKEW pio& + io_SrcWidth%, x1%
				POKEW pio& + io_SrcHeight%, y1%

				POKEL pio& + io_DestCols%, 5000
				POKEL pio& + io_DestRows%, 5000
				POKEW pio& + io_Special%, SPECIAL_MILROWS& OR SPECIAL_MILCOLS&

			      ELSE  'Turboprint vorhanden

			      TPExtIODRP&=0
			      TPExtIODRP&=AllocVec&(6 ,MEMF_CLEAR&)
                              IF TPExtIODRP&=NULL& THEN EXIT FUNCTION
                              POKEW TPExtIODRP&+PixAspX%,1
                              POKEW TPExtIODRP&+PixAspY%,1
                              POKEW TPExtIODRP&+TPMode%,TPFMT_CyberGraphX% OR TPFMT_RGB24%   REM TPFMT_RGB24%


				' Fill in the IOTPDRPRequest
			  	POKEW pio& + IODRPReqio_Command%, PRD_TPEXTDUMPRPORT&
			 	POKEL pio& + io_RastPort%, rp&
			  	POKEL pio& + io_ColorMap%, cm&
			  	POKEL pio& + io_Modes%, TPExtIODRP&
			  	POKEW pio& + io_SrcX%, x%
			 	POKEW pio& + io_SrcY%, y%
			  	POKEW pio& + io_SrcWidth%, x1%
			  	POKEW pio& + io_SrcHeight%, y1%

			  	POKEL pio& + io_DestCols%, 5000
	        	 	POKEL pio& + io_DestRows%, 5000
			  	POKEW pio& + io_Special%, SPECIAL_MILROWS& OR SPECIAL_MILCOLS&
                            
			       END IF

				' Always give the user a change to abort.
				' So we'll use SendIO(), instead of DoIO(), to be asynch and
				' catch a possible user request to abort printing


 SendIO pio&
    PRINT "SendIO"

    ' Now Wait() for either a user signal or a printer.device signal

    sigfr& = xWait&((1& << PEEKB(pmp& + mp_SigBit%)))
    PRINT "hinter Wait"
    Delay 250
    PRINT "hinter delay"

    IF sigfr& AND (1& << PEEKB(pmp& + mp_SigBit%)) THEN
     ' printer is either ready or an error has occurred

     WHILE GetMsg&(pmp&)
      PRINT "getmsg"
      ' Remove any messages
     WEND
    END IF

    ' Return error code (in this case we count user-abort as an error)
    dumpRP% = PEEKB(pio& + IODRPReqio_Error%)
    PRINT "returncode" 

    CloseDevice pio&
    PRINT "device schliessen"
    IF TPExtIODRP& THEN FreeVec TPExtIODRP&
   ELSE
    dumpRP% = r%
   END IF
   DeleteIORequest& pio&
         END IF
         DeleteMsgPort pmp&
        END IF

---

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von thomas:
Und was soll der Blödsinn mit dem GetMsg ? Auf dem IO-Port darfst du nicht rumpfuschen.

---

Wieso auf dem IO-Port rumpfuschen? Er holt ganz normal Reply-Messages von dem, dem printer.device per IORequest übergebenen, MsgPort ab, falls da welche vorhanden sein sollten. Ok, die Qualität des Codes ist nicht gerade berauschend, vom Prinzip her macht er aber nicht allzu viel falsch und die Nutzung des MsgPort ist ok. Die RKM-Beispiele sehen genau so aus.

WaitIO() macht ja auch nichts anderes, abgesehen davon, daß es halt nur auf Nachrichten des jeweils genutzten Device bzw. IORequest wartet.

Wäre aber sicher besser zu erkennen gewesen, wenn er das Programm hier relativ vollständig gepostet hätte.

@MaikG:

Ist schon etwas seltsam, daß Dein Programm nicht auf die Reply-Message des gesendeten IORequests wartet. Zeig uns doch bitte mal den Request (pio&) im Detail, evtl. liegt da etwas im Argen. Könnte aber auch sein, daß Dir MB da einen Streich spielt. Hast Du irgendwelche Optimierungen des Compilers aktiviert?
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 12.09.2008 um 17:48 Uhr geändert. ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
Wieso auf dem IO-Port rumpfuschen? Er holt ganz normal Reply-Messages von dem, dem printer.device per IORequest übergebenen, MsgPort ab, falls da welche vorhanden sein sollten. Ok, die Qualität des Codes ist nicht gerade berauschend, vom Prinzip her macht er aber nicht allzu viel falsch und die Nutzung des MsgPort ist ok. Die RKM-Beispiele sehen genau so aus.

---

[ - Answer - Quote - Direct link - ]

@Holger:

Würde demnach bedeuten, daß er die Nachricht (sofern eine vorhanden ist) untersuchen muß, ob es sich um das Reply des IORequests handelt, den er sendete oder ob es sich nur um ein "just for fun"-Signal handelte. Also so ähnlich, wie man bei mehreren quasi gleichzeitig gesendeten Requests vorgehen würde, korrekt? Dann sind die RKMs "etwas" mißverständlich, was die gezeigten printer.device-Beispiele angeht.

Ist allerdings relativ bizarr, daß man sich nicht darauf verlassen kann, daß das printer.device nur dann signalisiert, wenn der Request tatsächlich fertig bearbeitet wurde oder eben ein Fehler vorliegt

(Ich meine das ausschließlich im Kontext mit dem gezeigten Programm, in dem nur auf Signale vom printer.device gewartet wird. Mir ist klar, daß die ganze Sache bei mehreren möglichen Signalquellen weit komplexer wird. Das ist hier aber nicht der Fall).

Wie ist das eigentlich (vielleicht weißt Du es ja): Sendet das printer.device tatsächlich Signale schon vor der Beendigung eines Requests? Ich könnte mir sowas vorstellen, um eine regelmäßige Überprüfung des Request-Status durch die Applikation zu gewährleisten. Die Frage ist nur, ob meine Vorstellung richtig ist...

@MaikG:

Du müßtest dann die GetMsg()-Geschichte um den Vergleich einer ggf. vorhandenen Message mit der IODRPReq-Struktur erweitern. Vergleich der beiden Zeiger (msg == pio), nicht der kompletten Struktur. Sind die Zeiger identisch, ist es die erwartete Nachricht und der IORequest ist "erledigt". Das kann allerdings auch eine "Erledigung" im Sinne einer Fehlermeldung sein wenn ich mich nicht sehr irre, das müßtest Du zusätzlich untersuchen, also nicht einfach nur den Error Code ausgeben.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von MaikG:
Wenn ich nach dem SendIO ein WaitIO setze und den Rest vom Code wegnehme geht das?

---

Sollte. Sollte auch gehen, wenn Du DoIO() verwendest und den Rest des Codes wegläßt.
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von RhoSigma:
Also ich verwende in solchen Fällen, ich meine das Warten auf eine Nachricht, immer eine Kombi aus WaitPort() und GetMsg() und falls letzteres dann doch NULL liefert, sprich tatsächlich gar keine Nachricht vorliegt, dann springe ich postwendend zurück zum WaitPort().

---

Das kommt wohl aufs Gleiche raus, wenn man Wait() verwendet, da WaitPort() intern auch Wait() verwendet. Interessant wäre zu erfahren, weshalb es bei ihm zum Schluß mehrere gleiche Druckzeilen liefert, obwohl die Wait()-Mimik so weit korrekt ist und auch der Request ok zu sein scheint.
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]