Professional Web Applications Themes

wait loop - Mac Programming

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?...

  1. #1

    Default wait loop

    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?



    John Harrison Guest

  2. #2

    Default Re: wait loop

    In article <bj2c60$e1rbc$1ID-196037.news.uni-berlin.de>,
    "John Harrison" <john_andronicushotmail.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.
    David Phillip Oster Guest

  3. #3

    Default Re: wait loop

    In article <oster-1736F3.18480202092003news.sf.sbcglobal.net>,
    David Phillip Oster <osterieee.org> wrote:
    > In article <bj2c60$e1rbc$1ID-196037.news.uni-berlin.de>,
    > "John Harrison" <john_andronicushotmail.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.
    Michael Ash Guest

  4. #4

    Default Re: wait loop


    "David Phillip Oster" <osterieee.org> wrote in message
    news:oster-1736F3.18480202092003news.sf.sbcglobal.net...
    > In article <bj2c60$e1rbc$1ID-196037.news.uni-berlin.de>,
    > "John Harrison" <john_andronicushotmail.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


    John Harrison Guest

  5. #5

    Default Re: wait loop

    In article <bj3u6t$elpgh$1ID-196037.news.uni-berlin.de>, John Harrison
    <john_andronicushotmail.com> wrote:
    > "David Phillip Oster" <osterieee.org> wrote in message
    > news:oster-1736F3.18480202092003news.sf.sbcglobal.net...
    > > In article <bj2c60$e1rbc$1ID-196037.news.uni-berlin.de>,
    > > "John Harrison" <john_andronicushotmail.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?
    David C. Stone Guest

  6. #6

    Default Re: wait loop

    In article <bj3u6t$elpgh$1ID-196037.news.uni-berlin.de>, John Harrison
    <john_andronicushotmail.com> wrote:
    > "David Phillip Oster" <osterieee.org> wrote in message
    > news:oster-1736F3.18480202092003news.sf.sbcglobal.net...
    > > In article <bj2c60$e1rbc$1ID-196037.news.uni-berlin.de>,
    > > "John Harrison" <john_andronicushotmail.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/doentation/Carbon/EventsOtherInput-date.h[/url]
    tml#//apple_ref/doc/uid/TP30000420-TP30000447>

    and especially:

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


    -=-=-=-=-
    Carl R. Osterwald Guest

  7. #7

    Default Re: wait loop

    In article <bj3u6t$elpgh$1ID-196037.news.uni-berlin.de>,
    "John Harrison" <john_andronicushotmail.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?
    Michael Ash Guest

  8. #8

    Default Re: wait loop

    In article <030920030739045982%imac.com>,
    "Carl R. Osterwald" <imac.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/doentation/Carbon/EventsOtherInput-date.h[/url]
    > tml#//apple_ref/doc/uid/TP30000420-TP30000447>
    >
    > and especially:
    >
    > <[url]http://developer.apple.com/doentation/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.)
    David Phillip Oster Guest

  9. #9

    Default Re: wait loop


    "Michael Ash" <mailmikeash.com> wrote in message
    news:mail-B699DC.12344703092003localhost...
    > In article <bj3u6t$elpgh$1ID-196037.news.uni-berlin.de>,
    > "John Harrison" <john_andronicushotmail.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


    John Harrison Guest

  10. #10

    Default Re: wait loop

    In article <bj5nfs$ff31e$1ID-196037.news.uni-berlin.de>,
    "John Harrison" <john_andronicushotmail.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 cirstance 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>

    Miro Jurisic Guest

  11. #11

    Default Re: wait loop

    In article <bj5nfs$ff31e$1ID-196037.news.uni-berlin.de>,
    "John Harrison" <john_andronicushotmail.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.
    Michael Ash Guest

  12. #12

    Default Re: wait loop


    "Miro Jurisic" <macdevmeeroh.org> wrote in message
    news:macdev-58C337.19282403092003senator-bedfellow.mit.edu...
    > In article <bj5nfs$ff31e$1ID-196037.news.uni-berlin.de>,
    > "John Harrison" <john_andronicushotmail.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 cirstance 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 Guest

  13. #13

    Default Re: wait loop


    "Michael Ash" <mailmikeash.com> wrote in message
    news:mail-B0932D.22063703092003localhost...
    > In article <bj5nfs$ff31e$1ID-196037.news.uni-berlin.de>,
    > "John Harrison" <john_andronicushotmail.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


    John Harrison Guest

  14. #14

    Default Re: wait loop

    In article <bj6kad$g3fso$1ID-196037.news.uni-berlin.de>, John Harrison
    <john_andronicushotmail.com> wrote:
    > "Michael Ash" <mailmikeash.com> wrote in message
    > news:mail-B0932D.22063703092003localhost...
    > > In article <bj5nfs$ff31e$1ID-196037.news.uni-berlin.de>,
    > > "John Harrison" <john_andronicushotmail.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.
    David C. Stone Guest

  15. #15

    Default Re: wait loop

    In article <040920031055550590%no.emailexample.com>,
    "David C. Stone" <no.emailexample.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.
    Tom Dowdy Guest

  16. #16

    Default Re: wait loop

    In article <dowdy-C49F08.08402304092003news.apple.com>, Tom Dowdy
    <dowdyapple.com> wrote:
    > In article <040920031055550590%no.emailexample.com>,
    > "David C. Stone" <no.emailexample.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
    David C. Stone Guest

  17. #17

    Default Re: wait loop


    "Tom Dowdy" <dowdyapple.com> wrote in message
    news:dowdy-C49F08.08402304092003news.apple.com...
    > In article <040920031055550590%no.emailexample.com>,
    > "David C. Stone" <no.emailexample.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


    John Harrison Guest

  18. #18

    Default Re: wait loop

    In article <bj6k5k$fhq22$1ID-196037.news.uni-berlin.de>,
    "John Harrison" <john_andronicushotmail.com> wrote:
    > "Miro Jurisic" <macdevmeeroh.org> wrote in message
    > news:macdev-58C337.19282403092003senator-bedfellow.mit.edu...
    > > In article <bj5nfs$ff31e$1ID-196037.news.uni-berlin.de>,
    > > "John Harrison" <john_andronicushotmail.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
    > > > cirstance 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>

    Miro Jurisic Guest

  19. #19

    Default Re: wait loop

    In article <bj7p62$fv9gq$1ID-196037.news.uni-berlin.de>,
    "John Harrison" <john_andronicushotmail.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.
    Tom Dowdy Guest

  20. #20

    Default Re: wait loop


    "Miro Jurisic" <macdevmeeroh.org> wrote in message
    news:macdev-CACE8E.13373204092003senator-bedfellow.mit.edu...
    > In article <bj6k5k$fhq22$1ID-196037.news.uni-berlin.de>,
    > "John Harrison" <john_andronicushotmail.com> wrote:
    >
    > > "Miro Jurisic" <macdevmeeroh.org> wrote in message
    > > news:macdev-58C337.19282403092003senator-bedfellow.mit.edu...
    > > > In article <bj5nfs$ff31e$1ID-196037.news.uni-berlin.de>,
    > > > "John Harrison" <john_andronicushotmail.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
    > > > > cirstance 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


    John Harrison Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. Loop option set, but flash doesn't loop
    By uj666 in forum Macromedia Flash Player
    Replies: 6
    Last Post: October 21st, 04:23 AM
  2. Can a film loop play once, then loop on the last frame(s)?
    By Schiemer webforumsuser@macromedia.com in forum Macromedia Director Lingo
    Replies: 0
    Last Post: November 29th, 03:35 AM
  3. Film loop rollovers working with tell sprite, but only if Loop is checked
    By Schiemer webforumsuser@macromedia.com in forum Macromedia Director Basics
    Replies: 0
    Last Post: November 27th, 06:02 AM
  4. In loop wait for function return
    By mUs in forum PERL Miscellaneous
    Replies: 3
    Last Post: August 10th, 09:24 AM
  5. Urgent: Repeat loop and Film loop clash!
    By Jai G in forum Macromedia Director Lingo
    Replies: 4
    Last Post: July 31st, 04:39 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139