marty@june.cs.washington.edu (Marty Sirkin) (01/19/89)
I am a brand new Mac programmer with a very strange problem. I wrote a simple program shell (in Think Pascal) to do basic menu/window/mouse/keyboard interface. Some of the code was taken from the Chernicoff (sp?) book, and some is my own. I wrote the program shell on a Mac 2, and it worked just fine. I have discovered, though, that it does have a problem running on other machines (I've tried it on two Mac Se, and two other Mac 2's). The program itself (run either as an application, or in the compiler's integrated environment) runs just great. When I leave it, however, double cliking for ALL other programs is disabled. Single clicking and menu clicks (also single) work just great. I don't know enough about the machine architecture to even have a guess where to start. It seems to me that there must be something that I am doing in the program, yet the shell is very simple. Also, I thought it might have something to do with a special resource which only likes the machine on which it is compiled, but I compiled a new copy on a different machine - same problem. Any help would be greatly appreciated, either by posting, or by E-mail. Thanks, Marty Sirkin marty@june.cs.washington.edu
dan@lclark.UUCP (Dan Revel) (01/20/89)
In article <6977@june.cs.washington.edu> marty@june.cs.washington.edu (Marty Sirkin) writes: >I wrote [a] program ... on a Mac [II], and it worked ... fine. [But] it [has] >a problem running on other machines [SEs, +s]. The program runs ... great. >When I leave it, however, double cliking for ALL other programs is disabled. >Single clicking and menu clicks (also single) work just great. > Thanks, > Marty Sirkin I've experienced what I think is the same problem. I developed a program on the Mac II which works just fine there but which disables double clicking in the Finder after it is used on other Macs. Sorry Marty, I don't know why this happens either, but I sure would like to find out! As in Marty's case I used Chernicoff's 'Macintosh Revealed' as a starting point, perhaps there's something there since things which I have written using MacApp don't have this difficulty. (By the way I'm using MPW Pascal) Inquiring minds want to know! -- dan@lclark tektronix!reed!lclark!dan Dylsexics untie! (-|
jackiw@cs.swarthmore.edu (Nick Jackiw) (01/20/89)
In article <6977@june.cs.washington.edu> marty@june.cs.washington.edu (Marty Sirkin) writes: > I am a brand new Mac programmer with a very strange problem. > The program itself > (run either as an application, or in the compiler's integrated environment) > runs just great. When I leave it, however, double cliking for ALL other > programs is disabled. Single clicking and menu clicks (also single) work > just great. > > Any help would be greatly appreciated, either by posting, or by E-mail. > > Thanks, > Marty Sirkin > marty@june.cs.washington.edu From tech note #202, revised December 1988: "..._Finder Anomaly_... When MultiFinder is disabled, users will notice a strange behaviour in the Finder (versions 6.0 and later) after quitting applications which fail to restore the event mask. If an application failed to restore the event mask when quitting and had set the event mask to mask out mouse-up events, all mouse-up events would continue to be masked out, and the user would notice that the Finder no longer recognizes double clicks. ..." Could this be your problem? If you fool with the event mask, be sure to set it back to its default. E-Mail me for more details if this sounds promising but isn't detailed enough to solve your problem. -Nick -- +-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+ | nicholas jackiw | jackiw%campus.swarthmore.edu@swarthmr.bitnet | +-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+ PER ASPERA AD ASTRA
billkatt@sol.engin.umich.edu (Steve Bollinger) (01/20/89)
In article <379@lclark.UUCP> dan@lclark.UUCP (Dan Revel) writes: >In article <6977@june.cs.washington.edu> marty@june.cs.washington.edu (Marty Sirkin) writes: >>I wrote [a] program ... on a Mac [II], and it worked ... fine. [But] it [has] >>a problem running on other machines [SEs, +s]. The program runs ... great. >>When I leave it, however, double cliking for ALL other programs is disabled. >>Single clicking and menu clicks (also single) work just great. >> Thanks, >> Marty Sirkin > You are setting the event mask to mask mouse-up events. The reason that "it works on a Mac II" is probably because you ran it under Multifinder on the II, and Multifinder resets the event mask when your program ends. Put this at the end of your program to fix the problem: SetEventMask(everyEvent-MouseUpMask) or better yet, don't set the mask on entry. +----------------------+----------------------------------------------------+ | Steve Bollinger | Internet: billkatt@caen.engin.umich.edu | | 4297 Sulgrave Dr. +------+---------------------------------------------+ | Swartz Creek, Mi. 48473 | "My employer doesn't take my opinion any | +-----------------------------+ more seriously than you do." | | "You remember the IIe, it +---------------------------------------------+ | was the machine Apple made before they decided people didn't need | | machines with big screens, color, or slots." | | - Harry Anderson (from NBC's Night Court) | +---------------------------------------------------------------------------+
ra_robert@gsbacd.uchicago.edu (01/21/89)
In article <379@lclark.UUCP>, dan@lclark.UUCP (Dan Revel) writes... >In article <6977@june.cs.washington.edu> marty@june.cs.washington.edu (Marty Sirkin) writes: >>I wrote [a] program ... on a Mac [II], and it worked ... fine. [But] it [has] >>a problem running on other machines [SEs, +s]. The program runs ... great. >>When I leave it, however, double cliking for ALL other programs is disabled. >>Single clicking and menu clicks (also single) work just great. >> Thanks, >> Marty Sirkin > >I've experienced what I think is the same problem. I developed a program >on the Mac II which works just fine there but which disables double clicking >in the Finder after it is used on other Macs. Chernicoff's program has several bugs in it, and this is a manifestation of one of them. I think he sets the event mask (filtering out mouseUp ?) and it never gets reset. Something like that. Anyway, the behavior is traceable to Chernicoff's program (sorry, but I saw this on the net a while ago and don't remember exactly what the problem with the event mask was). Robert ------ ra_robert@gsbacd.uchicago.edu ------ generic disclaimer: all my opinions are mine
jcl@hpausla.HP.COM (Jeff Laing) (01/24/89)
In article <379@lclark.UUCP>, dan@lclark.UUCP (Dan Revel) writes... > Chernicoff's program has several bugs in it, and this is a manifestation > of one of them. I think he sets the event mask (filtering out mouseUp ?) One of the saddest realizations I had was that even Chernicoff's code had bugs in it; I found it out the easy way, by reading it in as I typed it (yes, I had to type from the book). Its also amazing how much other source code I have seen floating around that has the same problem. So, in the interest of letting someone else avoid a problem that 'nearly' got me. You really need to watch those handles being locked and unlocked a lot. The number of times I have seen ... a() { HLock(h); b(h); *h->x = ... /* this would no survive a heap scramble */ HUnlock(h); } b(h) Handle h; { HLock(h); ... HUnlock(h); } (Yeh, yeh, Chernicoff was in pascal. But I'm in C-mode at the moment and you get my point anyway ...)
dwb@Apple.COM (David W. Berry) (02/05/89)
In article <2580011@hpausla.HP.COM> jcl@hpausla.HP.COM (Jeff Laing) writes: >In article <379@lclark.UUCP>, dan@lclark.UUCP (Dan Revel) writes... >> Chernicoff's program has several bugs in it, and this is a manifestation >> of one of them. I think he sets the event mask (filtering out mouseUp ?) > >One of the saddest realizations I had was that even Chernicoff's code had >bugs in it; I found it out the easy way, by reading it in as I typed it (yes, >I had to type from the book). Its also amazing how much other source code >I have seen floating around that has the same problem. So, in the interest >of letting someone else avoid a problem that 'nearly' got me. > >You really need to watch those handles being locked and unlocked a lot. The >number of times I have seen ... > >a() >{ > HLock(h); > b(h); > *h->x = ... /* this would no survive a heap scramble */ > HUnlock(h); >} > >b(h) >Handle h; >{ > HLock(h); > ... > HUnlock(h); >} Something that I don't believe is very explicitly spelled out in Inside Mac, although it is mentioned several times is that you really do want to restore the previous lock state. Most times your code should look like: short state = HGetState(handle); HLock(handle); ... HSetState(handle, state); That way you get to make sure it's locked and at the same time don't destroy anybody else's notion that it's locked. Opinions: MINE, ALL MINE! (greedy evil chuckle) David W. Berry apple!dwb@sun.com dwb@apple.com 973-5168@408.MaBell
jkjl@munnari.oz (John Lim) (02/06/89)
> Something that I don't believe is very explicitly spelled out >in Inside Mac, although it is mentioned several times is that you really >do want to restore the previous lock state. Most times your code should >look like: > > short state = HGetState(handle); > > HLock(handle); > ... > HSetState(handle, state); > >That way you get to make sure it's locked and at the same time don't destroy >anybody else's notion that it's locked. > >David W. Berry >apple!dwb@sun.com dwb@apple.com 973-5168@408.MaBell You only need to do something like this for shared resources like those from the System File or when you have IPC. Otherwise checking the Resource Bits is not really necessary. The normal HLock-HUnlock pair of traps is satisfactory for most circumstances. john lim ---------------- lineeater lineeater lineeater lineeater lineeater lineeater lineeater lineeater lineeater lineeater lineeater lineeater lineeater lineeater lineeater
jcl@hpausla.HP.COM (Jeff Laing) (02/07/89)
David W. Berry (dwb@Apple.COM) writes in comp.sys.mac.programmer:
! In article <2580011@hpausla.HP.COM> jcl@hpausla.HP.COM (Jeff Laing) writes:
! > [ my example program deleted from sheer modesty 8-) ]
!
! Something that I don't believe is very explicitly spelled out
! in Inside Mac, although it is mentioned several times is that you really
! do want to restore the previous lock state. Most times your code should
! look like:
! short state = HGetState(handle);
! HLock(handle);
! ...
! HSetState(handle, state);
!
! That way you get to make sure it's locked and at the same time don't destroy
! anybody else's notion that it's locked.
Good in theory, but unfortunately HGetState isn't in the Inside Macintosh that
I use (the old phone book). This raises another issue.
In an attempt to remain compatible with all those 'little brother' Macintoshes
(you know, back before we all had less than 1 meg), I have been trying to avoid
using these newer traps as much as possible. Of course, every so often you
don't have a choice, and have to use (GetTrapAddress() != Unimplemented),
and perform a fiddle (as David Oster has pointed out previously).
Also, I hate the look of my program(s) that have to rush around ensuring that
all the services that they might call are actually there at startup.
Especially as the list seems to be growing as an attempt to be robust.
Is there a(n accurate) list of new traps and the System/Finder combination that
they arrived with? That way, you can stand a chance of telling people that
'this program requires at least System 3.2x to run' I can't afford to keep
a copy of every System/Finder around on diskette, even if I could actually
find them ...
Similiarly, I know that Lightspeed C generates inline HGetState() traps which
means I have to write glue to wrap around it to be safe on old Macs; has any
one sat down and written their own GluedMacTraps that sits over MacTraps
somehow and hides all those incorrect traps? Is it even possible?