Verhaltensweise beim Schließen einer Form

>gemacht, dass beim Schließen einer Form (eines Fensters),

Was den nun, Form oder Fenster, oder vielleicht was anderes?

>in dem Daten per RS232 ausgetauscht wurde,

Wie soll ich mir das vorstellen? Das Formster sendet Daten an eine RS232 
Schnittstelle, diese ist mit einer anderen RS232-Schnittstelle 
verbunden, welche ihre Daten wieder ans Formster sendet, so dass dieses 
mit sich selbst Daten austauschen kann?

>trotz ordnungsgemäßem Schließen des ComPorts eine '0' gesendet wird?
Welche Daten gesendet werden, ist unabhängig davon, ob das Schließen 
ordnungsgemäß durchgeführt wird. Denn beim Schließen ist der 
Datentransfer ja bereits erledigt. Stell dir mal vor, es gäbe keine '0' 
im Zeichensatz, na gut, könnte man durch den Buchstaben 'o' ersetzen, 
viele schreiben ja auch 2oo6 uns so.

>Der Effekt tritt bei einigen Rechnern
>mit WIN XP SP2 auf, bei Anderen mit demselben OS nicht.

Das zeigt die hervorragende Fehlertoleranz von WIN XP SP2. Dank des 
selbstlernenden OS werden problematische RS232-Form-Fenster direkt mit 
der MS-Datenbank abgeglichen, so daß weitere Fenster-Daten-Austausche 
wieder problemlos funktionieren.

Es ist also alles in Ordnung.

OK, war vielleicht 'n bischen oberflächlich.
Ich tausche Daten per MSComm - Steuerelement in einer Form mit einem 
externen Gerät aus.
Der Datenaustausch ist beendet.
Ich schließe die Form (unload Me).
An der RS232 (überwacht per Terminal an anderem Rechner) wird eine 
(dezimal, Hex) '0' empfangen.
Es sollte eigentlich NICHTS gesendet werden, der Code enhält nichts was 
das auslösen könnte.
Manche Rechner machen das, andere nicht, alle mit demselben OS.
Mein Problem war, dass das Gerät, mit dem kommuniziert wird, durch das 
zuviel gesendete Byte einen unkontrollierten Zustand annimmt und sich 
nicht mehr ansprechen lässt.

btw: '0' bezeichnet üblicherweise die ASCII-Kodierung der Ziffer 0. Du 
meinst aber wohl das tatsächliche Null-Zeichen, das mit '\0', 0x0 oder 
einfach 0 (ohne '') geschrieben wird.

Zu deinem Problem: Hat das Gerät keine Fehlererkennnung, um 
Übertragungsfehler zu bemerken und fehlerhafte/unvollständige Befehle 
zurückzuweisen? Vielleicht solltest du versuchen, das Protokoll robuster 
zu gestalten, wenn es über eine unzuverlässige Verbindung wie RS232 
übertragen wird.

Wenn dein Programm die RS232-Schnittstelle freigibt, gestattest du damit 
beliebigen anderen Programmen (Betriebssystem einschließlich) Zugriff 
darauf. Das heißt nach dem Schließen des Handles darf das Betriebssystem 
(AFAIK) ganz offiziell völlig beliebige Daten senden.

>Manche Rechner machen das, andere nicht, alle mit demselben OS.
Hast du gelesen, was ich schrieb? Wenn XP solche Fehler bemerkt, 
versucht es, das Problem zu beheben. Darum kann ein anderes Gerät 
anschließend anders reagieren.

>Mein Problem war, dass das Gerät, mit dem kommuniziert wird, durch das
>zuviel gesendete Byte einen unkontrollierten Zustand annimmt und sich
>nicht mehr ansprechen lässt.
Wie du schreibst, ist das dein persönliches Problem. Ein Gerät, das 
durch einen Datenstrom in einen unkontrollierten Zustand versetzt werden 
kann, ist ein Sicherheitsrisiko. Den Fehler bei VB oder XP zu suchen, 
heißt die Ursache zu ignorieren, denn diese Produkte sind äußerst 
ausgereift und bestimmt nicht der Grund.

