wait loop

[John Harrison]

Hello,

How do I pause my application for a given number of seconds without blocking
any other application or user input? I've found the sleep function but that
seems to lock the entire system while it executes. I'm hoping there's a
simple answer.

I'm writing a carbonised application for MacOS 9 and I know very little
about programming Macs.

MTIA,
John

PS is there a FAQ for this group?

[David Phillip Oster]

In article <bj2c60$e1rbc$1@ID-196037.news.uni-berlin.de>,
"John Harrison" <john_andronicus@hotmail.com> wrote:

> How do I pause my application for a given number of seconds without blocking
> any other application or user input? I've found the sleep function but that
> seems to lock the entire system while it executes. I'm hoping there's a
> simple answer.

When you want to sleep, just call WaitNextEvent() in a loop, with
allowing only activate, update, and high level events, until the
event.when field is after the target time (or the user cancels)

Remember that you can receive a quit appleEvent at this point, so be
sure your code handles that case gracefully.

[Michael Ash]

In article <oster-1736F3.18480202092003@news.sf.sbcglobal.net>,
David Phillip Oster <oster@ieee.org> wrote:

> In article <bj2c60$e1rbc$1@ID-196037.news.uni-berlin.de>,
> "John Harrison" <john_andronicus@hotmail.com> wrote:
>

> > How do I pause my application for a given number of seconds without blocking
> > any other application or user input? I've found the sleep function but that
> > seems to lock the entire system while it executes. I'm hoping there's a
> > simple answer.

>
> When you want to sleep, just call WaitNextEvent() in a loop, with
> allowing only activate, update, and high level events, until the
> event.when field is after the target time (or the user cancels)

Also be sure to be kind to the user's CPU (and battery consumption if
he's on a portable) and give WNE a non-zero sleep time. Preferably you'd
give it a sleep time equal to the remaining time you want to delay.
Using CPU in a busy-wait loop is still an isuse even in Classic.

[John Harrison]

"David Phillip Oster" <oster@ieee.org> wrote in message
news:oster-1736F3.18480202092003@news.sf.sbcglobal.net...

> In article <bj2c60$e1rbc$1@ID-196037.news.uni-berlin.de>,
> "John Harrison" <john_andronicus@hotmail.com> wrote:
>

> > How do I pause my application for a given number of seconds without

blocking

> > any other application or user input? I've found the sleep function but

that

> > seems to lock the entire system while it executes. I'm hoping there's a
> > simple answer.

>
> When you want to sleep, just call WaitNextEvent() in a loop, with
> allowing only activate, update, and high level events, until the
> event.when field is after the target time (or the user cancels)
>
> Remember that you can receive a quit appleEvent at this point, so be
> sure your code handles that case gracefully.

I was hoping that wouldn't be the answer. I've no interest in letting my
application run at this point, I would like all events to be queued (or
something) until the delay has finished. If I did receive a quit event I
certainly could not quit at that point. My interest is not to prevent other
applications from running, or prevent the user from switching to another
application while mine is waiting.

What would be the consequence of using WaitNextEvent without allowing
activate, update or high level events?

I actually need this in two different applications, the first is a regular
app with a user interface etc. but the other has no windows or menus at all,
does that make a difference?

john

[David C. Stone]

In article <bj3u6t$elpgh$1@ID-196037.news.uni-berlin.de>, John Harrison
<john_andronicus@hotmail.com> wrote:

> "David Phillip Oster" <oster@ieee.org> wrote in message
> news:oster-1736F3.18480202092003@news.sf.sbcglobal.net...

> > In article <bj2c60$e1rbc$1@ID-196037.news.uni-berlin.de>,
> > "John Harrison" <john_andronicus@hotmail.com> wrote:
> >

> > > How do I pause my application for a given number of seconds without

> blocking

> > > any other application or user input? I've found the sleep function but

> that

> > > seems to lock the entire system while it executes. I'm hoping there's a
> > > simple answer.

> >
> > When you want to sleep, just call WaitNextEvent() in a loop, with
> > allowing only activate, update, and high level events, until the
> > event.when field is after the target time (or the user cancels)
> >
> > Remember that you can receive a quit appleEvent at this point, so be
> > sure your code handles that case gracefully.

