Hallo Hans-Juergen! Hans-Juergen Taenzer <[EMAIL PROTECTED]> schrieb:
>Ich hatte zun�chst versucht, in den Autoexec-Puffer zwei Nachrichten >einzuf�gen. Die erste Nachricht als Supersed der in XP stehenden >Nachricht, und die zweite Nachricht als wiederhergestellte >Originalnachricht (ohne Steuerheader). Nach dem Einlesen in XP gibt >es dann also drei Nachrichten mit der gleichen MID. Ich hatte >f�lschlicherweise erwartet, dass die Spam- und die >Supersedes-Nachricht auf l�schen gesetzt w�rden. Tats�chlich wurden >aber die Spam- und die zweite Nachricht des Autoexec-Puffers (die >wiederhergestellte Nachricht) auf l�schen gesetzt (kann ich auch so >leidlich in xp3io.inc nachvollziehen). Ich finde eigentlich seltsam, dass die Supersedes-Nachricht nicht auch auf l�schen gesetzt wird. Ich kann mich dunkel daran erinnern, dass schon mal Thema irgendwo gewesen ist. >Deine Idee oben mit der Cancel-Msg (STAT: CTL/oder vielleicht X-XP_F) >probier ich aus. Ich bef�rchte aber, dass auch hier alle Msg mit der >gleichen MID auf gel�scht gesetzt werden. Wie Du im Followup schreibst, funktioniert das erwartungsgem�� nicht. >Um das Auszuprobieren: wenn ich die (alten) Sourcen zum UUZ richtig >interpretiere, sind f�r eine Cancel-Msg zwei Header zu schreiben: >STAT: CTL und ein zweiter Header CONTROL: xxx. Wei�t Du vielleicht >wie das xxx in diesem Fall auszusehen hat? Du hast es ja wohl schon herausgefunden, aber IMHO m�sste der Header folgenderma�en aussehen: CONTROL: cancel MID >Stefan Vinke ([EMAIL PROTECTED]) wrote: >> Alternativ k�nnte man versuchen, die durch den Filter ver�nderte >> Nachricht durch die Originalnachricht mit hinzugef�gtem >> ERSETZT-Header zu, �hm, ersetzen. >Das ist jetzt auch mein Ansatz, der allerdings den Sch�nheitsfehler >hat, dass in der zweiten Nachricht (die mit dem ERSETZT-Header) der >ERSETZT- Header stehen bleibt. Das ist unsch�n, aber nicht so tragisch, oder? >Ich hatte noch die Idee, (f�r das Schreiben von zwei Nachrichten: >ERSETZT- und wiederhergestellte Nachricht) die zwei Nachrichten auf >zwei Autoexec- Puffer zu verteilen. In den ersten Puffer die >ERSETZT-Nachricht, und in den zweiten die wiederhergestellte >Nachricht. Das m�sste funktionieren, aber man kann sich bei den >verschiedenen XP-Derivaten wohl nicht darauf verlassen, dass der >Autoexec-Puffer mit der ERSETZT-Nachricht als erster eingelesen und >verarbeitet wird. Ich wei� gerade nicht, nach welchem Algorithmus die Reihenfolge der AUTOEXEC-Nachrichten bestimmt wird, aber vielleicht kann man herausfinden, ob es eine definiert Reihenfolge gibt und diese entsprechend ausnutzen. Was sicher funktioniert sollte, w�re eine zeitliche Trennung der Nachrichten. Wenn man es schaffte, erst den Cancel einzulesen und die "neue alte" Nachricht sp�ter (nach dem Einlesen) ins AUTOEXEC- Verzeichnis zu legen, sollte es klappen. Das scheint aber eine rein akademische �berlegung zu sein, denn ich w�sste nicht, wie man das realisieren k�nnte... MfG Stefan ------------------------------------------------------------------------ FreeXP Entwickler-Mailingliste [email protected] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
