Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MacroMaker does strange things to the system...
Message-ID: <7459@hoptoad.uucp>
Date: 26 May 89 19:09:01 GMT
References: <789@tekno.chalmers.se>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 50

In article <789@tekno.chalmers.se> d83_sven_a@tekno.chalmers.se
(Sven (Sciz) Axelsson) writes:
>THE SCENARIO: I am hacking on a DA which will utilize the journaling mechanism.
>Today I pulled all parts together and everything ought to work just fine...
>I compile etc. and open the DA - it runs wild. It is receiving jRecordCtl calls
>all the time although I can see with MacsBug that JournalFlag is definitely
>zero. Huh, what, and why?? After several hours of fruitless search for some
>bug in my program I realized - MacroMaker! Throw MacroMaker out and - low and
>behold - now it works perfectly.

Don't be too hard on MacroMaker.  It's a damn fine product, even if it
does stick its grubby little fingers into everything.  (You would not
believe how many traps it patches!)  Journaling is a very minor feature
used by few applications, and it's not too surprising that it might not
work exactly as advertised on all future supported Mac configurations.

However, I do have a problem with one part of your description.  Why
are you setting JournalRef when JournalFlag is zero?  If you make sure
that you don't have your device driver's reference number in JournalRef
when JournalFlag is zero, then you should not have this problem.  I
would recommend saving the old value of JournalRef when you set
JournalFlag to non-zero, then restoring the old value when you set
JournalFlag to zero.  This should insure that you get all (and only)
the events you want, while MacroMaker gets all (and only) the events
that it wants.  Pretty easy work-around; I haven't tried it, but I
don't see how it could fail to work.  Any problem that has an easy
work around and breaks hardly any existing software is not quite as
serious as you're making it out to be.

>QUESTION: Why is it that Apples own programs always breaks all Apples own
>programming guidelines? Other macromaking utilities (such as QuicKeys) can
>manage without disrupting the journaling mechanism.

I sympathize.  The reason is that they think they can get away with
it.  It's a well-known fact that Apple's own software is often the
least compatible with system software revisions (and the same goes, I
understand, for high-ranking Apple alumni like Andy Hertzfeld), and it
is a problem.  But in this case, it's not really a serious one.

If I had to guess at the reason for this particular inconsistency, I'd
say that it has to do with the fact that the journaling low-memory
globals are part of the Switcher globals set that MultiFinder also
switches, while (as you may have noticed) MultiFinder will happily
switch between application layers and proceed correctly during the
recording or execution of a macro.  This is a guess and should not be
taken for fact.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Americans will buy anything, as long as it doesn't cross the thin line
 between cute and demonic." -- Ian Shoales