>
> I was hoping that wouldn't be the answer. I've no interest in letting my
> application run at this point, I would like all events to be queued (or
> something) until the delay has finished. If I did receive a quit event I
> certainly could not quit at that point. My interest is not to prevent other
> applications from running, or prevent the user from switching to another
> application while mine is waiting.

One thing to consider is that the event queue is not infinite - if the
delay is long and the user impatient, you could end up dropping events.

As far as not being able to quit at the point in your delay, that's one
of the reasons for having a quit application handler - so you can alert
the user that there are pending operations, and allow them to respond
accordingly.

>
> What would be the consequence of using WaitNextEvent without allowing
> activate, update or high level events?

Your application would not allow the user to switch windows so that they
could check their email while whatever process it is you are running
completes its delay. Users quite rightly expect that any application
process which must complete before it yields control back to the user
would be in the form of a dialog, hopefully with a "Cancel" button in
case the user can't wait any longer.

There may well be a very elegant and user-friendly solution to your
problem, but without knowing more about why you need this particular
delay, I doubt that anyone will be able to help you much. Can you
give more details?

[Carl R. Osterwald]

In article <bj3u6t$elpgh$1@ID-196037.news.uni-berlin.de>, John Harrison
<john_andronicus@hotmail.com> wrote:

> "David Phillip Oster" <oster@ieee.org> wrote in message
> news:oster-1736F3.18480202092003@news.sf.sbcglobal.net...

> > In article <bj2c60$e1rbc$1@ID-196037.news.uni-berlin.de>,
> > "John Harrison" <john_andronicus@hotmail.com> wrote:
> >

> > > How do I pause my application for a given number of seconds without

> blocking

> > > any other application or user input? I've found the sleep function but

> that

> > > seems to lock the entire system while it executes. I'm hoping there's a
> > > simple answer.

> >
> > When you want to sleep, just call WaitNextEvent() in a loop, with
> > allowing only activate, update, and high level events, until the
> > event.when field is after the target time (or the user cancels)
> >
> > Remember that you can receive a quit appleEvent at this point, so be
> > sure your code handles that case gracefully.

>
> I was hoping that wouldn't be the answer. I've no interest in letting my
> application run at this point, I would like all events to be queued (or
> something) until the delay has finished. If I did receive a quit event I
> certainly could not quit at that point. My interest is not to prevent other
> applications from running, or prevent the user from switching to another
> application while mine is waiting.
>
> What would be the consequence of using WaitNextEvent without allowing
> activate, update or high level events?
>
> I actually need this in two different applications, the first is a regular
> app with a user interface etc. but the other has no windows or menus at all,
> does that make a difference?

I would use Carbon events, which are structured so that your event
handlers are only called when an event has occurred. If want to go
away for awhile, you can install a one-shot Carbon timer that will
effectively suspend your app until the timer completes.

See:

<[url]http://developer.apple.com/documentation/Carbon/EventsOtherInput-date.h[/url]
tml#//apple_ref/doc/uid/TP30000420-TP30000447>

and especially:

<[url]http://developer.apple.com/documentation/Carbon/Conceptual/Carbon_Event[/url]
_Manager/index.html>


-=-=-=-=-

[Michael Ash]

In article <bj3u6t$elpgh$1@ID-196037.news.uni-berlin.de>,
"John Harrison" <john_andronicus@hotmail.com> wrote:

> I was hoping that wouldn't be the answer. I've no interest in letting my
> application run at this point, I would like all events to be queued (or
> something) until the delay has finished. If I did receive a quit event I
> certainly could not quit at that point.

Why couldn't you quit? Is the operation totally non-cancellable? That
seems very wrong. Not only should the user be able to quit your app in
the middle of the delay, but he should be able to cancel the operation
as well. (If this is an absolute impossibility, I'd be interested to
know why.) You need to handle activate events so your app can be
switched in and out, and you need to handle update events so your
windows don't go white anytime they're covered and then uncovered.

I don't see this as being a very harsh requirement, though. All you need
is a small event loop. What kind of operation are you doing where it's
*so* important that you not handle any events, and you can't quit or
cancel or anything?

[David Phillip Oster]

