Jun 97 - Macintosh Q and A
Volume Number: 13
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:
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:
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.