MCALLT, Easyptr4

[dilwyn]

Oops, I started it with my laptop after a Windows 10 update last year - viewtopic.php?f=19&t=2783&p=27206&hilit ... eep#p27207

I copied that binary mentioned in that thread over from laptop to the desktop PC and it has fixed the issue with QPC2 freezing on sleep or calling Task Manager issue. Not sure why I haven't noticed this until now, maybe the old version was fine on this desktop PC until a recent update, or maybe I used to have the laptop version on this PC and replaced it while grappling with printing issues more recently.

[mk79]

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.

Right, I can now reproduce your problem by putting a Loose item in your menu and clicking it during the first "long" MCALLT. But it's even a bit worse than that, as the timeout relies on the standard I/O timeout handling of QDOS in the IOP.RPTR call and QDOS never tells you much much time was "left" in the case of a successful return, the call is always restarted using the full timeout. This can also be noticed if you keep moving the pointer over the window, notice how the timeout never occurs because the pointer read is always restarted.

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.

DirectDraw graphics problem most likely. One of the reasons I rewrote that part for v5 (which is coming, yes).

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

Right, I can now reproduce your problem by putting a Loose item in your menu and clicking it during the first "long" MCALLT. But it's even a bit worse than that, as the timeout relies on the standard I/O timeout handling of QDOS in the IOP.RPTR call and QDOS never tells you much much time was "left" in the case of a successful return, the call is always restarted using the full timeout. This can also be noticed if you keep moving the pointer over the window, notice how the timeout never occurs because the pointer read is always restarted.

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.

DirectDraw graphics problem most likely. One of the reasons I rewrote that part for v5 (which is coming, yes).

OK, wonderful Marcel. The QPC2 4.93 trial version you sent me a while back does resolve the sleep freeze issue. I had removed that version over Christmas while investigating another issue, which I now know is nothing to do with QPC2.

The explanation of what is happening with MCALLT makes perfect sense, it is exactly the behaviour I am seeing. Thanks for taking the time to look at that.

[pjw]

Hi Marcel, thanks for looking into it!

The thing in Per's code I can explain (besides the bug that event% is set outside of the loop).

This was just a knocked-together piece of code to demonstrate an issue. Events were not being acted on at this point..

<> So your second MCALLT is actually not a new call but your first MCALLT is resumed, which didn't have a timeout. <>

By setting a reasonable timeout in the first MCALLT the routine works as it should, so I believe your assumptions are correct. A little awkward this, but at least I think I can find a way around.
It doesnt explain the behaviour I mentioned at first, where I had to get my program to send an Event to itself to get it going (and why the same technique doesnt work here!) But perhaps in light of your explanation it will become clear when I look at it again.