amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Druckproblem [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

12.09.2008, 16:13 Uhr

MaikG
Posts: 5172
Nutzer
Ich habe am Ende meines Ausdrucks manchmal eine Zeile die sich immer
wiederholt, in Pixeln ausgedrückt etwa 100.
Manchmal klappt auch alles reibungslos.
Nun ist im Programm alles I/O, kein Fehler zu finden, die
Grafik die geschickt wird ist immer 100% okay.
Spasseshalber hab ich nun einige Debug Ausgaben
eingefügt. xWait kommt zurück bevor der Druck beendet
ist, ports/dev ist also geschlossen wenn der druck immernoch
läuft.
Dann habe ich ein Delay nach dem Wait eingefügt.
Nun sind 5 von 5 ausdrucke erfolgreich.
Delay 100 reicht nicht aus.
Kann mir das jemand erklären oder ist das zufall das es jetzt
5x geklappt hat?
Druckerfarbe wird langsam knapp ;-)

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


[ Dieser Beitrag wurde von MaikG am 12.09.2008 um 18:07 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.09.2008, 16:32 Uhr

thomas
Posts: 7650
Nutzer

Wo ist denn das WaitIO zu dem SendIO ?

Warum benutzt du nicht DoIO wenn du eh nur auf den Drucker wartest ?

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

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

12.09.2008, 17:09 Uhr

MaikG
Posts: 5172
Nutzer
>Wo ist denn das WaitIO zu dem SendIO ?

Das hab ich mich auch gefragt, aber so ist das Beispiel.
Da ist nur das xWait drinnen.

>Warum benutzt du nicht DoIO wenn du eh nur auf den Drucker wartest ?

Weil ich das aus dem Beispiel habe.
Das ersetzen vom SendIO gegen DoIO hat den selben fehlerhaften
effekt.

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

Weiss nicht da steht das die Messages entfehrnt werden.
Vermutlich kommen da ggf. eine Reihe von Fehlermeldungen rein
die jedoch nicht weiter verarbeitet werden.

Sonst habe ich nur noch ein uralt Beispiel, da ist nur ein DOIO danach
CloseDevice. Allerdings wollte ich evtl. eine Abbruchmöglichkeit mit einbauen, da z.B. der Drucker manchmal das Blatt schräg einzieht.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2008, 17:47 Uhr

whose
Posts: 2156
Nutzer
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?
--
---

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


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

[ - Antworten - Zitieren - Direktlink - ]

12.09.2008, 18:13 Uhr

MaikG
Posts: 5172
Nutzer
>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?


Hab das Prog ergänzt.
MB glaub ich eigentlich nicht, weil ähnliche Konstuckte mit
anderen Devices funktionieren.

Optionen sind wie sonst auch, ist nicht so wie bei anderen Basic Compilern
das man sich durch Optimierungen den Code zerschiessen kann.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2008, 18:19 Uhr

Holger
Posts: 8038
Nutzer
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.

Wait() garantiert nicht, dass an dem zugehörigen MessagePort Nachrichten angekommen sind. Wer mit Wait() und GetMsg() hantiert, muss damit leben, dass Signale ankommen können, ohne dass Nachrichten vorliegen, oder dass für aufeinanderfolgende Nachrichten kein Signal ankommt.
Dementsprechend müsste man in dem geposteten Code auch sicherstellen, dass man mindestens die eine Nachricht bekommen hat, die das Ende der I/O-Operation signalisiert.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

12.09.2008, 18:46 Uhr

whose
Posts: 2156
Nutzer
@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 :dance3:

(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

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

12.09.2008, 18:49 Uhr

MaikG
Posts: 5172
Nutzer
>Dementsprechend müsste man in dem geposteten Code auch sicherstellen, >dass man mindestens die eine Nachricht bekommen hat, die das Ende der >I/O-Operation signalisiert.

Kann der beschriebene Fehler daher kommen?

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

[ - Antworten - Zitieren - Direktlink - ]

12.09.2008, 18:58 Uhr

whose
Posts: 2156
Nutzer
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.
--
---

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

[ - Antworten - Zitieren - Direktlink - ]

12.09.2008, 20:20 Uhr

MaikG
Posts: 5172
Nutzer
Geht leider nicht, fehler treten weiter auf. Auch das delay scheint nicht zuverlässig zu sein. So ein Mist.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2008, 22:06 Uhr

RhoSigma
Posts: 67
Nutzer
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 wird von vielen (hauptsächlich 3rd Party) Quellen & Beispielen auch so angegeben, da angeblich eine "enge" Schleife, die also ohne Zwischenstopps immer nur wieder GetMsg() aufruft bis eine Nachricht vorliegt (GetMsg() != NULL), angeblich auf 68060 CPUs Probleme bereitet (habsch leider nich, kanns also nicht bestätigen).

Was die Sache mit SendIO()/WaitIO() statt DoIO() angeht, so erklärt das sicherlich folgender Kommentar, zu finden hinter dem großen IF Block mit der ganzen POKE Geschichte:

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


[ - Antworten - Zitieren - Direktlink - ]

13.09.2008, 00:28 Uhr

whose
Posts: 2156
Nutzer
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.
--
---

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

[ - Antworten - Zitieren - Direktlink - ]

13.09.2008, 10:59 Uhr

MaikG
Posts: 5172
Nutzer
Ich dachte schon in Turboprint läuft ein Puffer über, also
habe ich das Bild in 2 hälften geteilt. Selber fehler.

Versteh ich nicht, muss die Höhe/Breite evtl. irgendwie durch 2 oder
4 Teilbar sein?

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Druckproblem [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1997-2019 by amiga-news.de - alle Rechte vorbehalten.
.