User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
Eric Schlegel wrote:
Since Carbon does not support automatic cursor switching, let's
consider approaches that allow you to do it manually. It does seem to
me that you could implement this quite easily using two event handlers
for kEventWindowCursorChange and kEventMouseMoved. Install these on the
application event target. When you get the CursorChange event, check
the window parameter in the event; if it's the window that should hide
the mouse, then hide it with HideCursor(). When you get the MouseMoved
event, you'll know that the mouse is not over one of your windows, so
you can show the cursor with ShowCursor(). I wrote a quick test app
that does this and, at a first approximation, it seems to work pretty
well.
Thanks, this seems a pretty reasonable approach. Unfortunately
the application is not arranged to service events once the window
has been painted with a test color. This doesn't cause
problems, because the windows class and attributes make
it have a fixed position, it is over any other window, and
doesn't need to be accessed by the user at all.
The process is waiting for the instrument to reply, or the
user to hit a key on stdin indicating an abort. I not sure
I want to add a separate thread to service window events to
track the cursor, although I may look into how complicated it would be.
You mentioned in a previous message that when you clicked in the
window, the cursor became visible again.
Sorry, I wasn't very specific. The cursor disappears as soon as
my application starts (it having done a HideCursor()), so if
I want to abort the application I have to select the terminal
window it was started from, so I click the mouse button,
and the cursor appears again. Probably the pointer wasn't
located in the application window when it was clicked,
which presumably explains why the cursor appears - the
HideCursor() only applied to the application thread,
not other threads (I'm guessing. The HideCursor() documentation
doesn't explain these sort of details, but the lack of any
arguments is suspicious)
> I didn't see that problem for
normal clicks in my test window, but I was just using standard
HIToolbox controls. What kind of content does your window use -
standard controls, or your own custom content?
No controls, it's just a color test window. There are no other
GUI elements, as the application is controlled from a terminal.
Thanks for your suggestions.
Graeme Gill.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartz-dev/email@hidden