In article <030920030739045982%i@mac.com>,
"Carl R. Osterwald" <i@mac.com> wrote:

> I would use Carbon events, which are structured so that your event
> handlers are only called when an event has occurred. If want to go
> away for awhile, you can install a one-shot Carbon timer that will
> effectively suspend your app until the timer completes.
>
> See:
>
> <[url]http://developer.apple.com/documentation/Carbon/EventsOtherInput-date.h[/url]
> tml#//apple_ref/doc/uid/TP30000420-TP30000447>
>
> and especially:
>
> <[url]http://developer.apple.com/documentation/Carbon/Conceptual/Carbon_Event[/url]
> _Manager/index.html>

Can you be more specific? I only see how you use a timer to trigger an
event some time in the future, not one that will suspend the delivery of
other, ordinary events, until some time in the future.

You could use select() from the System framework to block your program
until some time in the future, but the original poster seems to need
something that will also work under OS 9. (Under OS X his experiment,
using Delay(), would have worked as he expected.)

[John Harrison]

"Michael Ash" <mail@mikeash.com> wrote in message
news:mail-B699DC.12344703092003@localhost...

> In article <bj3u6t$elpgh$1@ID-196037.news.uni-berlin.de>,
> "John Harrison" <john_andronicus@hotmail.com> wrote:
>

> > I was hoping that wouldn't be the answer. I've no interest in letting my
> > application run at this point, I would like all events to be queued (or
> > something) until the delay has finished. If I did receive a quit event I
> > certainly could not quit at that point.

>
> Why couldn't you quit? Is the operation totally non-cancellable? That
> seems very wrong. Not only should the user be able to quit your app in
> the middle of the delay, but he should be able to cancel the operation
> as well. (If this is an absolute impossibility, I'd be interested to
> know why.) You need to handle activate events so your app can be
> switched in and out, and you need to handle update events so your
> windows don't go white anytime they're covered and then uncovered.
>
> I don't see this as being a very harsh requirement, though. All you need
> is a small event loop. What kind of operation are you doing where it's
> *so* important that you not handle any events, and you can't quit or
> cancel or anything?

It's not a question of the operation being so important, quite the opposite
in fact. The situation when I need a delay is a rare occurrence, and I'm not
able to devote a lot of programming time to writing perfect code that
handles all eventualities. Particularly as I am working with a large
application that was designed and written by someone else, it is not
practical to amend the design of this program in order to satisfy this small
requirement. The design of the code is no doubt very sophisticated but it is
also very opaque, with event handlers and event listeners, registering of
interest in various events etc. etc. A simple operation like updating a
window or allowing the user to cancel a lengthy operation is not simple at
all in this code.

I just want a way of delaying my application without locking the user out of
other applications. I don't much care if I miss a few update events, I do
care if my inexpertly written code crashes my application or locks the
system.

I have the following code (from memory)

void delay(unsigned long seconds)
{
unsigned long t0 = TickCount();
unsigned long t1 = 0;
unsigned long t2 = 60*seconds;
while (t1 < t2)
{
EventRecord e;
WaitNextEvent(0, &e, t2 - t1, 0);
t1 = e.when - t0;
}
}

How close does that come to my requirements?

1) Not crashing my program
2) Allowing other programs to run (i.e. not hogging the CPU)
3) Allowing users to switch to other applications

What events do I need to process to accomplish the above?

I really don't care about the other stuff.

john

[Miro Jurisic]

In article <bj5nfs$ff31e$1@ID-196037.news.uni-berlin.de>,
"John Harrison" <john_andronicus@hotmail.com> wrote:

> What I need is something that will suspend my application for a given period
> (a few seconds) then carry on processing, a simple linear sequence. It is
> not an option when I need this delay to happen to return to the main event
> processing loop, it would be too difficult in that circumstance to pick up
> processing where it was left off before the delay happened.

It is simply impossible to do what you are trying to do on Mac OS 9. In order to
suspend an application you have to use an event loop, however trivial that loop
may be, and in that loop you must handle activate/deactivate and suspend/resume
events. If you do not handle those events correctly, the Process Manager will
get mighty confused if the user clicks on a window in another application.

Please read <http://developer.apple.com/qa/ps/ps06.html>

