Always on pattern ?

Hi,

In one of our applications, we have a long process that can take up to 10
minutes.
During this time, I don't want the device to enter sleep mode.
The process is embedded in a command line application and I wrote this code
:

uint timerID = 0;
int _tmain(int argc, _TCHAR* argv[])
{
timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
SetCursor(LoadCursor(NULL, IDC_WAIT));

DoTheLongOperation();

SetCursor(NULL);
KillTimer(NULL, timerID);
return 0;
}

void CALLBACK TimerProc(
HWND hwnd,
UINT uMsg,
UINT idEvent,
DWORD dwTime
)
{
SystemIdleTimerReset();
timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
}

I wonder if this pattern is correct.

Thanks in advance for any feedback!
steve

srhartone
Tue Jun 19 07:51:00 CDT 2007

That code will work and I am assuming method SystemIdleTimerReset() is
calling SHIdleTimerReset in aygshell.dll. I am also assuming the code you
posted is in the UI layer because of changing the cursor to wait would
generally take place in the UI layer.

You haven't posted the DoTheLongOperation() method but I will assume it is
not running in its own separate worker thread because you set the cursor to
wait.

So I am assuming a lot of things!! ;)

The way I would of coded it would be simpler and getting rid of the timer.
Moving all that logic from the UI. I would wrap the DoTheLongOperation up
into the business layer which would create a new worker thread to do the
work. This enables control to return to the UI preventing it from locking up
for the whole process. Part of this business procedure would call
SHIdleTimerReset. I would lose the wait cursor and possibly create an event
which the UI would subscribe to which tells the UI when the process has
finished.

--
Simon Hart
http://srhartone.blogspot.com


"Steve B." wrote:

> Hi,
>
> In one of our applications, we have a long process that can take up to 10
> minutes.
> During this time, I don't want the device to enter sleep mode.
> The process is embedded in a command line application and I wrote this code
> :
>
> uint timerID = 0;
> int _tmain(int argc, _TCHAR* argv[])
> {
> timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
> SetCursor(LoadCursor(NULL, IDC_WAIT));
>
> DoTheLongOperation();
>
> SetCursor(NULL);
> KillTimer(NULL, timerID);
> return 0;
> }
>
> void CALLBACK TimerProc(
> HWND hwnd,
> UINT uMsg,
> UINT idEvent,
> DWORD dwTime
> )
> {
> SystemIdleTimerReset();
> timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
> }
>
> I wonder if this pattern is correct.
>
> Thanks in advance for any feedback!
> steve
>
>
>

Steve
Tue Jun 19 07:54:23 CDT 2007

This is only a "simple" console application that has no ui (with the
exception of the cursor).

Steve
"Simon Hart" <srhartone@yahoo.com> wrote in message
news:229B4A76-2574-4D63-B44D-6A91EE9ADC27@microsoft.com...
> That code will work and I am assuming method SystemIdleTimerReset() is
> calling SHIdleTimerReset in aygshell.dll. I am also assuming the code you
> posted is in the UI layer because of changing the cursor to wait would
> generally take place in the UI layer.
>
> You haven't posted the DoTheLongOperation() method but I will assume it is
> not running in its own separate worker thread because you set the cursor
> to
> wait.
>
> So I am assuming a lot of things!! ;)
>
> The way I would of coded it would be simpler and getting rid of the timer.
> Moving all that logic from the UI. I would wrap the DoTheLongOperation up
> into the business layer which would create a new worker thread to do the
> work. This enables control to return to the UI preventing it from locking
> up
> for the whole process. Part of this business procedure would call
> SHIdleTimerReset. I would lose the wait cursor and possibly create an
> event
> which the UI would subscribe to which tells the UI when the process has
> finished.
>
> --
> Simon Hart
> http://srhartone.blogspot.com
>
>
> "Steve B." wrote:
>
>> Hi,
>>
>> In one of our applications, we have a long process that can take up to 10
>> minutes.
>> During this time, I don't want the device to enter sleep mode.
>> The process is embedded in a command line application and I wrote this
>> code
>> :
>>
>> uint timerID = 0;
>> int _tmain(int argc, _TCHAR* argv[])
>> {
>> timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
>> SetCursor(LoadCursor(NULL, IDC_WAIT));
>>
>> DoTheLongOperation();
>>
>> SetCursor(NULL);
>> KillTimer(NULL, timerID);
>> return 0;
>> }
>>
>> void CALLBACK TimerProc(
>> HWND hwnd,
>> UINT uMsg,
>> UINT idEvent,
>> DWORD dwTime
>> )
>> {
>> SystemIdleTimerReset();
>> timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
>> }
>>
>> I wonder if this pattern is correct.
>>
>> Thanks in advance for any feedback!
>> steve
>>
>>
>>

