SEND IN TIME

[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

***************
Response to multiple responses ...

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 produce meaningful messages and timestamps.  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.  Meaning, not Revolution.  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 (after the weekend).

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.
Or, perhaps it will "trigger" some "Aha!" thoughts in the developers.

Terry