use-revolution Digest, Vol 73, Issue 30

[Terry Dennis]

Date: Wed, 21 Oct 2009 16:56:13 +1000
From: Sarah Reichelt <sarah.reichelt at gmail.com>
Subject: Re: SEND IN TIMe
To: How to use Revolution <use-revolution at lists.runrev.com>
Message-ID:
<f99b52860910202356m4fac3d7ap2abf92fa0a0845be at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Are you running a standalone or from inside the Rev IDE? I have had
messages lost due to editing the script at the wrong moment.

However in critical apps with lots of pending messages, I put in
another handler that checks that all the expected messages are in the
pendingMessages list and re-schedules them if they are not. It then
calls itself. The other pending messages also check to see that the
message checking handler is in the queue, so they are each checking
each other. Using this routine, I have never had problems with missing
messages in a standalone. And I'm not sure that it is really
necessary, but I started doing it for an app with lots of scheduled
messages where it was unattended and vital. Messages can be delayed if
the app is busy doing something else, but I haven't had any go
missing.

One other good technique is to reschedule the next call to the handler
at the start of the handler instead of at the end. This means that
even if there is a problem when running the handler, the pending
message has already been created. And if timing is slightly more
important, it removes the time taken to complete the handler from the
calculation for the next event.

Cheers,
Sarah

***************
The "SEND IN TIME" message  is sent at the top of the application as soon as 
the "Auto" button is clicked, and then it's sent again as soon as the app 
gains control when the time interval expires and the message is sent.  The 
time when the next interval is supposed to be triggered is displayed in the 
window. If the app got re-triggered, it would reset the display to be the 
time when the next execution is expected.

Environment is Windows Vista.  I have started the Windows Task Manager to 
see if the app was using an abnormal amount of time.  It wasn't.

There is one and only one SEND IN TIME in the app.  All the app does is 
re-trigger itself to periodically capture data from the internet.  Perhaps 
there's some weird situation where the trigger happens at the same time as 
some external app does its own wait for a response from the internet?  I 
doubt it, but I've seen stranger things happen in other environments.  Maybe 
because the internet requests are blocking, Revolution gets "stuck" if it 
doesn't get a "proper" response from a GET URL?  In that case, the app would 
never get control to SEND the message again.

I'm no rookie to programming.  I've tried about everything I could think of, 
or I wouldn't have reported it here.  It *appears* to be something outside 
of my control.  It *could* be a Windows glitch.  Again, doubtful, but ...

As far as I can tell, the problem happens ONLY in the standalone app.  I set 
the interval to a small number to test within the IDE, but could not get it 
to fail.  Of  course, I would have to be testing it precisely during the 
period when SEND IN TIME fails.  Since I haven't been able to detect when 
that situation occurs, I can't create the situation on demand, so I've never 
had it fail in the IDE. Besides, the interaction between the IDE and the 
keyboard might reset whatever is getting screwed up.

All the application exits are also timestamped..  I have seen nothing 
abnormal in any of that activity.

Again, this ONLY happens when there are other CPU intensive apps running in 
the system.  In time periods when my CPU is idle, I start up the app in 
question, then it auto-executes just fine until I cancel it, possibly days 
later.

I understand that it will be extremely difficult for this to be fixed, if 
indeed it is a Revolution glitch.  If I can't recreate it on demand, you 
guys certainly can't do it.  I just reported it here in case somebody else 
has encountered a similar problem and could corroborate my experience.

Terry