Re: ZPR

maxfile Und damit aber nur innerhalb der CLIP gültig. Achso, der Implementationsteil ist ja lokal, dennoch sind die consts dort mit /V in ZPR als Symbol zu sehen und damit vermutlich als const eingebunden. Es ist und bleibt weiter rätselhaft. Tja, aber da wird man wohl nichts mehr machen

Re: ZPR

Martin Wodrich ([EMAIL PROTECTED]) schreibt: Das ist aber doch nur die über das Clipfile. Alle anderen CONST werden doch nur lokal in der CLIP deklariert. Die anderen drei sind unter Implementation: Multiplex cf_Oemtext maxfile -- Salut _)oachim

Re: ZPR

maxfile Und damit aber nur innerhalb der CLIP gültig. Achso, der Implementationsteil ist ja lokal, dennoch sind die consts dort mit /V in ZPR als Symbol zu sehen und damit vermutlich als const eingebunden. Es ist und bleibt weiter rätselhaft. -- Salut _)oachim

Re: ZPR

ZPR auch benutzt wird und daher zu diesem veränderten Verhalten führt. Da die Windows-Erkennung den Defekt verursacht und ich hier kein Windows habe und auch der ZPR darauf nicht angewiesen ist, hielt ich das für plausibel. Nochmal: Wenn der ZPR nicht darauf angewiesen ist (d.h., daß er die

Re: ZPR

ZPR auch benutzt wird und daher zu diesem veränderten Verhalten führt. Solange Du nicht eine Routine benennen kannst, sind Deine Aussagen nur leere Vermutungen. Es sind logische Schlußfolgerungen. Wenn keine solche Routine existiert, kann das pure Einbinden von clip.pas nach meinem Verständnis

Re: ZPR

Martin Wodrich ([EMAIL PROTECTED]) schreibt: ZPR benutzt die Routine die die Art eines Laufwerks zurückgibt nicht. -- IMO werden in ZPR.EXE - nur - die globalen deklarierten const aus der CLIP.PAS eingebunden. Der Compiler scheint also der Auffassung zu sein, daß die dem Programm bekannt

Re: ZPR

Martin Wodrich ([EMAIL PROTECTED]) schreibt: Es wurde in ZPR an keiner Stelle der Standard-I/O geöffnet. Und damit hätte es eigentlich immer nur eine Ausgabe auf dem Standardfehlerkanal geben dürfen. Ja, wenn dosx rausgenommen wird, war das schon etwas erstaunlich. Ich dachte mit dem Aufruf

Re: ZPR

Martin Wodrich ([EMAIL PROTECTED]) schreibt: Joachim Merkel [EMAIL PROTECTED] schrieb am 08.11.04 um 02:43: Wenn man diesen Aufruf unter ZPR deaktiviert, der lediglich als NOT OutputRedirected vorkommt, kann man uses dosx aus ZPR.PAS entfernen und die Umleitung geht wieder. QED Oder man

Re: ZPR

ich schrieb: [...] Ich dachte mit dem Aufruf not outputredirected ist die Umleitung aktiviert, aber für die Fortschrittsanzeige abgeschaltet. Hat sich hier eindeutig nicht bestätigt, ich hatte es nochmal mit DocForm ausüpobiert. [...] Man müßte mal die Register im Debugger überprüfen, ob da

Re: ZPR

Martin Wodrich [EMAIL PROTECTED] wrote on 06.11.04: Joachim Merkel [EMAIL PROTECTED] schrieb am 06.11.04 um 11:54: Also nochmal, bis Dosx.pas r1.19 geht die Umleitung, mit r1.22 nicht mehr. Die dazwischen habe ich nicht getestet, weil die ja buggy sind. Du brauchst das auch nicht weiter zu

Re: ZPR

Michael Heydekamp ([EMAIL PROTECTED]) schreibt: Martin Wodrich [EMAIL PROTECTED] wrote on 06.11.04: Joachim Merkel [EMAIL PROTECTED] schrieb am 06.11.04 um 11:54: Also nochmal, bis Dosx.pas r1.19 geht die Umleitung, mit r1.22 nicht mehr. Die dazwischen habe ich nicht getestet, weil die ja

Re: ZPR

Michael Heydekamp ([EMAIL PROTECTED]) schreibt: Wenn das Einbinden von clip.pas aber tatsächlich zu einer Änderung des Verhaltens führt, habe ich im Moment keine andere Erklärung dafür, als daß sich dort eine Routine befinden muß, die von ZPR auch benutzt wird und daher zu diesem veränderten

Re: ZPR

Martin Wodrich ([EMAIL PROTECTED]) schreibt: Joachim Merkel [EMAIL PROTECTED] schrieb am 05.11.04 um 21:42: Eine Verschlechterung beim ZPR der v3.40 IMO seit der snapshot vom 31.8.2003 ist, daß die Umleitung mit hier nicht mehr funktioniert (beim Backport der v3.21 geht das auch noch.) Die

Re: ZPR

Logfile steht jedoch Dosx.pas 1.22 bei der snapshot - ich sehe gerade, bei mir im Arbeitsverzeichnis ist das so, weil ich die Änderungen nicht mehr übernommen hatte. Wahrscheinlich, weil der Windows-Kram hier keine Rolle spielt. Daher habe ich immer eine funktionierende Umleitung mit dem ZPR gehabt

ZPR (was: Crosppoint 16bit auf Windows XP 64bit) (was: Crosppoint 16bit auf Windows XP 64bit)

X-Header nicht erkannt werden. Da steht immer am Anfang mehrere U-Received etc. Wenn der LEN:-Header nicht stimmt, verpasst ZPR immer den Headeranfang und das zieht sich unter Umständen durch den gesamten Puffer ab dem Fehler. Daher war meine Überlegung, zunächst per Kommandozeile den Header zur