oster@dewey.soe.berkeley.edu (David Phillip Oster) (11/07/89)
TextEdit hides the mouse cursor by calling ObscureCursor(). My testers have complained that the cursor doesn't re-appear until they move the mouse. The only solution I could come up with is to call InitCursor(). Is it okay to call InitCursor() whenever you feel like it? What other choice is there if you care about this point? > The mac is a detour in the inevitable march of mediocre computers. > drs@bnlux0.bnl.gov (David R. Stampf) --- David Phillip Oster -master of the ad hoc odd hack. Arpa: oster@dewey.soe.berkeley.edu Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
wdh@well.UUCP (Bill Hofmann) (11/09/89)
In article <32409@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu (David Phillip Oster) writes: >TextEdit hides the mouse cursor by calling ObscureCursor(). My testers >have complained that the cursor doesn't re-appear until they move the >mouse. The only solution I could come up with is to call InitCursor(). Is >it okay to call InitCursor() whenever you feel like it? What other choice >is there if you care about this point? It's just fine to call InitCursor whenever you please, note however that it sets the cursor to the arrow cursor, so you may want to do a SetCursor immediately after this. BTW, there is some logical sense to doing an ObscureCursor, basically so the user can see what s/he's typing. I agree that it is confusing to lose it, but your testers are the first people I've heard complain enough to make a difference. -Bill
oster@dewey.soe.berkeley.edu (David Phillip Oster) (11/09/89)
I was a little too terse in my first posting on this topic. I'll try again to make the problem clear. You are typing at a dialog. The mouse cursor has vanished, as the User Interface Guidlines inteded, because TextEdit() calls ObscureCursor(). Now, the user hits the <return> key. Since this dialog has a default action, the dialog vanishes. No text cursor. Also no mouse cursor. Experienced Mac users unconsciously know that if they move the mouse, they'll get a cursor. My testers don't come from the Mac culture and say Bug Report 850:, dialog code 12, code 13, code 14... SetCursor() doesn't show the cursor. RevealCursor() doesn't show the cursor. Nothing undoes ObscureCursor() except InitCursor(), which also has the side effect of making the cursor be the arrow. Those who have responded to me by mail have assured me that calling InitCursor() more than once isn't a problem, but I want reassurance from Apple. Yes, it is a finicky detail, but finicky details are important. A little background: This program changes the mouse cursor to an i-beam if it is over a text edit dialog item, even in SFPutFile(). It provides cut/copy/paste AND UNDO in every dialog, even SFPutFile(). My testers have sent me bug reports that I've tracked down to Apple bugs in TEUpdate(), TEGetOffset(), and PtrAndHand(). (I've filed bug reports on these with apple over MCI mail.) My testers also filed a bug report with me that my program didn't tell them that they'd turned off their imagewriter. (For those who don't know, a turned off imagewriter sends a continuous "ready" signal to the Mac's serial port.)