Page 2 of 4
SerialLib Klasse für VO 2.8
Posted: Wed Jun 08, 2022 2:47 pm
by lagraf
Hallo Gerhard,
du hast Recht, die beiden Magnetkartenleser, wo der Absturz stattfindet, werden über Sockets angesprochen. Die beiden Waagen über ser. Schnittstellen. Das wurde mal von 4 ser. Schnittstellen umgestellt, hatte das noch immer so im Kopf.
Dann also so: Kann es daran liegen dass die Sockets mit VO 2.8 nicht funktionieren, weil der Kundenrechner noch ein XP Rechner ist?
SerialLib Klasse für VO 2.8
Posted: Thu Jun 09, 2022 9:42 am
by lagraf
Ich habe das Problem gefunden:
Code: Select all
CLASS dtaSocket INHERIT dtaSerial
EXPORT _oSocket AS CSocket
METHOD Setup(nIndex) CLASS dtaSocket
LOCAL t1 AS TParams
...
_t1 := MemAlloc(_SIZEOF(TParams))
RegisterKid(_t1, 1, FALSE)
_t1.MainDlg := PTR(_CAST, SELF)
pTask:=CreateVOThread(NULL, 0, @Logging(), _t1, 0, @nID) // Übergabe an Func Logging _t1 = dtaSocket
ACCESS oSocket CLASS dtaSocket
RETURN _oSocket
FUNCTION Logging(dwParam AS DWORD) AS INT PASCAL
LOCAL oDta AS dtaSocket
LOCAL t1 AS TParams
...
t1 := dwParam
oDta := OBJECT(_CAST,t1.MainDlg)
WHILE TRUE
oDta:oSocket:listen(1) // oDta:oSocket über ACCESS bringt Absturz
oDta:_oSocket:listen(1) // oDta:_oSocket über EXPORT Var funktioniert
Der Zugriff über ACCESS bringt das Prog zum Absturz, ich weiß allerdings nicht warum. Der direkte Zugriff über die EXPORT Variable funktioniert hingegen.
SerialLib Klasse für VO 2.8
Posted: Thu Jun 09, 2022 9:57 am
by ArneOrtlinghaus
Wenn der Kunde noch XP hat und das Programm sonst nicht testbar ist, dann würde ich sagen:
Keine einzige Änderung, die nicht unbedingt notwendig, also auch unbedingt mit der alten VO-Version weiterarbeiten.
Es werden Threads benutzt und die geben in Zusammenhang mit der GUI und vielen anderen Klassen unter Umständen Fehler in Zusammenhang mit dem Garbage Collector.
Das, was auch sehr gefährlich aussieht, ist das Casten von Objekten aus Pointerstrukturen. Die Frage ist immer, ob der Pointer immer noch auf das korrekte Objekt zeigt, nachdem der Garbage Collector gelaufen ist. Und beim Garbage Collector hat sich viel verändert von VO 2.7 auf VO 2.8 (meistens zum Positiven, aber es reichen hier kleine Veränderungen).
Ich selbst würde hier als erstes die Casts auf die Objekte ändern, indem ich ein globales Array mit Objekten anlegen würde und der Thread nur eine Nummer bekommt und dann aus dem globalen Array das richtige Objekt rausholen kann. Das ist zwar auch nicht schön, aber das verhindert, dass der Garbage Collector durcheinanderkommen kann.
In einem Thread darf es nichts geben, dass den Garbage Collector anstoßen kann. Oder als Ersatzlösung muss so viel dynamischer Speicher bei Programmstart reserviert werden, dass der Garbage Collector (hoffentlich) nicht während der Threadausführung anfängt zu laufen. Das kann man mit AppSetDynMem steuern mit ausreichend großen Werten.
Arne
SerialLib Klasse für VO 2.8
Posted: Thu Jun 09, 2022 10:07 am
by lagraf
Hallo Arne,
danke dir für die Infos! Die Fehlerursache habe ich inzwischen gefunden, hast du mein Posting 15min vor deinem gesehen?
Info über den Kunden:
Es handelt sich um eine weltweite Großfirma mit ca. 3000 Leuten nur an diesem einen Standort. Die haben auch in der nächsten Zeit (also wohl in den nächsten 2 Jahren) vor, den Rechner von XP auf neuere Hardware und OS umzustellen. Aber das ist dort ein Projekt für 4-5 Mann und mind. 2 Wochen Aufwand!
SerialLib Klasse für VO 2.8
Posted: Thu Jun 09, 2022 10:21 am
by ArneOrtlinghaus
Umso besser, dass es jetzt wieder läuft. Aber es läuft ja nur wegen einer kleinen Anpassung, die eigentlich ja nicht der Grund sein sollte.
Da kann man sich nur fragen, welche Bedeutung IT-Sicherheit und -Stabilität bei dem Kunden hat, wenn das dann ein wichtiges Produktivsystem ist.
Ich gebe zu, dass wir bei uns in unserer Entwicklungsabteilung bis Anfang letzten Jahres noch einen virtualisierten Windows Server 2003 hatten (entspricht ja der Windows XP-Zeit). Wir brauchten noch eine alte Datenbankversion aus Kompatibilitätszwecken, weil einige Kunden auch noch so alte Rechner hatten. Da unsere Programme jetzt nicht mehr mit der alten Datenbankversion zu betreiben waren, war automatisch Schluß, sobald sie auf eine aktuelle Programmversion umsteigen wollten.
Gruß
Arne
SerialLib Klasse für VO 2.8
Posted: Thu Jun 09, 2022 10:50 am
by g.bunzel@domonet.de
Hallo Franz,
gut, wenn es jetzt funktioniert.
Ich hätte so einen ACCESS mit 'Strong Typing' erstellt - evtl. macht das einen Unterschied.
ACCESS oSocket AS CSocket CLASS dtaSocket
RETURN SELF:_oSocket
Gruss
Gerhard
SerialLib Klasse für VO 2.8
Posted: Thu Jun 09, 2022 11:41 am
by lagraf
Arne: Ich muss dazu sagen, dass der Rechner nur lokal verwendet wird und nicht im Internet hängt. Aber bei so großen Firmen ist ein Umstieg, vor allem bei 24/7 Betrieb, nicht einfach. Da wollen/müssen viele Leute mitreden und koordiniert werden!
Gerhard: Ich habs mit Strongtyping getestet, aber stürzt auch damit ab.
Ich habe eine Software namens CardServer gefunden, welche die beiden Magnetkartenleser steuert und mit meinem Prog per Socket kommuniziert. Wenn ich die nicht hätte, würde ich beim Test gar nicht bis zu der ursprünglichen Fehlerposition kommen, sondern schon beim Connect scheitern. Gut wenn man auch 25 Jahre alte Software nicht wegwirft!
SerialLib Klasse für VO 2.8
Posted: Thu Jun 23, 2022 8:44 am
by lagraf
Aktueller Stand:
Damit der Kunde arbeiten kann, habe ich ihm die Software mit VO2.7 geändert und ausgeliefert. Ich würde aber interessehalber und um VO2.7 wegzubekommen die Software noch unter VO 2.8 zum Laufen bringen. Da ich aber die Hardware nicht habe, kann ich die Abläufe nicht testen.
Meine Idee zum Test ohne Hardware:
Die beiden Magnetkartenleser werden von einer Software namens crdreader verwaltet. Diese kommuniziert per Socket mit meinem Programm bidirektional. Meine Idee ist jetzt, mir aus dem EchoSrv einen eigenen crdreader zu machen, der mir die Zugriffe auf die Magnetkarten simuliert und die Antworten retourniert.
Dabei habe ich aber das Problem, dass ich die erste Anfrage an den EchoSrv absetzen kann, diese wird dort im Fenster angezeigt, aber jede weitere Anfrage bewirkt nichts mehr. Nachfolgend das Setup für den Thread gekürzt aufs Wesentliche und 2 Dummyanfragen:
Code: Select all
CLASS dtaSocket INHERIT dtaSerial
EXPORT _oSocket AS CSocket
PROTECT _t1 AS TParams
PROTECT _cIP AS STRING
PROTECT _nPort AS WORD
METHOD Setup(nIndex) CLASS dtaSocket
LOCAL nID AS DWORD
LOCAL pTask AS PTR
// Socket erstellen
_oSocket := CSocket{SOCK_STREAM}
_oSocket:Timeout:=100
IF _oSocket:connect(_cIP, _nPort)
// Thread starten für Listening
_lStop := FALSE
_t1 := MemAlloc(_SIZEOF(TParams))
RegisterKid(_t1, 1, FALSE)
_t1.MainDlg := PTR(_CAST, SELF)
pTask:=CreateVOThread(NULL, 0, @Logging(), _t1, 0, @nID)
CloseHandle(pTask)
// Nachricht senden
_oSocket:SendLine("INFO#1") // Kommt beim EchoSrv an, Antwort in Func Logging retour
_oSocket:SendLine("INFO#2") // Kommt nicht an
ENDIF
RETURN SELF
Was könnte das Problem sein, dass nur die erste Anfrage an den EchoSrv dort ankommt?
SerialLib Klasse für VO 2.8
Posted: Thu Jun 23, 2022 9:01 am
by ArneOrtlinghaus
Die serielle Schnittstelle ist extrem tückisch. Wenn dann noch Thread-Programmierung dazukommt, dann wird das noch schwieriger. Meiner Meinung nach müsstest du die Kommunkation mit externen Programmen wie Telnet machen. Es kommt natürlich auf das Protokoll an, wie oft sich Programm und Kartenleser Daten hin- und her- schicken.
Wenn das Programm so schwer zu testen ist, ist die Frage, warum du es auf VO 2.8 zum Laufen bringen willst. Im Grunde ist VO 2.8 auch ein Auslaufmodell.
Gruß
Arne
SerialLib Klasse für VO 2.8
Posted: Thu Jun 23, 2022 9:56 am
by lagraf
Hallo Arne,
die beiden seriellen Schnittstellen bedienen die Waagen, habe aber nichts mit dem Problem zu tun. Die beiden Magnetkartenleser werden über Sockets angesprochen: MeinProg <-> crdreader <-> Hardware. Und da gibt es anscheinend zwischen VO 2.7 und VO 2.8 Unterschiede. Eine Umstellung auf X# ist nicht möglich, der Kunde will das Prog solange laufen lassen, bis eine Alternative gefunden wird. Außerdem wird der Unterschied zwischen VO 2.7 und X# noch größer sein als der zwischen VO 2.7 und VO 2.8.
Alle meine Programme bei den Kunden laufen noch mit VO2.8 und daran wird sich nichts ändern, solange VO auf Windows funktioniert. Nur möchte ich wegen 1 einzigen App nicht noch VO 2.7 mitschleppen müssen.