OK, das Gerät habe ich selbst gebaut und der Fehler (dass 
unkontrollierte Zustände auftreten können) ist mittlerweile 'raus.
Das Ganze fiel aber erst nach 3 Jahren störungsfreiem Berieb auf, als 
der Rechner und das OS erneuert wurden. Mal abgesehen vom fehlerhaften 
Gerät das dranhing ist das meiner Meinung nach ein dicker Hund seitens 
Microsoft.
Wenn ich nicht ausdrücklich sage dass Daten gesendet werden sollen 
erwarte ich auch, dass keine kommen!
Die '0' hab' ich nur wegen der visualisierung so geschrieben, sorry, 
nächstes mal 0.

@ MS-VB Certified Expert:
wo liegt der Fehler wenn ich eine Form beende? Es besteht überhaupt kein 
Unterschied zu einem andern OS oder sonstwas. Da sollte auf der RS232 
überall dasselbe passieren.

>Mal abgesehen vom fehlerhaften Gerät das dranhing ist das meiner Meinung >nach 
ein dicker Hund seitens Microsoft.

Das ist schon ne üble Unterstellung.

>@ MS-VB Certified Expert:
>wo liegt der Fehler
Wie bitte? Du benutzt ein fehlerhaftes Gerät und ein fehlerhaftes 
Programm und fragst mich, wo de Fehler liegt, ohne einen Schaltplan oder 
Quellcodeausschnitte zu zeigen?

Du hattest ursprünglich gefragt, ob es evtl. an der Hardware liegt. Das 
ist ziemlich eindeutig der Fall. Und zwar an der Hardware, die deine 
Tastatur bedient.

>Du hattest ursprünglich gefragt, ob es evtl. an der Hardware liegt. Das
>ist ziemlich eindeutig der Fall. Und zwar an der Hardware, die deine
>Tastatur bedient.

Nu mach mal halblang!
Ich wollte nur wissen, ob jemand auch die Erfahrung gemacht hat, dass 
sich die serielle Schnittstelle selbstständig macht.
>Das ist schon ne üble Unterstellung.
Nee, ist Fakt.

Codebeispiele hier zu posten macht wenig Sinn, das Teil (Datenlogger) 
ist mittlerweise recht umfangreich und Codeschnipsel würden niemand 
wirklich etwas sagen. Aber wenn jemand Bock hat, sich in 2 Jahre Arbeit 
von 3 Personen einzulesen mach' ich das schon.

Wie gesagt: der Fehler ist 'raus! Wollte nur wissen warum XP 
selbstständig Bytes über RS232 ausgibt.

Ich bedanke mich bei allen für die Antworten, scheint wirklich an Bill 
G. zu liegen. Bleibt nix anderes übrig als darauf zu reagieren.

Darf ich dich an deine Bemerkung erinnern:
>OK, das Gerät habe ich selbst gebaut und der Fehler [...]
>ist mittlerweile 'raus.

Nun wiederholst du
>Wie gesagt: der Fehler ist 'raus!
Und schließlich
>Wollte nur wissen warum XP selbstständig Bytes über RS232 ausgibt.
Warum um alles auf der Welt willst du, nachdem du den Fehler an deinem 
Gerät behoben hast, nun XP in die Schuhe schieben, daß es den Fehler 
verursacht hätte? Da du außerdem behauptest, nicht in der Lage zu sein, 
die wesentlichen Angaben zu machen, die irgendwem eine Idee von deinem 
Problem vermitteln könnten, geselle ich dich jetzt einfach zu den 
anderen mir bekannten Trolls.

Nun gut,  MS-VB Certified Expert, dann merk' ich mir halt deinen Nick 
und ignorier' die Postings, du bist echt keine Hilfe hier!

NOCHMAL: ich wollte nur wissen, warum Windows selbsttätig die RS232 
bedient. Scheinbar weiß das keiner.

Ich klinke mich jedenfalls wegen der schlechten Stimmung hier aus.
Gut's Nächtle!

>NOCHMAL: ich wollte nur wissen, warum Windows selbsttätig die RS232
>bedient. Scheinbar weiß das keiner.

Weil das scheinbar eine unbegründete Behauptung deinerseits ist.

So ist es, ich habe auch oben geschrieben, dass ich das mit einem 
Terminalprogramm mittels zweitem Rechner festgestellt habe. Es ist nun 
mal definitiv so, dass der eine Rechner die Null sendet, der Andere 
nicht.
Könnte gut sein dass das mit Plug-and-play zu tun hat. Danke Karl Heinz, 
werde in der Richtung mal forschen. Vor 'nem Kunden steht man nach 3 
Jahren störungsfreiem Betrieb natürlich blöd da!

