Hi Walter,

When this code is executed, my development system is fully hung!. there is no wait window and the VFP frame is static. I believe it has something to do with an environmental setting. When I run this program with a "clean" VFP6 I performs as advertised. However when the system is initialized to my "normal" settings by way of various SET commands the programs no longer responds. I will investigate and report my findings.


Glenn

>Hi glen,
>
>I'm not sure what is wrong. The code works perfectly on my Athlon 750, 128 MB.
>questions:
>1 - Do you see the seconds enumerating in the wait window at the upper right corner ?
>2 - Are you able to open the VFP menu and select the class browser ?
>
>Walter,
>
>
>>Hi Walter,
>>
>>I copied the code to and executed this test using VFP6.0 sp3 on a 900 mhz 256mb Antholon and it locks up tight! What do you think is wrong?
>>
>>Glenn
>>
>>>Hi glenn,
>>>
>>>Just copy and past the following code:
>>>
>>>

nStartSec=SECONDS()
>>>nReportSec=SECONDS()
>>>DO WHILE SECONDS() < nStartSec+60
>>>	IF CHRSAW() OR MDOWN()
>>>		DOEVENTS
>>>	ENDIF
>>>	IF SECONDS() - nReportSec > 1
>>>		nReportSec=SECONDS()
>>>		WAIT WINDOW STR(SECONDS()-nStartSec,5,2) NOWAIT
>>>	ENDIF
>>>ENDDO

>>>
>>>Save it (e.g. test.prg), and let the program file open on the VFP desktop. Now start it with: DO test
>>>
>>>You'll see a wait window in the upper right corner for every second, so the programm is busy. However you're able to move the program window, activate the menubar and start the debugger, class browser or other programs if you whish.
>>>
>>>Im not pretending it's perfect, but it's at least an interesting possibility.
>>>
>>>Walter,
>>>
>>>
>>>>Hi Walter,
>>>>
>>>>You mentioned you can start other processes using the code you proposed, It is not clear to me (early morning - no coffee) how that is accomplished. Could you please provide a simple example.
>>>>
>>>>Thanks
>>>>
>>>>Glenn
>>>>
>>>>>Hi ed,
>>>>>
>>>>>>>

IF CHRSAW() OR MDOWN()
>>>>>>>   DOEVENTS
>>>>>>>ENDIF

>>>>>>
>>>>>>Actually, I got this from Dave Frankenbach a while before you proposed it; it works in most cases. Another approach is to call the API to check all the Windows virtual keys using a buffer to detect changes:
>>>>>
>>>>>AFAIK, I was the first one who came to this solution, David proposed the fastdoevents with the help of moving the mouse which unfortunately has some side-effects and does not work in all cases.
>>>>>
>>>>>>

DECLARE SHORT GetKeyboardState IN USER32 STRING @ lpKeyState
>>>>>>cKeyboardAtRest = REPL(CHR(0),256)
>>>>>>cKeyboardStateNow = cKeyboardAtRest
>>>>>>=GetKeyboardState(@cKeyboardAtRest)
>>>>>>*
>>>>>>*  In loop
>>>>>>*
>>>>>>=GetKeyboardState(@cKeyboardStateNow)
>>>>>>IF cKeyboardStateNow # cKeyboardAtRest
>>>>>>   *  Something happened
>>>>>>   DOEVENTS
>>>>>>   =GetKeyboardState(@cKeyboardAtRest)
>>>>>>ENDIF

>>>>>>
>>>>>>I suspect it has less overhead than calling CHRSAW() and MDOWN() - it traps all the virtual keys, not just keystrokes that translate to characters; you can trap pressing Alt, Shift, Ctrl as well, down and up changes.
>>>>>
>>>>>Good tip! I'll look into this and will do some benchmarking and see if this from a performance point of view is a better solution.
>>>>>
>>>>>Walter,