Seite 2 von 3
Verfasst: 29.10.2008 21:57
von exit
Und schon wieder etwas gelernt
. Ich kann also diese Zeilen, die mir immer etwas "im Magen lagen", getrost entfernen. Durch das Delay von Anfang an gibt es nämlich einen hakeligen Programmstart.
Danke erstmal
Code: Alles auswählen
;Programmoberfläche schneller starten und Delay später einsetzen
If countdelay < 5
countdelay = countdelay + 1
EndIf
If countdelay >= 5
Delay (1) ; erst nach ein paar Durchläufen
EndIf
Verfasst: 29.10.2008 22:03
von X360 Andy
Kaeru Gaman hat geschrieben:probier mal WaitWindowEvent(10)
wartet maximal 10ms, rödelt aber trotzdem nicht pausenlos durch.
ansonsten kann ich so beim drübergucken auf die schnelle nichts entdecken, und testen geht ja nicht.
... das war halt vorher nicht klar...
als wir nach code gefragt haben, sind wir mangels Informationen davon ausgegangen, dass es lauffähig sein würde.
Also bei mir läuft er..... ( ohne Debuger )
Mit Debuger gehts nicht....
Ich musste "nur" folgende zeilen löschen ( die ja nur zur grafischen oberfläche gehören )
Code: Alles auswählen
PureCOLOR_SetGadgetColor(#Laenge, #PureCOLOR_SystemColor, $FF00)
PureCOLOR_SetGadgetColor(#Verschluss, #PureCOLOR_SystemColor, $FF00)
PureCOLOR_SetGadgetColor(#akt_Laenge, #PureCOLOR_SystemColor, $FFFF)
PureCOLOR_SetGadgetColor(#Toleranz, #PureCOLOR_SystemColor, $FF00)
PureCOLOR_SetGadgetColor(#Solllaenge, #PureCOLOR_SystemColor, $FF00)
Verfasst: 29.10.2008 22:05
von ts-soft
Den ganzen Dauerquatsch sollteste nur ausführen, wenn kein Event anliegt,
also Event = 0, desweiteren in eine Procedure packen, das ganze ist so ja
ziemlich unleserlich, obwohl ja noch nicht viel code.
Verfasst: 29.10.2008 22:11
von Kaeru Gaman
X360 Andy hat geschrieben:Also bei mir läuft er..... ( ohne Debuger )
das mag ja sein...
das bringt aber grad mal garnix, weil ich den scanner nicht am COM hab und nix testen kann.
also wird auch hier kein IMA verursacht, also kann ich hier auch nicht dem Bug auf die Spur steigen...
> Den ganzen Dauerquatsch sollteste nur ausführen, wenn kein Event anliegt,
> also Event = 0, desweiteren in eine Procedure packen, das ganze ist so ja
> ziemlich unleserlich, obwohl ja noch nicht viel code.
yo, find ich auch.
Verfasst: 29.10.2008 22:13
von exit
Es liegt wahrscheinlich am Code von PureForm oben. Das neue blabla$ wird nirgendo anders benutzt und eine Gadgetabfrage müsste doch zu jedem Zeitpunkt möglich sein oder?
Also mit blabla$ habe ich den gleichen Fehler.
Code: Alles auswählen
blabla$ = GetGadgetText(#scanner_rohdaten)
;scan_new$= GetGadgetText(#scanner_rohdaten)
Verfasst: 29.10.2008 22:17
von exit
@ TS-Soft
Es liegt später nie ein Event an. Maus, Tastatur sind nicht zugänglich. Das Programm wird nur über die Scannerabfrage bedient.
Verfasst: 29.10.2008 22:19
von ts-soft
exit hat geschrieben:@ TS-Soft
Es liegt später nie ein Event an. Maus, Tastatur sind nicht zugänglich. Das Programm wird nur über die Scannerabfrage bedient.
Doch, SetGadgetText, verschieben des Fensters usw., es liegen tausende
von Events an, glaube mir
Verfasst: 29.10.2008 22:23
von exit
Ich war bisher der Meinung, dass ein WindowsEvent "von aussen" ausgelöst wird, sprich Maus, Tastatur und Co.
Wenn SetGadgetText auch ein WindowEvent ist, sieht die Welt schon anders aus.
Verfasst: 29.10.2008 22:26
von ts-soft
Dabei wird unter Windos u.a. ein #WM_SETTEXT ausgelöst, aber nicht nur
der alleine
Verfasst: 29.10.2008 22:29
von Kaeru Gaman
tja ... so kann man sich irren.
so manche Set-Commands lösen mindestens ein Event aus.
das führt dazu, dass manche Interfaces pro Update ein paar Dutzend Events auslösen,
die per (Wait)WindowEvent ans OS weitergereicht werden müssen.
wenn bei diesen Abarbeitungs-Durchläufen neue Events erzeugt werden,
läuft irgendwann die Eventqueue über, ist ja klar.