| |
| |
|
E.T. | Kann es sein, das XProfan mit schneller Fastmode-Umschaltung nicht zurecht kommt ??
Wenn ich das folgende Beispiel-Proc einbaue, wirkt das unterschiedlich in Interpreter und Exe:
- Im Interpreter stürzt das Prog kommentarlos ab, wenn die (das ??) Proc schnell hintereinander aufgerufen wird
- In der Exe scheint das Programm öfters im Fastmode 0 zu bleiben, Redraw(...) wird nur sporadisch ausgeführt
KompilierenMarkierenSeparieren...
Proc CheckFarbe
ClearList SpeicherRot&
ClearList SpeicherGruen&
ClearList SpeicherBlau&
WhileLoop 0,@GetCount(DatBox&[2])
FarbCheck$ = @GetText$(DatBox&[2],&loop,0)
Case FarbCheck$ = @Date$(3) : @Addstring(SpeicherRot&,@str$(&loop))
EndWhile
set(fastmode,1)
~SetWindowLong(%hwnd,~GWL_WNDPROC,procaddr(FarbZeile,4))
Redraw(DatBox&[2])
set(fastmode,0)
~SetWindowLong(%hwnd,~GWL_WNDPROC,WndProc&)
EndProc
...
|
|
| |
| Grüße aus Sachsen... Mario  WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 11.02.2009 ▲ |
|
| |
|
|
E.T. | Eben nochmal ein wenig probiert:
Wenn man in die (das) Proc schnell genug hintereinander aufruft, bleibt das Programm irgendwann (wenn es nicht abstürzt) mit einer dicken Sanduhr und ~50% Prozessor-Auslastung stehen und lässt sich nur noch abschießen.
Meine erste Vermutung, das es auch am ~SetWindowLong... liegen könnte !
Aber da ich das Prog ja abschießen kann, ist es (lt. Hilfe) ja im Fastmode 0, also doch der Fastmode ?? 
Baue ich hinter das Redraw(...) ein sleep 1000 ein, läuft das Prog !!!
  
Edit
Oder verkackt sich doch diese blöde API, womit ich das Neuzeichnen der Gridbox verbiege ??
Je mehr ich probiere, umso mehr tendiere ich in diese Richtung... |
|
| |
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 11.02.2009 ▲ |
|
| |
|
(1.333)
Deutsch
English
Français
Español
Italia