srhartone
Tue Jun 19 08:15:02 CDT 2007

Ah, I did just notice you mentioned it was a command-line app. Even still,
I'd still do my suggestions without the event of course.
--
Simon Hart
http://srhartone.blogspot.com


"Steve B." wrote:

> This is only a "simple" console application that has no ui (with the
> exception of the cursor).
>
> Steve
> "Simon Hart" <srhartone@yahoo.com> wrote in message
> news:229B4A76-2574-4D63-B44D-6A91EE9ADC27@microsoft.com...
> > That code will work and I am assuming method SystemIdleTimerReset() is
> > calling SHIdleTimerReset in aygshell.dll. I am also assuming the code you
> > posted is in the UI layer because of changing the cursor to wait would
> > generally take place in the UI layer.
> >
> > You haven't posted the DoTheLongOperation() method but I will assume it is
> > not running in its own separate worker thread because you set the cursor
> > to
> > wait.
> >
> > So I am assuming a lot of things!! ;)
> >
> > The way I would of coded it would be simpler and getting rid of the timer.
> > Moving all that logic from the UI. I would wrap the DoTheLongOperation up
> > into the business layer which would create a new worker thread to do the
> > work. This enables control to return to the UI preventing it from locking
> > up
> > for the whole process. Part of this business procedure would call
> > SHIdleTimerReset. I would lose the wait cursor and possibly create an
> > event
> > which the UI would subscribe to which tells the UI when the process has
> > finished.
> >
> > --
> > Simon Hart
> > http://srhartone.blogspot.com
> >
> >
> > "Steve B." wrote:
> >
> >> Hi,
> >>
> >> In one of our applications, we have a long process that can take up to 10
> >> minutes.
> >> During this time, I don't want the device to enter sleep mode.
> >> The process is embedded in a command line application and I wrote this
> >> code
> >> :
> >>
> >> uint timerID = 0;
> >> int _tmain(int argc, _TCHAR* argv[])
> >> {
> >> timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
> >> SetCursor(LoadCursor(NULL, IDC_WAIT));
> >>
> >> DoTheLongOperation();
> >>
> >> SetCursor(NULL);
> >> KillTimer(NULL, timerID);
> >> return 0;
> >> }
> >>
> >> void CALLBACK TimerProc(
> >> HWND hwnd,
> >> UINT uMsg,
> >> UINT idEvent,
> >> DWORD dwTime
> >> )
> >> {
> >> SystemIdleTimerReset();
> >> timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
> >> }
> >>
> >> I wonder if this pattern is correct.
> >>
> >> Thanks in advance for any feedback!
> >> steve
> >>
> >>
> >>
>
>
>

ctacke/>
Tue Jun 19 08:51:52 CDT 2007

> That code will work and I am assuming method SystemIdleTimerReset() is
> calling SHIdleTimerReset in aygshell.dll.

Other way around. SHIdletTimerReset calls the SystemIdleTimerReset API.
AYGSHELL is simply a set of wrappers that call native APIs.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com

srhartone
Tue Jun 19 10:06:01 CDT 2007

Thanks
--
Simon Hart
http://srhartone.blogspot.com


"<ctacke/>" wrote:

> > That code will work and I am assuming method SystemIdleTimerReset() is
> > calling SHIdleTimerReset in aygshell.dll.
>
> Other way around. SHIdletTimerReset calls the SystemIdleTimerReset API.
> AYGSHELL is simply a set of wrappers that call native APIs.
>
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Managed Code in an Embedded World
> www.OpenNETCF.com
>
>
>
>

ctacke/>
Tue Jun 19 10:12:42 CDT 2007