Bill G. die Schuld an allem zu geben ist einfach, löst dein Problem aber 
nicht
Ich denke du übersiehst einiges.
1. Möglichkeit:
Du sendest noch während du die Form schließt. (Senden dauert ne weile)
je nach Rechner geht das unterschiedlich schnell (das schliessen der 
Form)
und damit siehst du auf der anderen Seite was oder nicht.
potentielle Kandidaten zur suche sind alle Senderoutinen besonders in 
eventroutinen. Einfacher Test in der Form.Unload ? Routine als letztes 1 
Sekunde warten.
2. Möglichkeit
Die 0 die du bekommst, ist das ein Sendefehler oder wirklich ein 
Zeichen?
Je nach Einstellung der dcb kann ein Sendefehler durch ein anderes 
Zeichen vorzugsweise 0 ersetzt werden.
Test mit Oszi, seriellen Portlogger auf Senderseite oder "ordentlichem" 
Terminalprogramm z.B. Hterm auf Empfängerseite, das kann auch Fehler 
anzeigen.
3. Nochmalige Kontrolle aller Senderoutinen und Nachlesen in der MSDN 
und Microsoft Technet, im Internet findest du eine Menge Senderoutinen 
die äußerst fehlerhaft arbeiten, weil Leute nicht in der MSDN nachlesen 
oder es nicht verstehen.
4. Auf Sende und Empfangsseite das Handshaking überprüfen, nicht das 
hierdurch etwas blockiert wird und durch das "loslassen" des Ports diese 
blockierung sich löst.
5. Durch ein falsches Byte sollte ein Gerät niemals blockieren

Das sind die Sachen die du erstmal selbst machen könntest
6. serielle Mäuse werden nur am Anfang getestet, schau mal nach 
Activesync etc.
7. möglicherweise Fehler oder Feature von Bill, aber es gilt 5.

und auch auf die Gefahr hin das du dieses Posting auch ignorierst:
 MS-VB Certified Expert hat es vielleicht nicht sehr höflich ausgedrückt 
aber ich tippe auch darauf: zu 99% liegt der Fehler bei Dir.

Hm, ich habe drei Rechner nebeneinander stehen, alle dasselbe OS. Auf 
einem läuft zur Überwachung Hterm. Auf den zwei Anderen ist dieselbe SW 
installiert und deren Einstellungen sind identisch. Der eine Rechner 
schickt eine 0 (mit Hterm eingelesen) beim Schließen der Form, der 
Andere nicht. In der Form kann die Kommunikation schon 30 Minuten 
beendet sein, die 0 kommt trotzdem. Geöffnet ist die COM im Binary-Mode 
und nach der Kommunikation wieder geschlossen worden.
Ich will hier nicht die Schuld auf Windows schieben, auch wenn's so 
rübergekommen ist. Ich wundere mich nur dass der eine Rechner anders 
reagiert als der Andere.

>Hm, ich habe drei Rechner nebeneinander stehen, alle dasselbe OS.

Hast du auf allen drei die Festplatte formatiert, das OS installiert und 
zur gleichen Zeit die gleichen Programme in gleicher Abfolge gestartet?

Es reicht aus, dass irgendein Prozess auf einem Rechner einmal auf die 
serielle Schnittstelle zugreift, auf dem anderen aber nicht, damit sie 
hinterher unterschiedlich konfiguriert sind. Wenn dein Programm dann 
keine saubere Initialisierung vornimmt, verhalten sie sich eben 
unterschiedlich.

Auch das ist kein Problem von Windows. Wer bestimmte 
IO-Port-Eigenschaften braucht, muss diese halt setzen und nicht hoffen, 
dass der Port zufällig so arbeitet, wie es den Gedanken des 
Programmierers entspricht.

Ok jetzt kennt man den Versuchsaufbau,

>In der Form kann die Kommunikation schon 30 Minuten
>beendet sein, die 0 kommt trotzdem. Geöffnet ist die COM im Binary-Mode
>und nach der Kommunikation wieder geschlossen worden
unmittelbar nach der Kommunikation?
so richtig Port.Close und unload des Moduls?
Wenn dein Programm nicht sendet kannst du dann den COMPort mit einem 
anderen Programm öffnen?

In HTerm Fehler anzeigen aktiviert?
Was zeigt das Oszi?

