TweetFollow Us on Twitter

Jan 98 - Tips

Volume Number: 14 (1998)
Issue Number: 1
Column Tag: Tips & Tidbits

Jan 98 - Tips and Tidbits

by Steve Sisak

Here is a tip about the use of the GetScrap Scrap Manager trap. When your application is starting up, you may want to check the contents of the scrap or transfer it into your private scrap. However, you should be careful not to call GetScrap until after you've made a couple calls to WaitNextEvent.

This delay is required to allow the Process Manager to move the contents of the clipboard from the previously active application into your application's process context. Also, don't forget that TEFromScrap is just a wrapper around GetScrap, and has the same requirement.

Here is some code to illustrate the problem. Don't do this:

    InitGraf(&qd.thePort);
    ...
    InitDialogs(0);
    TEFromScrap();
 
    for (;;)
       WaitNextEvent(...);

Instead, do something like this:

    switch (event.what)
    {
       case nullEvent:
       {
          static int      idleCount;
          static Boolean      gotBootScrap;
 
          if (++idleCount == 3 && !gotBootScrap)
          {
             TEFromScrap();
             gotBootScrap = true;
          }
       }
    }

You're probably wondering why the Process Manager doesn't just set up the scrap correctly when it launches a new application? Actually it can't because the current application might have data in a private scrap, which won't be moved into the system scrap until that application receives a suspend event. The suspend event won't be received, however, until after the LaunchApplication trap has created the new process and returned back to the caller. The Process Manager has to wait until the original frontmost application has received that suspend event before it can safely move the contents of the system scrap into the launched application's context.

Eric Schlegel
ericsc@apple.com

"Rather than trying to guess how many nullEvents to wait for, it may be more reliable to hold off importing the scrap (and other initialization) until you receive your first Apple event. That first Apple event will be either 'aevt'/'oapp', 'aevt'/' odoc', or 'ascr'/' noop' and will not be sent until the Process Manager has fully suspended the previous frontmost application."

--ed sgs

Eric replys: "That would have the same effect. It might not always be a better choice than just waiting for the null events, though, depending on whether you already have Apple event handlers. Stickies opens its data file immediately without waiting for an oapp event, so for Stickies and similar apps it makes sense to just use the idle count." --eric

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

Latest Forum Discussions

See All


Price Scanner via MacPrices.net


Jobs Board

All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.