It should work fine, provided the long operation doesn't have any long
system-blocking calls. For safety it might be best to spawn the long
running process in a thread. Something like this would work:

HANDLE hEvent;

int _tmain(int argc, _TCHAR* argv[])
{
hEvent = CreateEvent(...);
HANDLE hThread = CreateThread(..., TheLongOperationProc, ...);
CloseHandle(hThread);

while(WaitForSingleObject(hEvent) != WAIT_OBJECT_0)
{
Sleep(100);
// maybe update the console to show we're not dead
SystemIdleTimerReset();
}
return 0;
}

void TheLongOperationProc()
{
// do stuff
SetEvent(hEvent);
}



--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com


"Steve B." <steve_beauge@com.msn_swap> wrote in message
news:umCyNblsHHA.1060@TK2MSFTNGP06.phx.gbl...
> Hi,
>
> In one of our applications, we have a long process that can take up to 10
> minutes.
> During this time, I don't want the device to enter sleep mode.
> The process is embedded in a command line application and I wrote this
> code :
>
> uint timerID = 0;
> int _tmain(int argc, _TCHAR* argv[])
> {
> timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
> SetCursor(LoadCursor(NULL, IDC_WAIT));
>
> DoTheLongOperation();
>
> SetCursor(NULL);
> KillTimer(NULL, timerID);
> return 0;
> }
>
> void CALLBACK TimerProc(
> HWND hwnd,
> UINT uMsg,
> UINT idEvent,
> DWORD dwTime
> )
> {
> SystemIdleTimerReset();
> timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
> }
>
> I wonder if this pattern is correct.
>
> Thanks in advance for any feedback!
> steve
>

Steve
Tue Jun 19 10:22:18 CDT 2007

The first pattern I provided seems to work so I keep by now.
I'll probably investigate running the process in a separate thread to give
feedback to the user but at a later time...

Thanks for your advices.
Steve

"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message
news:%23eJ0LRosHHA.1208@TK2MSFTNGP05.phx.gbl...
> It should work fine, provided the long operation doesn't have any long
> system-blocking calls. For safety it might be best to spawn the long
> running process in a thread. Something like this would work:
>
> HANDLE hEvent;
>
> int _tmain(int argc, _TCHAR* argv[])
> {
> hEvent = CreateEvent(...);
> HANDLE hThread = CreateThread(..., TheLongOperationProc, ...);
> CloseHandle(hThread);
>
> while(WaitForSingleObject(hEvent) != WAIT_OBJECT_0)
> {
> Sleep(100);
> // maybe update the console to show we're not dead
> SystemIdleTimerReset();
> }
> return 0;
> }
>
> void TheLongOperationProc()
> {
> // do stuff
> SetEvent(hEvent);
> }
>
>
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Managed Code in an Embedded World
> www.OpenNETCF.com
>
>
> "Steve B." <steve_beauge@com.msn_swap> wrote in message
> news:umCyNblsHHA.1060@TK2MSFTNGP06.phx.gbl...
>> Hi,
>>
>> In one of our applications, we have a long process that can take up to 10
>> minutes.
>> During this time, I don't want the device to enter sleep mode.
>> The process is embedded in a command line application and I wrote this
>> code :
>>
>> uint timerID = 0;
>> int _tmain(int argc, _TCHAR* argv[])
>> {
>> timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
>> SetCursor(LoadCursor(NULL, IDC_WAIT));
>>
>> DoTheLongOperation();
>>
>> SetCursor(NULL);
>> KillTimer(NULL, timerID);
>> return 0;
>> }
>>
>> void CALLBACK TimerProc(
>> HWND hwnd,
>> UINT uMsg,
>> UINT idEvent,
>> DWORD dwTime
>> )
>> {
>> SystemIdleTimerReset();
>> timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
>> }
>>
>> I wonder if this pattern is correct.
>>
>> Thanks in advance for any feedback!
>> steve
>>
>
>

Uncle
Tue Jun 19 10:43:55 CDT 2007

In reply to Steve B. (steve_beauge@com.msn_swap) who wrote this in
OWayAZosHHA.4572@TK2MSFTNGP02.phx.gbl, I, Marvo, say :