Nunja, auf die restliche Konfiguration habe ich keinen Einfluss mehr, da 
es ein Kundenrechner ist. Wie gesagt, mittlerweile ist ein Blockieren 
des Gerätes nicht mehr möglich, wurde in der Firmware korrigiert und es 
läuft auch wieder wie's soll.
Das Portmon schau' ich mir mal an, auch mit dem Oszi werd' ich mal 
rangehen, evtl. 'erleuchtet' mich das dann ;-)
Erstaunlich ist halt, dass es drei Jahre lang keine Probleme gab, die 
tauchten erst mit XP SP2 und dem neuen Rechner auf. Vorher war's 
übrigens auch XP, aber ohne SP2.
Ich werde jedenfalls weiterforschen, auch meine SW nochmal genauer unter 
die Lupe nehmen.
Ich danke euch für die Beiträge und lass' es euch wissen wenn ich den 
Fehler gefunden habe!

@Wolfram:
Ja, unmittelbar nach der Kommunikation mit .portopen=False.
Kann grade leider nicht messen, habe das Oszi nicht zur Verfügung.
Hterm Fehler Anzeigen hatte ich noch nicht aktiviert, werd's aber 
testen.
der Port lässt sich nach der Kommunikation von anderen Programmen 
öffnen, ist ja schließlich geschlossen.

>Vorher war's übrigens auch XP, aber ohne SP2.

pruuust Und das nennst du das gleiche OS? Spätestens jetzt muss auch 
ich gratulieren. In diesem Zusammenhang ist dir das Unmögliche gelungen: 
du hast eine dumme Frage gestellt. Und auch gleich die Marke sehr hoch 
angesetzt, Respekt!

>*pruuust*
Den ganzen Thread gelesen? Offensichtlich nicht!
BEVOR das Problem auftrat war's XP ohne SP2.
Bitte erst lesen bevor man anderen an den Karren fährt!

> Wenn dein Programm die RS232-Schnittstelle freigibt, gestattest du
> damit beliebigen anderen Programmen (Betriebssystem einschließlich)
> Zugriff darauf. Das heißt nach dem Schließen des Handles darf
> das Betriebssystem (AFAIK) ganz offiziell völlig beliebige Daten
> senden.

Hast du diesen Absatz eigentlich gelesen? Der Fehler liegt ganz 
offensichtlich nicht auf der Seite von Windows.
Wenn du willst, dass die Schnittstelle ruhig bleibt, muss dein Programm 
sie eben belegen.

Das ist ja wie wenn du dich beschweren würdest "wenn ich einen 
Speicherblock mit free() freigebe, wie kann Windows dann einfach auf die 
Idee kommen darin rumzuschreiben? Bill ist daran Schuld, ganz klar!!1".

Ja, ist mir schon klar dass Windows dann drauf zugreifen darf. Nur frage 
ich mich eben: warum macht es das? Da sonst keine Applikationen laufen 
sollte eigentlich Ruhe herrschen, was bei den meisten Rechnern auch der 
Fall ist, die ich getestet habe (mittlerweile 12 Stück). Bei 3 von 12 
Rechnern kommt die Null beim Schließen der Form, beim Rest ist Ruhe. 
Also kann's nicht an meinem Programm liegen, das habe ich nochmal 
durchgeforstet, beim Schließen ist die COM zu und in der 'Unload' - 
Funktion wird sie auch nicht mehr angesprochen.
Sei's wie's ist: ich lebe damit.

> Ja, ist mir schon klar dass Windows dann drauf zugreifen darf.
> Nur frage ich mich eben: warum macht es das?
Ohne die Kompetenz dieses Forums in Frage stellen zu wollen schätze ich, 
dass du hier keine Antworten darauf erhalten wirst, die keine 
Mutmaßungen sind. Und zwar einfach aus dem Grund, weil das wohl nur ein 
Experte beantworten kann, der sich mit Windows-Treiberprogrammierung 
allgemein, bestimmten Treibern im speziellen usw. sehr gut auskennt.

> Da sonst keine Applikationen laufen sollte eigentlich
> Ruhe herrschen, [...]
Eben das ist eine unzulässige Annahme. Wenn du die Schnittstelle 
freigst, hat Windows volles Anrecht darauf und kann machen, was es will.

>hat Windows volles Anrecht darauf und kann machen, was es will.
Hab' ich jetzt auch berücksichtigt. Die ext. Hardware ist so abgesichert 
dass Windows das gerne machen kann.
Ich denke auch dass Windows und die Applikationen die drauf laufen 
mittlerweile so komplex sind, dass man fast keine Chance mehr hat 
solchen Sachen auf den Grund gehen zu können.