Ich versuche grad einen IOWarrier24 mittles VB6 zum laufen zu bekommen.
Eigentlich wollte ich in der ersten Ausbaustufe nur mal schnell den Status eines einzelnen Schalters abfragen. In weiteren Ausbaustufen sollte dann auch noch ein LCD Display angeschlossen werden.
Aber leider scheint hier nichts zusammenzupassen.
Die VB-Beispiele des SDK funktionieren durch die Bank nicht.
Teils sind sogar die Deklarationen definitiv falsch.
So heißt es in der iow.bas
Public Declare Function IowKitGetProductId _
Lib "iowkit" _
() _
As Long
Das ist aber definitiv falsch und führt zum Laufzeitfehler 49 (Falsche DLL Aufrufkonvention)
Richtig muß es wohl heißen:
Public Declare Function IowKitGetProductId _
Lib "iowkit" _
(ByVal iowHandle As Long) _
As Long
Auch das Beispiel IOWSAMPLE.VBP funktioniert so überhaupt nicht!
Hier lautet z.B. die Funktion
Private Sub ReadButton_Click()
Dim Res As Long
' Perform a read
' Don't forget that we read report ID too
' So we have 5 bytes buffer In der Doku sind's aber acht!!!
' Turn off all LEDs
' Unmask all input lines
' first byte is report ID
data(0) = &O0 Laut Doku aber FF
' first report byte
.....
' Write to IO-Warrior
nWritten = IowKitWrite(iowHandles(0), 0, data(0), 5) 0 ist falsch laut Doku
' Handle error
If (nWritten <> 5) Then ' das wird immer falsch sein (entweder sinds 8 oder 0)
' You can use GetLastError() to get error code
MsgBox "Can not set input mask!", 0, "Error"
Exit Sub
End If
' After this write, all input lines are unmasked
' Set caption
ReadLabel.Caption = "Reading from IOW"
ReadLabel.Refresh
' Read from IO-Warrior
Res = IowKitRead(iowHandles(0), 0, data(0), 5)
' Check results
If (Res <> 5) Then
ReadLabel.Caption = "Read from IOW wrong?"
Else
...
End If
End Sub
Das geht nicht und kann auch nie und nimmer funktionieren!
Es kommt auch sofort der Fehler "Can not set input mask!"
Das ist wohl auch logisch denn in der (verdammt spärlichen) Dokumentation heißt es: To get the port status just send a report with ID
$FF to interface 1:
Hier wird aber mit data(0) = &O0 versucht Interface 0 anzusprechen.
Interface 0 gibt es aber anscheinend gar nicht, denn bei der Deklaration von IoKitWrite heißt es " numPipe - Number of interface to write to (ranges from 1 to number) also nichts mit 0.
Und so setzen sich die Fehler durch alle Bereiche und Deklarationen durch. Die VB-Beispiele paßen überhaupt irgendwie überhaupt nicht zur iowkit.dll. Hier funktioniert nichts aber auch gar nichts.
Der IOWarrior24 hingegen funktioniert, denn wenn ich die Datei ioblink.exe ausführe bekomme ich den Status des Schalters wie gewünscht zurückgeliefert.
Bitte dringend um Hilfe!
Wie kann ich unter VB6 den Status eines Schalters am IOW24 abfragen!
Dabei sollte die Abfrage auch nicht solange hängen bleiben bis sich der Status des IOW tatsächlich ändert.
Grüße
Erich
VB Beispiele zum IOWarrior24 funktionieren nicht!
Moderator: Guido Körber
-
Guido Körber
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Also erst mal: Die Beispiele funktionieren.
Was die angeblichen Diskrepanzen zur Doku betrifft, so würde ich noch mal langsames und aufmerksames Durchlesen empfehlen, hier sind offensichtlich viele Dinge noch nicht oder falsch verstanden worden.
Interface 0 (= Pipe 0), also das für den direkten Zugriff auf die Portpins, benutzt so viele Bytes wie beim jeweiligen IO-Warrior für die Portpins notwendig sind. Windows verlangt dann immer noch ein zusätzliches 0 Byte vorne weg als ReportID, auch wenn das Interface gar keine ReportID verwendet. Daher ergeben sich für den IOW40 5 Bytes und für IOW24 3 Bytes.
Was die angeblichen Diskrepanzen zur Doku betrifft, so würde ich noch mal langsames und aufmerksames Durchlesen empfehlen, hier sind offensichtlich viele Dinge noch nicht oder falsch verstanden worden.
Interface 0 (= Pipe 0), also das für den direkten Zugriff auf die Portpins, benutzt so viele Bytes wie beim jeweiligen IO-Warrior für die Portpins notwendig sind. Windows verlangt dann immer noch ein zusätzliches 0 Byte vorne weg als ReportID, auch wenn das Interface gar keine ReportID verwendet. Daher ergeben sich für den IOW40 5 Bytes und für IOW24 3 Bytes.
Sorry!
Aber wenn die Beispiele funktionieren, warum funktioniert dann bei mir nicht mal die bereits fertig kompilierte Datei IOWSAMPLE.EXE?
Wenn ich den Wert aber auf 1 und die Anzahl der Bytes auf 8 erhöhe, dann funktionierts plötzlich
Zudem wird in den VB-Beispielen nicht zwischen IOW24 und IOW40 unterschieden. Ich habe keinen Hinweis darauf gefunden, ob die Beispiele für den IOW24 oder IOW40 sind.
Zudem bleibe ich bei der Behauptung, daß die Deklaration
Public Declare Function IowKitGetProductId _
Lib "iowkit" _
() _
As Long
Definitiv falsch ist und zum Laufzeitfehler 49 (Falsche DLL Aufrufkonvention) führt
Richtig muß es wohl heißen:
Public Declare Function IowKitGetProductId _
Lib "iowkit" _
(ByVal iowHandle As Long) _
As Long
Damit funktioniert es! Was hab ich da falsch verstanden?
Und wenn in der Bemerkung zur Deklaration steht, daß der Wert für das Interface Größer gleich 1 sein soll. Warum soll ich dann woanderst nachlesen, ob das wirklich stimmt?
Grüße
Erich Freibert
Sorry! Ich habe meinem Kunden empfohlen den IOWarrior für ein Projekt einzusetzen.
Wenn ich gewußt hätte, daß die Dokumentation und die Beispiele in VB derart lau sind, hätte ich dies nicht getan. Die Zeit, welche ich gebraucht habe durch Trail and Error die Fehler in den Beispielen (oder sind die eventuell gar nicht für den IOW24???) zu beseitigen bzw. un- bzw. kaum dokumentierte Funktionen mühsehlig aus den C-Beispielen herauszupfriemeln, zahlt mir leider keiner. Das war Lehrgeld für mich.
Aber wenn die Beispiele funktionieren, warum funktioniert dann bei mir nicht mal die bereits fertig kompilierte Datei IOWSAMPLE.EXE?
Wenn ich den Wert aber auf 1 und die Anzahl der Bytes auf 8 erhöhe, dann funktionierts plötzlich
Zudem wird in den VB-Beispielen nicht zwischen IOW24 und IOW40 unterschieden. Ich habe keinen Hinweis darauf gefunden, ob die Beispiele für den IOW24 oder IOW40 sind.
Zudem bleibe ich bei der Behauptung, daß die Deklaration
Public Declare Function IowKitGetProductId _
Lib "iowkit" _
() _
As Long
Definitiv falsch ist und zum Laufzeitfehler 49 (Falsche DLL Aufrufkonvention) führt
Richtig muß es wohl heißen:
Public Declare Function IowKitGetProductId _
Lib "iowkit" _
(ByVal iowHandle As Long) _
As Long
Damit funktioniert es! Was hab ich da falsch verstanden?
Und wenn in der Bemerkung zur Deklaration steht, daß der Wert für das Interface Größer gleich 1 sein soll. Warum soll ich dann woanderst nachlesen, ob das wirklich stimmt?
Grüße
Erich Freibert
Sorry! Ich habe meinem Kunden empfohlen den IOWarrior für ein Projekt einzusetzen.
Wenn ich gewußt hätte, daß die Dokumentation und die Beispiele in VB derart lau sind, hätte ich dies nicht getan. Die Zeit, welche ich gebraucht habe durch Trail and Error die Fehler in den Beispielen (oder sind die eventuell gar nicht für den IOW24???) zu beseitigen bzw. un- bzw. kaum dokumentierte Funktionen mühsehlig aus den C-Beispielen herauszupfriemeln, zahlt mir leider keiner. Das war Lehrgeld für mich.
-
Guido Körber
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Also VBsample ist leider momentan nur mit dem IOW40 lauffähig, aber definitiv nicht fehlerhaft. Das stand hier mal im Forum bevor ein netter Mensch seine Miderwertigkeitskomplexe damit kompensieren musste uns das Forum zu zerstören...
Die anderen VB Beispiele sind mit IOW40 und IOW24 lauffähig, da IIC und LCD über das zweite Interface gehen und da das Datenformat einheitlich ist, da ja die Special Mode Functions eine Abstraktion von den einfachen IO-Pins sind.
Wie die einzelnen Funktionen aufzurufen sind ist in "iowkitreadme.txt" beschrieben, die Syntax da ist allerdings C, die DLL ist nun mal nicht für eine einzelne Sprache.
Was die Bemerkung über den Wert für numPipe betrifft, so ist der anscheinend falsch, das müssen wir mal ändern. In der Doku steht es auf jeden Fall korrekt drin.
Die anderen VB Beispiele sind mit IOW40 und IOW24 lauffähig, da IIC und LCD über das zweite Interface gehen und da das Datenformat einheitlich ist, da ja die Special Mode Functions eine Abstraktion von den einfachen IO-Pins sind.
Wie die einzelnen Funktionen aufzurufen sind ist in "iowkitreadme.txt" beschrieben, die Syntax da ist allerdings C, die DLL ist nun mal nicht für eine einzelne Sprache.
Was die Bemerkung über den Wert für numPipe betrifft, so ist der anscheinend falsch, das müssen wir mal ändern. In der Doku steht es auf jeden Fall korrekt drin.
Also sorry!
Aber da wir eine Software mit dem IO-Warrior 24 Starterkit mitgeliefert, welche nur mit dem IO-Warrior 40 lauffähig ist und dann wird auf nicht mehr vorhandene Forumsbeiträge verwiesen?
Wohin darf ich die Rechung für einige Stunden Fehlersuche hinschicken?
Warum gehen Sie eigentlich nicht auf die fehlerhafte Funktion ein?
Hier ist übrigens noch mal ein Fehler enthalten. Die Funktion liefert keinen long sondern einen integer zurück USHORT in C ist gleich integer in VB nicht long!
Also:
Public Declare Function IowKitGetProductId _
Lib "iowkit" _
(ByVal iowHandle As Long) _
As Integer
und nicht wie in der beigestellten iow.bas
Public Declare Function IowKitGetProductId _
Lib "iowkit" _
() _
As Long
Das kann -insbesondere ohne den iowHandle - noch nie funktioniert haben.
Hier wird vollmundig auf "einfachen Zugriff von vielen Programmiersprachen" mit "Beispiele für C++, VisualBasic™ und Delphi sind im SDK enthalten" hingewiesen und dann scheint diese Funktionen zumindest in VB noch niemand vollständig getestet zu haben und auch die Funktionsbeschreibung (iowkitreadme.txt) umfaßt nur C.
Daß die Funktionsbeschreibung in der iowkit.h mit
// Async events handling
BOOLEAN IOWKIT_API
IowKitRegisterMsgCallback(IOWKIT_HANDLE iowHandle, HWND hWnd, UINT Msg);
BOOLEAN IOWKIT_API
IowKitRegisterMsgCallback(IOWKIT_HANDLE iowHandle, HWND hWnd, UINT Msg);
zweimal dieselbe Funktion beinhaltet aber dafür keine um den Callback wieder zu deregistrieren, sei hier auch noch nur am Rande erwähnt.
Gruß
EF
Aber da wir eine Software mit dem IO-Warrior 24 Starterkit mitgeliefert, welche nur mit dem IO-Warrior 40 lauffähig ist und dann wird auf nicht mehr vorhandene Forumsbeiträge verwiesen?
Wohin darf ich die Rechung für einige Stunden Fehlersuche hinschicken?
Warum gehen Sie eigentlich nicht auf die fehlerhafte Funktion ein?
Hier ist übrigens noch mal ein Fehler enthalten. Die Funktion liefert keinen long sondern einen integer zurück USHORT in C ist gleich integer in VB nicht long!
Also:
Public Declare Function IowKitGetProductId _
Lib "iowkit" _
(ByVal iowHandle As Long) _
As Integer
und nicht wie in der beigestellten iow.bas
Public Declare Function IowKitGetProductId _
Lib "iowkit" _
() _
As Long
Das kann -insbesondere ohne den iowHandle - noch nie funktioniert haben.
Hier wird vollmundig auf "einfachen Zugriff von vielen Programmiersprachen" mit "Beispiele für C++, VisualBasic™ und Delphi sind im SDK enthalten" hingewiesen und dann scheint diese Funktionen zumindest in VB noch niemand vollständig getestet zu haben und auch die Funktionsbeschreibung (iowkitreadme.txt) umfaßt nur C.
Daß die Funktionsbeschreibung in der iowkit.h mit
// Async events handling
BOOLEAN IOWKIT_API
IowKitRegisterMsgCallback(IOWKIT_HANDLE iowHandle, HWND hWnd, UINT Msg);
BOOLEAN IOWKIT_API
IowKitRegisterMsgCallback(IOWKIT_HANDLE iowHandle, HWND hWnd, UINT Msg);
zweimal dieselbe Funktion beinhaltet aber dafür keine um den Callback wieder zu deregistrieren, sei hier auch noch nur am Rande erwähnt.
Gruß
EF
Ach ja noch was!
Wenn man sich beim genannten Beispiel etwas Mühe gemacht hätte, dann hätte man mit der falsch deklarierten Funktion eine einfache Abfrage ob IOW40 oder IOW24 einbauen können. Dann hätte man zum einen festgestellt, daß die Deklaration fehlerhaft ist und hätte zum anderen keine Kunden, welche einen IOW24 einsetzen in die Irre geführt.
Warum man dann einen Kunden (zbr147), welcher das Problem anspricht offensichtlich eine PN/E-Mail oder was auch immer zukommen läßt, aber die Antwort nicht ins Forum einträgt ist mir schleierhaft. Ich muß von meiner Arbeit leben.
Insbesondere, da die Information, daß man bei der Einfachen Abfrage mit Interface 0 und mit unterschiedlicher Anzahl von Bytes arbeiten muß gut im Text versteckt ist (im Datasheet), dann aber die Special Mode Functions, sauber und ausführlich einschließlich einer Tabelle beschrieben sind.
Gruß
Erich
Wenn man sich beim genannten Beispiel etwas Mühe gemacht hätte, dann hätte man mit der falsch deklarierten Funktion eine einfache Abfrage ob IOW40 oder IOW24 einbauen können. Dann hätte man zum einen festgestellt, daß die Deklaration fehlerhaft ist und hätte zum anderen keine Kunden, welche einen IOW24 einsetzen in die Irre geführt.
Warum man dann einen Kunden (zbr147), welcher das Problem anspricht offensichtlich eine PN/E-Mail oder was auch immer zukommen läßt, aber die Antwort nicht ins Forum einträgt ist mir schleierhaft.
Hätte auch mir einige Stunden Arbeit erspart. aber nichts "Laughing"Nun gehts ! Aber es wäre noch besser wenn in den SDK Beispielen auch noch dran stehen würde ob das Beispiel für den IOW40 oder IOW24 gedacht ist.
Hätte mir einiges an suche erspart . Laughing
Ich muß von meiner Arbeit leben.Insbesondere, da die Information, daß man bei der Einfachen Abfrage mit Interface 0 und mit unterschiedlicher Anzahl von Bytes arbeiten muß gut im Text versteckt ist (im Datasheet), dann aber die Special Mode Functions, sauber und ausführlich einschließlich einer Tabelle beschrieben sind.
Gruß
Erich
-
Guido Körber
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Also die Meckerei reicht mir jetzt, wenn sich der Tonfall nicht bessert lösche ich diesen Thread.
Der Sinn dieses Forums ist es bei Problemen zu helfen und die Lösungen dafür allen zugänglich zu machen. Daher ist so ein Vorwurf wie der, dass wir heimlich einzelnen Forumsmitgliedern Antworten per Email oder PM liefern würden lächerlich. Abgesehen davon habe ich die offensichtlich von dem Forumsteilnehmer selbst gefundene Antwort auch noch mal in den entsprechenden Thread geschrieben.
Die Informationen sind durchaus nicht in der Dokumentation versteckt und die Sektion über die Special Mode Functions ist natürlich auffälliger, da wegen der höheren Komplexität deutlich länger.
Die Hierarchie der Dokumentation ist auch logisch, sofern man nicht davon ausgeht, dass man die einzige relevante Programmiersprache auf dem einzig relevanten Betriebssystem benutzt. Alle den Chip betreffenden Informationen sind im Datenblatt, damit nicht alles drei mal wiederholt wird. Die Informationen zur jeweiligen Library stehen bei der Library im SDK. Sourcecode und .h Files sind keine Dokumentation und die Beschreibung der Funktionen ist selbstverständlich in C Syntax, da dies nun mal sowas wie der kleinste gemeinsame Nenner ist.
Undokumentierte Funktionen zu benutzen ist übrigens wie überall auf eigene Gefahr, im Falle der Callback Funktionen sogar mit Nichtfunktionsgarantie, da diese noch nicht fertig sind und nur wegen eines notwendigen Bugfixes mit in die Auslieferungsversion gekommen sind.
Sollten noch konstruktive Fragen sein werde ich mich gerne bemühen diese zu beantworten.
Der Sinn dieses Forums ist es bei Problemen zu helfen und die Lösungen dafür allen zugänglich zu machen. Daher ist so ein Vorwurf wie der, dass wir heimlich einzelnen Forumsmitgliedern Antworten per Email oder PM liefern würden lächerlich. Abgesehen davon habe ich die offensichtlich von dem Forumsteilnehmer selbst gefundene Antwort auch noch mal in den entsprechenden Thread geschrieben.
Die Informationen sind durchaus nicht in der Dokumentation versteckt und die Sektion über die Special Mode Functions ist natürlich auffälliger, da wegen der höheren Komplexität deutlich länger.
Die Hierarchie der Dokumentation ist auch logisch, sofern man nicht davon ausgeht, dass man die einzige relevante Programmiersprache auf dem einzig relevanten Betriebssystem benutzt. Alle den Chip betreffenden Informationen sind im Datenblatt, damit nicht alles drei mal wiederholt wird. Die Informationen zur jeweiligen Library stehen bei der Library im SDK. Sourcecode und .h Files sind keine Dokumentation und die Beschreibung der Funktionen ist selbstverständlich in C Syntax, da dies nun mal sowas wie der kleinste gemeinsame Nenner ist.
Undokumentierte Funktionen zu benutzen ist übrigens wie überall auf eigene Gefahr, im Falle der Callback Funktionen sogar mit Nichtfunktionsgarantie, da diese noch nicht fertig sind und nur wegen eines notwendigen Bugfixes mit in die Auslieferungsversion gekommen sind.
Sollten noch konstruktive Fragen sein werde ich mich gerne bemühen diese zu beantworten.
-
Robert Marquardt
- Posts: 543
- Joined: Mon Dec 01, 2003 6:09 pm
Ist Guido Kröber gleich Robert Marquardt??? Seltsam! Bringt man so Leben ins Forum?
Wenn nicht:
Sie können den Thread gerne löschen, dann suchen sich halt noch weitere Kunden zu Tode.
Sie wären übrigens der erste, der einen Streit mit einem Kunden gewonnnen hat. Dann verkaufen Sie halt die 80 bis 120 IOWs weniger, welcher mein Kunde so in etwa im Jahr einsetzen wird. Ist nicht die Welt ich weiß.
Und ich habe auch gemeckert, aber ich bin nicht persönlich geworden, ich habe nur das Produkt bemängelt und wie ich meine zu Recht.
Darf man eigentlich nicht mehr erwarten, daß wenn man etwas kauft dieses auch funktioniert und man nicht in den Tiefen eines Web-Forums danach suchen darf, warum "Das Programm funktioniert" ... aber eben nicht mit der Hardware, welche damit verkauft wurde.
Sorry, ich habe mit der Integration einer Pipifax-Funktionalität mein WE verbracht. Eine Funktion, welche ich mit vernünftiger Beispielsoftware und Dokumentation in zwei Stunden verwirklicht hätte. Die zusätzlichen Stunden bezahlt mir niemand. Wundern Sie sich da, wenn ich sauer bin?
Gruß
Erich
Wenn nicht:
Sie können den Thread gerne löschen, dann suchen sich halt noch weitere Kunden zu Tode.
Sie wären übrigens der erste, der einen Streit mit einem Kunden gewonnnen hat. Dann verkaufen Sie halt die 80 bis 120 IOWs weniger, welcher mein Kunde so in etwa im Jahr einsetzen wird. Ist nicht die Welt ich weiß.
Und ich habe auch gemeckert, aber ich bin nicht persönlich geworden, ich habe nur das Produkt bemängelt und wie ich meine zu Recht.
Darf man eigentlich nicht mehr erwarten, daß wenn man etwas kauft dieses auch funktioniert und man nicht in den Tiefen eines Web-Forums danach suchen darf, warum "Das Programm funktioniert" ... aber eben nicht mit der Hardware, welche damit verkauft wurde.
Sorry, ich habe mit der Integration einer Pipifax-Funktionalität mein WE verbracht. Eine Funktion, welche ich mit vernünftiger Beispielsoftware und Dokumentation in zwei Stunden verwirklicht hätte. Die zusätzlichen Stunden bezahlt mir niemand. Wundern Sie sich da, wenn ich sauer bin?
Gruß
Erich
-
Guido Körber
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
-
orange-blue
- Posts: 28
- Joined: Wed Feb 23, 2005 5:26 pm
-
Guido Körber
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Bei:
IowKitWrite(iowHandle, 0, data(0), 5)
(oder halt IowKitRead) die 5 durch eine 3 ersetzen. Der IOW24 hat halt nur 16 I/O Pins und damit nur zwei Bytes an Nutzdaten, das zusätzliche Byte drückt uns Windows auf als ReportID, die jedoch bei diesem Interface garnicht vorhanden ist, Windows mags aber so.
IowKitWrite(iowHandle, 0, data(0), 5)
(oder halt IowKitRead) die 5 durch eine 3 ersetzen. Der IOW24 hat halt nur 16 I/O Pins und damit nur zwei Bytes an Nutzdaten, das zusätzliche Byte drückt uns Windows auf als ReportID, die jedoch bei diesem Interface garnicht vorhanden ist, Windows mags aber so.
Zum Thema PN
Also jetzt muss ich auch mal was dazu sagen,
wenn schon jemand mit meinem Namen spricht.
Eine PN oder E-mail Hilfe hatte ich nie erhalten , das einzige was mir geholfen
hatte war :
ein kleiner Anruf bei Herrn Körber der mich nur ein wenig darauf aufmerksam machte das ich beim IOW24 nur 3-Byte (24Bit) übergeben
kann und nicht 5-Byte.
Alles andere war nach ein wenig nachdenken klar.
Und tata alles ging. Zumindest kann ich nun 16 Magnetventile ansteuern und auslesen .
Wie ich nun IR oder sonstiges mache habe ich noch nicht probiert.
MFG zbr147
wenn schon jemand mit meinem Namen spricht.
Eine PN oder E-mail Hilfe hatte ich nie erhalten , das einzige was mir geholfen
hatte war :
ein kleiner Anruf bei Herrn Körber der mich nur ein wenig darauf aufmerksam machte das ich beim IOW24 nur 3-Byte (24Bit) übergeben
kann und nicht 5-Byte.
Alles andere war nach ein wenig nachdenken klar.
Und tata alles ging. Zumindest kann ich nun 16 Magnetventile ansteuern und auslesen .
Wie ich nun IR oder sonstiges mache habe ich noch nicht probiert.
MFG zbr147
-
orange-blue
- Posts: 28
- Joined: Wed Feb 23, 2005 5:26 pm
-
Guido Körber
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Nein, er hängt nicht sondern wartet auf Daten. So lange sich an keinem Eingang etwas ändert kommt auch kein Report und iowkitRead() blockiert. iowkitReadImmediate kehrt immer sofort zurück und gibt dann an ob die gelieferten Daten neu sind.orange-blue wrote:hmm wenn ich was auslesen will, hängt er sich auf(nicht nur das Beispiel sondern auch das ganze VB)... keine Ahnung wieso :?