hth

meeroh

--
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

[Michael Ash]

In article <bj5nfs$ff31e$1@ID-196037.news.uni-berlin.de>,
"John Harrison" <john_andronicus@hotmail.com> wrote:

> Is that so difficult? I find it hard to believe that it is. Please answer
> the question instead of telling me I should be doing it a different way. I
> do know what I am doing in general terms, just not what the answer is in
> Macintosh terms.

Mac OS 9 relies a very great amount on good behavior by the programs
running within it. Unlike a UNIX or even a modern Windows OS, a program
that does not do the proper things (simply avoiding the wrong things is
not enough) will cause problems for the entire system. This is one of
those cases.

[John Harrison]

"Miro Jurisic" <macdev@meeroh.org> wrote in message
news:macdev-58C337.19282403092003@senator-bedfellow.mit.edu...

> In article <bj5nfs$ff31e$1@ID-196037.news.uni-berlin.de>,
> "John Harrison" <john_andronicus@hotmail.com> wrote:
>

> > What I need is something that will suspend my application for a given

period

> > (a few seconds) then carry on processing, a simple linear sequence. It

is

> > not an option when I need this delay to happen to return to the main

event

> > processing loop, it would be too difficult in that circumstance to pick

up

> > processing where it was left off before the delay happened.

>
> It is simply impossible to do what you are trying to do on Mac OS 9. In

order to

> suspend an application you have to use an event loop, however trivial that

loop

> may be, and in that loop you must handle activate/deactivate and

suspend/resume

> events. If you do not handle those events correctly, the Process Manager

will

> get mighty confused if the user clicks on a window in another application.
>
> Please read <http://developer.apple.com/qa/ps/ps06.html>
>
> hth
>
> meeroh
>

Thanks, that's the sort of information I needed. I'm still unclear about
suspend and resume events though. What do I actually have to do to handle a
suspend or resume event, in order to avoid the bad things that the web page
mentions.

The web page does not mentions activate/deactivate events however, is that
simply an omission?

john

[John Harrison]

"Michael Ash" <mail@mikeash.com> wrote in message
news:mail-B0932D.22063703092003@localhost...

> In article <bj5nfs$ff31e$1@ID-196037.news.uni-berlin.de>,
> "John Harrison" <john_andronicus@hotmail.com> wrote:
>

> > Is that so difficult? I find it hard to believe that it is. Please

answer

> > the question instead of telling me I should be doing it a different way.

I

> > do know what I am doing in general terms, just not what the answer is in
> > Macintosh terms.

>
> Mac OS 9 relies a very great amount on good behavior by the programs
> running within it. Unlike a UNIX or even a modern Windows OS, a program
> that does not do the proper things (simply avoiding the wrong things is
> not enough) will cause problems for the entire system. This is one of
> those cases.

OK, point taken. What I'm trying to find out from my position as a very
occasional Mac developer is what 'the proper things' consist of. I know I
have to handle suspend/resume events, and maybe activate/deactivate events,
but frankly I don't know what it means to handle those events. What *must* I
do when I receive one of those events, and what can I get away with not
doing?

john

[David C. Stone]

In article <bj6kad$g3fso$1@ID-196037.news.uni-berlin.de>, John Harrison
<john_andronicus@hotmail.com> wrote:

> "Michael Ash" <mail@mikeash.com> wrote in message
> news:mail-B0932D.22063703092003@localhost...

> > In article <bj5nfs$ff31e$1@ID-196037.news.uni-berlin.de>,
> > "John Harrison" <john_andronicus@hotmail.com> wrote:
> >

> > > Is that so difficult? I find it hard to believe that it is. Please

> answer

> > > the question instead of telling me I should be doing it a different way.

> I

> > > do know what I am doing in general terms, just not what the answer is in
> > > Macintosh terms.

> >
> > Mac OS 9 relies a very great amount on good behavior by the programs
> > running within it. Unlike a UNIX or even a modern Windows OS, a program
> > that does not do the proper things (simply avoiding the wrong things is
> > not enough) will cause problems for the entire system. This is one of
> > those cases.

