MCALLT, Easyptr4

Anything QL Software or Programming Related.
User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: MCALLT, Easyptr4

Post by 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.


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: MCALLT, Easyptr4

Post by mk79 »

dilwyn wrote: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).


User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: MCALLT, Easyptr4

Post by dilwyn »

mk79 wrote:
dilwyn wrote: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.


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: MCALLT, Easyptr4

Post by pjw »

Hi Marcel, thanks for looking into it!
mk79 wrote: 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.


Per
dont be happy. worry
- ?
Post Reply