WaitWindowEvent erhält nicht ausgelöste Events

[ts-soft]

Da es ja nur für Windows ist, hier ein Skeleton mit HighResTimer:

Code: Alles auswählen

 Define.TIMECAPS TimerResolution

Procedure Timer_Init()
  Shared TimerResolution

  If timeGetDevCaps_(@TimerResolution, SizeOf(TIMECAPS)) = #TIMERR_NOERROR
    If timeBeginPeriod_(TimerResolution\wPeriodMin) = #TIMERR_NOERROR
      ProcedureReturn #True
    EndIf
  EndIf
  ProcedureReturn #False
EndProcedure

Procedure Timer_End()
  Shared TimerResolution
  timeEndPeriod_(TimerResolution\wPeriodMin)
EndProcedure

Procedure TimerCallback(hWnd, uMsg, uEventID, dwTimer)
  If uEventID = 1
    ; hier der quatsch von case 0 rein, leicht angepaßt
  EndIf
EndProcedure

OpenWindow(0, #PB_Ignore, #PB_Ignore, 640, 480, "bla")

Timer_Init()
SetTimer_(WindowID(0), 1, 5, @TimerCallback())

Repeat
  ; hier nur fenster, menü und gadgetereignisse
  Select WaitWindowEvent()
    Case #PB_Event_CloseWindow
      Break
  EndSelect
ForEver

KillTimer_(WindowID(0), 1)
Timer_End()

Gruß
Thomas

[Kaeru Gaman]

Events:

brauchst du denn überhaupt ein Event auf deinem Ausgabe-Stringgadget?
also ein click drauf oder so?
wenn nicht ist es doch schnurz, ob dein Aktualisieren ein Event enthält, da du ja unterhalb von Case #PB_Event_Gadget sowieso noch mal nach Gadgetnummer entscheidest.
dass eine Eventschleife extra noch mal durchläuft um Events zu übergeben, die nicht dein Fenster sondern Windows verarbeiten muss, ist ganz normal und muss so sein.

falls du doch ein click auf dein Stringgadget verarbeiten musst, unterscheide nach EventType.


Daten:

wie kommen deine Daten denn an, sind das schon Hex-Strings, oder machst du die erst draus?
anhand dessen muss man entscheiden, was die beste Lösung ist.
wenn du Byte-Daten bekommst, speichere sie als unsigned byte (.a) und wandele sie erst für die Ausgabe in Hex-Strings.

achte auch auf den String-Typ, also ANSI (ASCII), UTF-8 oder UniCode.

[alDo]

Event:
Also ich brauche keinen Klick auf das StringGadget verarbeiten. Dann ist ja alles ganz normal. Gut so. Dacht nur ich hätte da einen Fehler, der mit der falschen Ausgabe zusammenhängt.

Daten:
Ich empfange theoretisch Daten im Range von 0 bis 255 (ASCII). Im Anwendungsfall z.B. 70 (=F) wird in eine 15 (dez.) umgewandelt und in einem Array vom Typ integer gespeichert. Ich benutze zwei Arrays dieser Art, um zwischen einem Highbyte und Lowbyte unterscheiden zu können. Beide werden in Hex-Strings umgewandelt und in einem String-Array zusammengefasst.
Z.B. siehts dann so aus:

Code: Alles auswählen

DatenByte(0) = "8F"
.
.
.
DatenByte(7) = "0D"

Dies geschieht alles in einer Prozedur. In dieser erfolgt ein Aufruf einer Prozedur, welche die Daten aus dem String-Array in einem anderen (von mehreren Möglichen) String-Array zwischenspeichert und der eingetroffene Datensatz ausgegeben wird.
Wenn ich nun auf einen Button klicke sollen in anderen StringGadgets die zwischengespeicherten Daten ausgegeben werden. Falls ich nun ein zweites Mal auf den Button klicke tritt bei manchen (meist Ersten beiden) Datenstringgadgets folgendes auf:
a) es werden die falschen Daten ausgegeben (teils kryptische Zeichen siehe vorige Posts) oder
b) der Leerstring wird ausgegeben oder
c) ein Teil des Datensatzes, der nicht zu den Datenbytes gehört wird ausgegeben (ähnlich gelagert wie Datenbytes jedoch aus 3 Zeichen bestehend z.B. "7A2")
Dabei lässt sich beobachten, dass in einer anderen Prozedur(zum handlen der Buttons) die beiden ersten Werte der Zwischengespeicherten Daten in der Debugger Ausgabe schon kryptisch sind.

