TextGadget auslesen

[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

[X360 Andy]

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)

[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.

[Kaeru Gaman]

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.

[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)

[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.

[ts-soft]

@ 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

[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.

[ts-soft]

Dabei wird unter Windos u.a. ein #WM_SETTEXT ausgelöst, aber nicht nur
der alleine

[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.