Volume Number: 13 (1997)
Issue Number: 6
Column Tag: develop

Macintosh Q&A

by Apple Developer Support Center

Q: When I used CopyBits to do a screen capture, the cursor isn't included. Why not?

A: CopyBits calls ShieldCursor to hide the cursor before it does its work. That's why you never see the cursor in your screen capture. The following code hides the cursor and decrements the cursor count in the low-memory global to fool CopyBits not to call ShieldCursor. Standard warning: Using low-memory globals is dangerous and is subject to future OS changes.

unsigned char   oldCrsrVis;
short           oldCrsrState;
      
// Hide the cursor.
oldCrsrVis = GetCrsrVis();
oldCrsrState = GetCrsrState();
SetCrsrVis((unsigned char) 0);
SetCrsrState(oldCrsrState - 1);   
// Do the screen capture.
CopyBits(...)
      
// Restore the old cursor.
SetCrsrState(oldCrsrState);
SetCrsrVis(oldCrsrVis);

You should define the cursor functions as follows:

enum {
   CrsrVis = 0x8CC,      // Cursor visible? [byte]
   CrsrState = 0x8D0      // Cursor nesting level [word]
};
   
void SetCrsrVis(unsigned char cursorVisible)   
{
   *(unsigned char*)CrsrVis = cursorVisible;
}

unsigned char GetCrsrVis(void)
{
   return ( *(unsigned char*)CrsrVis );
}   

short GetCrsrState(void)
{
   return ( *(unsigned char*)CrsrState );
}   

void SetCrsrState(short val)
{
   *(unsigned char*)CrsrState = val;
}

Q: How can I determine whether the cursor is hidden?

A: Currently the best way to determine this is to use a low-memory global that has been removed from LowMem.h. The reason it has been removed is that a future operating system may handle it differently.

Using low-memory globals has never really been sanctioned, though they were documented in older interface files. The Universal Interfaces were designed to make way for future operating systems; access to some low-memory globals was provided through accessor functions for safety, while access to others was removed.

The global you want, CrsrVis, is a byte-sized flag that tells whether the cursor is hidden. It was defined in an older interface file like this:

enum {
   CrsrVis = 0x8CC,   // Cursor visible? [byte]
};

You can simply check this global to see if the cursor is hidden. As always, the direct use of low-memory globals is not recommended and will probably cause your code to break in the future.

Q: I want to support dragging from my application to the Trash without having the Finder create a clipping file inside the Trash. I tried several options but they all failed. Is this possible?

A: There is no good way to prevent a clipping file from being created in the Trash, or to prevent the "zoomback" animation that signals a failed drag. The problem is that the Finder treats the Trash like a folder; the drag succeeds or fails according to the user's supposed intent with respect to a folder.

In our opinion, however, this is good, since it's consistent with the Trash metaphor. When the user drags an icon from a Finder window into the Trash, she expects the Trash to get fat so that she can later change her mind, open the Trash, and drag the icon back out. Creating a clipping file in the Trash merely extends the metaphor. The only problem this might cause is that the user ought to be able to reverse her decision and drag the clipping back into the application. If your application doesn't already support this action, you may have some work ahead.

We realize that other applications manage to avoid making the Trash fat. This is, in our opinion, a Bad Thing. A Hack. Wrong. Nevertheless, if you still feel you need to avoid making the Trash fat, it might be possible to do so. It would probably involve creating a file via flavorTypePromiseHFS, then deleting it before the Finder has a chance to make the Trash fat. Unfortunately, since this involves "fooling" the Finder, it isn't likely to work for future versions of the Finder even if it does work today.

In short, this is not recommended.

Q: When my application calls TrackDrag, it crashes in low memory at an illegal instruction. The MacsBug stack crawl doesn't produce any useful information. I've stared and stared at my application's calls to the Drag Manager, and all the parameters appear to be valid. My drag tracking handler is never called, incidentally. If I take all calls to the Drag Manager out of my application, it runs just fine. I've been investigating this crash for two months. Why is life so cruel?

A: You've unearthed a really ugly problem. The Drag Manager thinks the drag originated in the Finder, and makes some fatal assumptions based on that.

Early versions of the Drag Manager did not enjoy the benefits of a drag-enabled Finder, so the Drag Manager plays a little fast and loose with the Finder's jump table. Yes, that means what it sounds like: the Drag Manager calls the Finder routines through its jump table.

The even more interesting story concerns the method by which the Drag Manager decides that the current application is the Finder. When TrackDrag is called, the Drag Manager determines whether the drag originates in any of the windows in the window list of the current process. If not, the Drag Manager determines whether the drag originates in any Finder window. Since the desktop is a "window" for these purposes, there's a large area that qualifies.

Once the Drag Manager has decided the drag originated in a Finder window, it assumes that the Finder is the current process. (This is the fatal mistake.) Once this assumption is made, the next thing for the Drag Manager to do to coax the Finder into exhibiting the correct drag behavior is call an entry in whatever jump table can be found by offsetting the current value of register A5. This is valid if the Finder is the current process, but of course if the current process is your application instead, things go terribly astray: The Drag Manager calls a jump table entry in your application, thinking it's the Finder, and your application's routine doesn't do the same thing that the Finder routine would. Any number of spectacular effects can result.

"Now wait a minute," you're thinking, "the drag originated in one of my application's windows; how is this stuff about the Finder relevant?" The answer is in the event record you're passing to TrackDrag. An event record is supposed to contain a where field expressed in global coordinates. However, the where field your application is passing is in local coordinates. How did this happen? Well, that depends on your application, but often it can result from an application frameworks (like PowerPlant, MacApp, or THINK Class Library) modifying the event record before passing it to your code. There's no language-level way to specify that the record has been modified, so the compiler doesn't warn you. (Honestly, this is Not Your Fault.)

Your code blithely calls TrackDrag with what it assumes is a valid event record but is not. TrackDrag interprets the where field, which is actually in local coordinates, as global coordinates. This point is somewhere up and to the left of where your application expects, and quite often it's in the desktop, which as we said above is considered a Finder window for these purposes. The Drag Manager reacts by going through its ritual for drags originating in Finder windows and eventually crashes after calling some odd routine in your application, as described above.

To solve this problem, simply call LocalToGlobal on the where field of the event record before calling TrackDrag.

Q: When I drag from my application into a Finder window, the system crashes. I notice the Finder uses a windowKind value of 20 for its windows, and so does my application. When my application avoids windowKind 20, everything's hunky-dory. What's going on?

A: Through the Drag Manager, the Finder has gotten access to the windows in your application's window list (specifically, by using undocumented calls to obtain the source window of a drag). If your window's windowKind field is 20, the Finder assumes the window is one of its own (as opposed to a driver window, whose windowKind would be negative, or a dialog window, whose windowKind would be 2, and so on). The Finder grabs the value in the window's refCon field and type-casts it to a pointer to a C++ object in the Finder's heap. I think you can see where this is going: when the Finder attempts to dereference the pointer, many fascinating crashing behaviors can result.

The upshot of this Finder bug is that your application should not use windowKind values of 20.