@Kaeru
Falls du doch mal testen möchtest, besorg dir zwei von denen hier :
http://www.canusb.com/
und verbinde beide miteinander:
http://www.lindy.de/serieller-loopback- ... 60254.html
dazu noch ne nette Software zum Testen:
http://www.canhack.de/viewtopic.php?f=25&t=989
und schon kannste loslegen^^

[Kaeru Gaman]

versteh ich das richtig..
deine ankommenden Daten sind bereits Hex-Strings, also die Zahlen 0-9 (asc 48-57) und die Buchstaben A-F (asc 65-70) ?

ein Kernproblem liegt anscheinend in deiner Umwandlung, trenne Ursprungs- und Ziel-String auch namentlich,
damit du nicht fehlerhaftiger Weise einen bereits verarbeiteten String noch mal verarbeitest.
so klingt nämlich deine Beschreibung: wenn ich noch mal drauf klicke wirds kryptisch,
das heißt für mich, du jagst die selben Daten 2x durch den Wandler und beim zweiten Mal kommt Unsinn raus.

aber vorher noch mal, beantworte bitte erst die erste Frage, ich würde nämlich erst gerne mal verstehen was du überhaupt tust.

... und was das testen anbelangt, da wirst du dir dann wohl jemanden suchen müssen, der zufällig mit der selben Hardware rumspielt.

ich hatte dir schon mal geraten, dir extra-programme oder threads zu schreiben, die die Kommunikationsports simulieren,
dann können auch andere deine Progs testen und wirklich helfen und tipps geben.

[ts-soft]

Event:
Also ich brauche keinen Klick auf das StringGadget verarbeiten. Dann ist ja alles ganz normal. Gut so. Dacht nur ich hätte da einen Fehler, der mit der falschen Ausgabe zusammenhängt.

Aber Veränderungen am StringGadget sieht man erst, wenn Du nach einem SetGadgetState wieder im
EventLoop bist. Deshalb sollst Du dieses auch so gut wie nie verlassen. Nimm den von mir geposteten
Timer, der geht ab Win2K auf eine ms genau und Dein EventLoop ist entlastet und kann auch mal was
darstellen

[Kaeru Gaman]

halte ich für unnötig.

ein TimeOut bzw. AddWindowTimer ist dafür genauso geeignet.

man sollte allerdings das TimeOut von 10 auf 100 ms hochstellen,
hundert mal pro Sekunde checken ist schlicht Overkill, zehn mal lang völlig.
es geht hier nicht um die Frames eines Actiongames oder Timing bei nem Musikstück.

[ts-soft]

halte ich für unnötig.

Wie soll er sonst Daten im ms Takt lesen, wie er es benötigt?
Serielle Schnittstelle ist schon sehr schnell.
Der PB-Timer bleibt zudem noch stehen, wenns Fenster bewegt wird.
Mit dem API-Timer mit max. Genauigkeit umschifft er alle seine Probleme
im EventLoop, Windows nutzt das TimerCallBack direkt.
Der ganze Schnittstellenkram arbeitet fast als wäre er in einem Thread,
nur ohne die Fehlermöglichkeiten.

Jetzt muß er nur noch drauf achten, das der Timer nicht schneller als
seine Abarbeitung ist

Gruß
Thomas

[Kaeru Gaman]

achso, ok...
wenn der Empfang SO schnell sein kann, hast du natürlich recht.
dann sollte er aber den kompletten Empfang in einen Thread packen, der völlig getrennt von der Eventschleife läuft.
für die Übergabe würde sich ein Ringbuffer anbieten...

die Abarbeitung muss natürlich schnell genug sein,
aber den Buffer sollte man sowieso nicht Timer-Step-Weise sondern per Parity (oder wie diese Synchro heißt) gesteuert füllen.

[ts-soft]

dann sollte er aber den kompletten Empfang in einen Thread packen, der völlig getrennt von der Eventschleife läuft

Ins Timercallback sollte genügen, ansonsten wäre der Timer ja unnütz, wenn er einen Thread
erstellt.

[Kaeru Gaman]

yo timercallback sollte genügen.

dann könnte man auch ne LList oder ein Array nehmen, weil man dann ja nicht mutexen müßte, oder?
der Ringbuffer ist ja dafür, damit man sich den Mutex spart.