The plot thickens:
In my case I had something like the following scenario:
Code: Select all
100 ch% = FOPEN("con")
110 time% = -1: event% = 0
120 n% = CODE("n")
130 MDRAW #ch%,'win1_ptr_mem_Menu_men', 0, 0, 100, 60
140 REPeat ol
150 num=MCALLT(#ch%\ event%,time%)
160 k% = MKEY%(#ch%)
170 SELect ON k%
180 = n%: REMark 'n' was pressed
190 BEEP 2000, 100
200 event% = 511: REMark $1FF
210 time% = 25
220 :
230 REPeat il
240 num=MCALLT(#ch%,event%,time%)
250 BEEP 2000, 20
260 SELect ON num
270 = -1280: REMark Timeout/Events
280 BEEP 2000, 2: REMark PRINT #0,"X ";
290 = -1: EXIT il: REMark ESC pressed
300 END SELect
310 END REPeat il
320 :
330 = 27: EXIT ol
340 END SELect
350 END REPeat ol
360 MCLEAR #ch%: CLOSE
An outer loop with an MCALLT in it and an inner loop with another MCALLT.
The menu has a LI that returns -1 on ESC.
If you run this snippet (eg with SBAS/QD, or EX) then it should loop around in the outer loop waiting for a keypress.
Only ESC and 'n' are served. If you press ESC you exit the program
If you press 'n' you enter the inner loop with a low tone beep.
Then, every 1/4 second, in theory, it should beep with a high tone as it times out. But nothing will induce it to do so! (Except the standard MACLL returns like hitting a LI or AW).
Pressing ESC again causes the flow to pass back to the outer loop.
In this example, even an event (internally generated or external) wont trigger the inner MCALLT, and certainly no timeout value, -1, 0 or whatever.
Ive tried the above on the latest versions of ptrmen_cde on an otherwise empty SMSQ/E machine: It doesnt work.
In my real-world instance there are some other things going on, and the SEND_EVENT scenario I suggested last time does actually get things going.
If anyone can come up with a solution, or even an explanation, we may yet be able to save civilisation!