>
> OK, point taken. What I'm trying to find out from my position as a very
> occasional Mac developer is what 'the proper things' consist of. I know I
> have to handle suspend/resume events, and maybe activate/deactivate events,
> but frankly I don't know what it means to handle those events. What *must* I
> do when I receive one of those events, and what can I get away with not
> doing?

Activeate/Deactivate events are received whenever the user switches
windows, so that you get a chance to activate/deactivate window
controls, text, tools, cursors... In classic, this is under the
event.what == activateEvt type.

Suspend/Resume events are received whenever the user switches
applications. This gives you a chance to manipulate the clipboard
contents (if necessary), show/hide tool palettes, etc. in classic,
these come (along with mouse moved) in the message of an osEvt.

Update events are received whenever a portion of a window is uncovered
and needs redrawing, whether the window is active or not.

[Tom Dowdy]

In article <040920031055550590%no.email@example.com>,
"David C. Stone" <no.email@example.com> wrote:

> Update events are received whenever a portion of a window is uncovered
> and needs redrawing, whether the window is active or not.

And to the point of the OP: failure to process update events in a timely
manner (you'll keep getting them if you ignore them) will cause the
system to bog down for around two minutes until finally the system
assumes your application is broken and stops giving them to you.

A properly behaving application on the Mac must process update events.
Minimal processing would be a BeginUpdate()/EndUpdate() pair with no
actual drawing taking place.

[David C. Stone]

In article <dowdy-C49F08.08402304092003@news.apple.com>, Tom Dowdy
<dowdy@apple.com> wrote:

> In article <040920031055550590%no.email@example.com>,
> "David C. Stone" <no.email@example.com> wrote:

> > Update events are received whenever a portion of a window is uncovered
> > and needs redrawing, whether the window is active or not.

>
> And to the point of the OP: failure to process update events in a timely
> manner (you'll keep getting them if you ignore them) will cause the
> system to bog down for around two minutes until finally the system
> assumes your application is broken and stops giving them to you.
>
> A properly behaving application on the Mac must process update events.
> Minimal processing would be a BeginUpdate()/EndUpdate() pair with no
> actual drawing taking place.

Good point. Another thing the original poster might consider is setting
a global flag that indicates whether the application is in delay mode or
not. That way, the existing event loop can be used, but all unnecessary
processing can be skipped until the delay period expires.

HTH

[John Harrison]

"Tom Dowdy" <dowdy@apple.com> wrote in message
news:dowdy-C49F08.08402304092003@news.apple.com...

> In article <040920031055550590%no.email@example.com>,
> "David C. Stone" <no.email@example.com> wrote:

> > Update events are received whenever a portion of a window is uncovered
> > and needs redrawing, whether the window is active or not.

>
> And to the point of the OP: failure to process update events in a timely
> manner (you'll keep getting them if you ignore them) will cause the
> system to bog down for around two minutes until finally the system
> assumes your application is broken and stops giving them to you.
>
> A properly behaving application on the Mac must process update events.
> Minimal processing would be a BeginUpdate()/EndUpdate() pair with no
> actual drawing taking place.

OK that's very useful, especially the bit about the system getting bogged
down. What about the other events listed, suspend/resume and
activate/deactivate?

john

[Miro Jurisic]

In article <bj6k5k$fhq22$1@ID-196037.news.uni-berlin.de>,
"John Harrison" <john_andronicus@hotmail.com> wrote:

> "Miro Jurisic" <macdev@meeroh.org> wrote in message
> news:macdev-58C337.19282403092003@senator-bedfellow.mit.edu...

> > In article <bj5nfs$ff31e$1@ID-196037.news.uni-berlin.de>,
> > "John Harrison" <john_andronicus@hotmail.com> wrote:
> >

> > > What I need is something that will suspend my application for a given
> > > period (a few seconds) then carry on processing, a simple linear
> > > sequence. It is not an option when I need this delay to happen to return
> > > to the main event processing loop, it would be too difficult in that
> > > circumstance to pick up processing where it was left off before the delay
> > > happened.

> >
> > It is simply impossible to do what you are trying to do on Mac OS 9. In
> > order to suspend an application you have to use an event loop, however
> > trivial that loop may be, and in that loop you must handle
> > activate/deactivate and suspend/resume events. If you do not handle those
> > events correctly, the Process Manager will get mighty confused if the user
> > clicks on a window in another application.
> >
> > Please read <http://developer.apple.com/qa/ps/ps06.html>

>
> Thanks, that's the sort of information I needed. I'm still unclear about
> suspend and resume events though. What do I actually have to do to handle a
> suspend or resume event, in order to avoid the bad things that the web page
> mentions.

That would be covered by any book which covers basic Mac OS 9 event handling.
<http://www.mactech.com/macintosh-c/classic-chap02-1.html> offers a good overview,
among others.

> The web page does not mentions activate/deactivate events however, is that
> simply an omission?

I believe that a failure to handle activate/deactivate is cosmetic, whereas a
failure to handle suspend/resume/update is much more serious, hence that Q&A
only discusses the latter.

hth

meeroh

--
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

[Tom Dowdy]

In article <bj7p62$fv9gq$1@ID-196037.news.uni-berlin.de>,
"John Harrison" <john_andronicus@hotmail.com> wrote:

> OK that's very useful, especially the bit about the system getting bogged
> down. What about the other events listed, suspend/resume and
> activate/deactivate?

Failure to process these events will result in your application's idea
of state (ie, am I in the foreground or background, is this window in
the front or not) being incorrect once you come out of this state. Only
you can tell if this is an issue for you or not.

No offense, but here's an idea: since lots of suggestions have been
made, perhaps you should actually code them and test your application.
At this point, asking more questions isn't in fact helping you find out
how your application will work once you do this -- and you are the only
one in a position to do this work.

[John Harrison]

"Miro Jurisic" <macdev@meeroh.org> wrote in message
news:macdev-CACE8E.13373204092003@senator-bedfellow.mit.edu...

> In article <bj6k5k$fhq22$1@ID-196037.news.uni-berlin.de>,
> "John Harrison" <john_andronicus@hotmail.com> wrote:
>

> > "Miro Jurisic" <macdev@meeroh.org> wrote in message
> > news:macdev-58C337.19282403092003@senator-bedfellow.mit.edu...

> > > In article <bj5nfs$ff31e$1@ID-196037.news.uni-berlin.de>,
> > > "John Harrison" <john_andronicus@hotmail.com> wrote:
> > >
> > > > What I need is something that will suspend my application for a

given

> > > > period (a few seconds) then carry on processing, a simple linear
> > > > sequence. It is not an option when I need this delay to happen to

return

> > > > to the main event processing loop, it would be too difficult in that
> > > > circumstance to pick up processing where it was left off before the

delay

> > > > happened.
> > >
> > > It is simply impossible to do what you are trying to do on Mac OS 9.

In

> > > order to suspend an application you have to use an event loop, however
> > > trivial that loop may be, and in that loop you must handle
> > > activate/deactivate and suspend/resume events. If you do not handle

those

> > > events correctly, the Process Manager will get mighty confused if the

user

> > > clicks on a window in another application.
> > >
> > > Please read <http://developer.apple.com/qa/ps/ps06.html>

> >
> > Thanks, that's the sort of information I needed. I'm still unclear about
> > suspend and resume events though. What do I actually have to do to

handle a

> > suspend or resume event, in order to avoid the bad things that the web

page

> > mentions.

>
> That would be covered by any book which covers basic Mac OS 9 event

handling.

> <http://www.mactech.com/macintosh-c/classic-chap02-1.html> offers a good

overview,

> among others.
>

> > The web page does not mentions activate/deactivate events however, is

that

> > simply an omission?

>
> I believe that a failure to handle activate/deactivate is cosmetic,

whereas a

> failure to handle suspend/resume/update is much more serious, hence that

Q&A

> only discusses the latter.
>
> hth
>

It does indeed. I don't think I've ever written a Mac application just
tinkered with ones that others have written. So basic stuff like how to
handle events is new to me.

I must say though that event handling on the Mac seems really bizarre. You
are expected to do all sorts of things in a standard or semi standard way.
Wouldn't it be easier if the OS did those things for you? Then you can just
write the bits of code that really are unique to your application. It would
also mean more consistency across Mac applications, and presumably fewer
bugs from incompetents like me.

john