> The first pattern I provided seems to work so I keep by now.
> I'll probably investigate running the process in a separate thread to
> give feedback to the user but at a later time...


There *is* actually a way to make your process run its ten minute job even
while the device is asleep. It's tricky, but can be done. I know, cos I've
done it. It may not be appropriate for your app though, and it won't run as
fast either.

ctacke/>
Tue Jun 19 11:42:07 CDT 2007

Not true - when fully asleep the processor clock is off and no instructions
are executed. Some devices (like the Phone Editions) have the ability to go
into a lower power state where teh display and backlight are off and still
execute code, but the device is defintiely not in sleep mode (as the much
higher current draw would attest).


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com


"Uncle Marvo" <paul.r@deletethisbitfortescue.org.uk> wrote in message
news:5dqbtvF35id03U1@mid.individual.net...
> In reply to Steve B. (steve_beauge@com.msn_swap) who wrote this in
> OWayAZosHHA.4572@TK2MSFTNGP02.phx.gbl, I, Marvo, say :
>
>> The first pattern I provided seems to work so I keep by now.
>> I'll probably investigate running the process in a separate thread to
>> give feedback to the user but at a later time...
>
>
> There *is* actually a way to make your process run its ten minute job even
> while the device is asleep. It's tricky, but can be done. I know, cos I've
> done it. It may not be appropriate for your app though, and it won't run
> as fast either.
>
>

Alan
Fri Jul 20 14:00:18 CDT 2007

Chris, let me make a simple correction to your code.
You could just wait on the thread handle to know when a thread
terminates.
You don't need a seperate event to notify thread termination.
Also I don't think you would need to call SystemIdleTimerReset() 10
times every second.
It just seems too often.


int _tmain(int argc, _TCHAR* argv[])
{

HANDLE hThread = CreateThread(..., TheLongOperationProc, ...);


while(WaitForSingleObject(hThread, 0 ) != WAIT_OBJECT_0)
{
Sleep(100);
// maybe update the console to show we're not dead
SystemIdleTimerReset();
}

CloseHandle(hThread);

return 0;

}


DWORD TheLongOperationProc()
{
// do stuff

return 0;
}



On Jun 20, 12:12 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
> It should work fine, provided the long operation doesn't have any long
> system-blocking calls. For safety it might be best to spawn the long
> running process in a thread. Something like this would work:
>
> HANDLE hEvent;
>
> int _tmain(int argc, _TCHAR* argv[])
> {
> hEvent = CreateEvent(...);
> HANDLE hThread = CreateThread(..., TheLongOperationProc, ...);
> CloseHandle(hThread);
>
> while(WaitForSingleObject(hEvent) != WAIT_OBJECT_0)
> {
> Sleep(100);
> // maybe update the console to show we're not dead
> SystemIdleTimerReset();
> }
> return 0;
>
> }
>
> void TheLongOperationProc()
> {
> // do stuff
> SetEvent(hEvent);
>
> }
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Managed Code in an Embedded Worldwww.OpenNETCF.com
>
> "Steve B." <steve_bea...@com.msn_swap> wrote in message
>
> news:umCyNblsHHA.1060@TK2MSFTNGP06.phx.gbl...
>
>
>
> > Hi,
>
> > In one of our applications, we have a long process that can take up to 10
> > minutes.
> > During this time, I don't want the device to enter sleep mode.
> > The process is embedded in a command line application and I wrote this
> > code :
>
> > uint timerID = 0;
> > int _tmain(int argc, _TCHAR* argv[])
> > {
> > timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
> > SetCursor(LoadCursor(NULL, IDC_WAIT));
>
> > DoTheLongOperation();
>
> > SetCursor(NULL);
> > KillTimer(NULL, timerID);
> > return 0;
> > }
>
> > void CALLBACK TimerProc(
> > HWND hwnd,
> > UINT uMsg,
> > UINT idEvent,
> > DWORD dwTime
> > )
> > {
> > SystemIdleTimerReset();
> > timerID = SetTimer(NULL, 0, 5000, &(TimerProc));
> > }
>
> > I wonder if this pattern is correct.
>
> > Thanks in advance for any feedback!
> > steve- Hide quoted text -
>
> - Show quoted text -