MCALLT, Easyptr4

[dilwyn]

I'm encountering some issues with the time parameter in Easyptr 4 (using the latest version on Marcel's site, but I've used an older version of ptrmenr_cde and menus created in more than one version of Easymenu to test against bugs in any one version).

Using the form LET num=MCALLT(#ch%,event%,time%) for a limited timing within a loop something like this will demonstrate the problem. This is a much simplified version of the program - it's an animation viewer - main difference being that the loop is in a PROCedure in my program.

Code: Select all

MDRAW #0,win1_test_men
REPeat
  event% = 255 : REM varying event% has no effect on the problem
  time% = 5 : REM 5/50ths second
  num=MCALLT(#ch%,event%,time%)
  PRINT #0,"X ";
END REPeat
MCLEAR #0

The PRINT "X "; is just a progress indicator to demonstrate the problem. Instead of a constant speed of printing the X'es, I get a sort of keyboard-repeat type of delay, where the first X appears, then there is a delay of about 5 to 7 seconds, after that each X appears smoothly every 5/50th second. Varying the event or time parameters has no effect.

Anyone else have experience of this? It's a weird little problem which has had me chasing my tail for several days now.

[pjw]

Hi Dilwyn,
Funny you should say that! Just this morning I had a similar problem. MCALLT just got stuck and refused to timeout. Like you, I tried everything. Normally it doesnt do this, but in this specific context it did. It took me a long while to find a workaround. This did the trick:

Code: Select all

100 ch% = FOPEN("con")
110 MDRAW #ch%,'win1_ptr_mem_Menu_men', 0, 0, 100, 60
120 event% = 511: REMark $1FF, ie Job Event #1 ($100 might also work)
130 time%  =  25: REMark 5/50ths second
140 SEND_EVENT JOBID, 1: REMark Kickstart MCALLT
150 REPeat
160   num=MCALLT(#ch%,event%,time%)
170   SELect ON num
180    = -1280: REMark Timeout/Events
190      BEEP 2000, 2: REMark Or PRINT #0,"X ";
200    = -1: EXIT
210   END SELect
220 END REPeat
230 MCLEAR #ch%: CLOSE

Thats right: Sending an event to itself kickstarts timeout! This is so peculiar it may not work in your case. Please let me know..

[dilwyn]

Thanks Per, tends to confirm my theory that MCALLT probably does its call, and only then does it update the timeout in time for the next call.

But I can't seem to write a routine where it's consistent. Build the simplest of test harnesses and the problem goes away. Make the test harness more complex, the problem comes back. Amend a menu in Easymenu, sometimes the effect shows then sometimes it doesn't (i.e. the test program will work with the menu one moment, then after amending the menu the results are different. Totally inconsistent and I didn't want to approach Marcel (I know he's not that keen on updating Easyptr code) about this before I had a routine which would consistently show the behaviour.

Can't release my GIF viewer (which uses your PAC routines) until I get this sorted as the MCALLT is used for inter-frame timing.

Next step, now I know someone else is having the problem, is to try using something like RDPT with a timeout to see if it gives the same result. (Don't want to send events to it as I want the viewer to work on QDOS with PE v2).

[pjw]

If you find another solution, it would be nice to know
Despite the gremlins, I think we can agree that EasyPtr is MUCH more useful than troublesome.

[dilwyn]

If you find another solution, it would be nice to know
Despite the gremlins, I think we can agree that EasyPtr is MUCH more useful than troublesome.

It's a bit less difficult to learn and use than QPTR maybe. But the sometimes weird syntax and distinct lack of examples often mean that when you run into a problem you're never quite sure if you've made a mistake or whether there's more to it.
EDIT:Forgot to mention that using SEND_EVENT doesn't seem to fix the problem in my case.

[pjw]

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!

[pjw]

Theres (almost) certainly a bug in MCALLT. It displays other erratic behaviour, depending on ambient circumstances..

[dilwyn]

Theres (almost) certainly a bug in MCALLT. It displays other erratic behaviour, depending on ambient circumstances..

I've sent Marcel an email with an example routine to demo the problem, asking him to investigate if he gets time (if...). When I sent it, it showed the problem about 50% of the time. Today, I tried it again, can't get it to show the problem at all. Hope my description of the problem explains it adequately to him.

I have three versions of ptrmenr_cde here, the problem is similarly unpredictable on all of them.

In my case, I can use RDPT with a timeout as a workaround, since the timeout parameter seems to work reliably in that.

[mk79]

I've seen the thread but I cannot reproduce the behavior. Like, at all. I've looked at the code, I don't claim to understand it completely but at least there is no obvious problem.

The thing in Per's code I can explain (besides the bug that event% is set outside of the loop). MCALL is a nasty little routine. When a loose item is hit while RPTR is running, usually some piece of machine code is called. Same in EasyPtr, but the piece of machine code saves the current state of the job and returns to basic. This means while MCALL has returned RPTR is still basically running. When MCALL is entered again the original RPTR call is resumed, restoring the stack and all. So your second MCALLT is actually not a new call but your first MCALLT is resumed, which didn't have a timeout. I do not know why it is done this way, but I guess you don't go to this length without a reason. Very difficult to wrap your head around at least.

[dilwyn]

Thanks Marcel. Tends to confirm my idea that something about the mis-timed call is a "hangover" from a previous call. Once the "too long" MCALLT saved from a previous MCALLT eventually times out, then the delay value does seem to rectify itself. Also explains why it's not been noticed until now, since nobody in their right mind (which excludes me) uses MCALLT in the way I have.

Workaround it will be for me, then.

Next problem - why does QPC2 4.05 fail to resume after the PC has gone to sleep overnight (irrespective of power settings)? I'm sure I've read about this somewhere else, time to go searching the Forum.