Issue with custom named event and waking every minute

[arfing]

Hi,

I am pulling my hair out trying to get my compact framework 2 app.
running on windows mobile 5 to wake every minute and do some
background processing.

I have read a lot of interesting posts but none seem to match what I'm
trying to do . i.e. in vb.net

What I'm trying to do is create a named event every 60 seconds so i
can raise an event and do some processing. The event however never
seems to fire ?

I have listed the code below. Any help is greatly appreciated.


Public Sub HandlerNotifications()

Try

DebugLog("MessageReminder Started")
NotificationEvent = New
OpenNETCF.Threading.EventWaitHandle(False,
OpenNETCF.Threading.EventResetMode.AutoReset, "StartME")
Notify.RunAppAtTime("\\.\Notifications\NamedEvents
\StartME", DateTime.Now.AddSeconds(60))

While bLeaving = False

DebugLog("MessageReminder Wait For event to Fire")
' Wait for the notification event to fire.
NotificationEvent.WaitOne()

DebugLog("MessageReminder Event Fired")

'Prevent firing Notify_Fired twice (was necessary in
my case)
System.Threading.Thread.Sleep(2000)

' Let the notification subsystem know that we're done
with the event.
Try
DebugLog("MessageReminder - Clear the event")
Notify.RunAppAtTime("\\.\Notifications\NamedEvents
\StartME", DateTime.MinValue)

Catch e As Exception
DebugLog("MessageReminder Error ", e)
End Try

' RaiseEvent NetworkConnect()

' Close event handle.
NotificationEvent.Close()

If bLeaving = False Then
DebugLog("MessageReminder Re init Listen for
event")
' Recreate the event for notification.
NotificationEvent = New
OpenNETCF.Threading.EventWaitHandle(False,
OpenNETCF.Threading.EventResetMode.AutoReset, "StartME")
DebugLog("MessageReminder Re create disconnect
monitor")
Notify.RunAppAtTime("\\.\Notifications\NamedEvents
\StartME", Now.AddSeconds(60))
End If
DebugLog("MessageReminder Re init Listen for Re
Submitted")

End While
DebugLog("MessageReminder Re init Listen for Completed")

Catch ex As Exception
DebugLog("MessageReminder Error ", ex)
End Try

End Sub

 

[Paul G. Tobey [eMVP]]

That's not really within the range of CeRunAppAtTime's range. Set it for a
couple of minutes and it should work. The resolution just isn't guaranteed
to be that close. Since the device almost certainly never has a chance to
go to sleep in your configuration, you'd be just as well-off to simply tell
the system not to go to sleep and use Sleep() or WaitForSingleObject() with
a timeout of 1 minute to accomplish what you're doing.

What *are* you doing? There might be a better suggestion if you tell us
*what* you're trying to do, rather than how you've decided to do it...

Paul T.

 

[arfing]

Hi Paul,

Thanks for the prompt response.

We have an app that continually runs on the device which is a closed
paging application , similar to a email client / presence manger but a
closed user group along with a whole lot of business logic.
The app connects to a ip server and receives messages periodically and
also sends messages.
What is happening is randomly we lose the ip socket and get no
disconnect event hence we need some sort of heartbeat which checks to
see if we have received a heart beat in the last x minutes (this comes
from the central server) . If we have not received a heartbeat then we
want to drop the ip connection / socket and re-establish.
We were thinking of running this function every 5 mins or so
internally using a event based on various posts about how to wake a
device out of sleep .
We tried a timer but when the device goes to sleep our heartbeat
stops.

Im open to suggestions on how we should do this and any guidance is
really appreciated.

Regards,

Andrei

 

[Paul G. Tobey [eMVP]]

If this is a connected socket, TCP, not UDP, you can use TCP keep-alive to
do that. Of course, if the device goes to sleep, it's very likely that the
connection will be dropped by the other end, so you may need to prevent
yourself from going to sleep, if that's not what you want.

If you are setting the time to five minutes, it should work fine with
CeRunAppAtTime(). If it doesn't verify that it has the same behavior in
*native* code. It could be a bug in the operating system, as built for this
particular device that you have there.

Paul T.