d83_sven_a@tekno.chalmers.se (Sven (Sciz) Axelsson) (05/25/89)
I've spent most of the day tearing my hair in dispair for a - thought I - utterly unbelievable bug. This was not so, however... 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. 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. UNRELATED QUESTION: The reason for me using MacroMaker instead of QuicKeys in the first place was that I couldn't get QuicKeys to define a macro in the DA-Handler layer only (MacroMaker can do this). Is there a way to do this with QuicKeys that I've missed? +-------------------------+--------------------------------+------------------+ | Sven Axelsson | d83_sven_a@tekno.chalmers.se | DISCLAIMER: | | dep:t of Linguistics | (^^ best ^^) | | | univ. of Gothenburg | dlv_sa@hum.gu.se | This is not | | SWEDEN | usdsa@seguc21.bitnet | a disclaimer. | +-------------------------+--------------------------------+------------------+
tim@hoptoad.uucp (Tim Maroney) (05/27/89)
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
flash@cs.qmc.ac.uk (Flash Sheridan) (05/28/89)
In article <789@tekno.chalmers.se> d83_sven_a@tekno.chalmers.se (Sven (Sciz) Axelsson) writes: > >UNRELATED QUESTION: The reason for me using MacroMaker instead of QuicKeys in >the first place was that I couldn't get QuicKeys to define a macro in the >DA-Handler layer only (MacroMaker can do this). Is there a way to do this >with QuicKeys that I've missed? > No, not even in 1.2; we've been discussing this in comp.sys.mac. It was a very convenient upgrade which ignored the two most important UI bugs. [Of course, if it weren't so good overall I wouldn't be flaming its sloppiness.] -- --- From: flash@cs.qmc.ac.uk (Flash Sheridan) Reply-To: sheridan@nsfnet-relay.ac.uk Portal,MacNet: FlashsMom
tecot@Apple.COM (Ed Tecot) (06/09/89)
In article <7459@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <789@tekno.chalmers.se> d83_sven_a@tekno.chalmers.se >(Sven (Sciz) Axelsson) writes: >>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. And I'd argue that it's not one at all... Journaling was built with macros in mind (and guided tours, but I digress). It's foolish to assume that you are the only one using a given service in the Macintosh. Always be prepared to share. _emt
tim@hoptoad.uucp (Tim Maroney) (06/10/89)
In article <7459@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >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. In article <32327@apple.Apple.COM> tecot@Apple.COM (Ed Tecot) writes: >And I'd argue that it's not one at all... Journaling was built with macros >in mind (and guided tours, but I digress). It's foolish to assume that you >are the only one using a given service in the Macintosh. Always be prepared >to share. Not quite. Sven's complaint was that the advertised sharing mechanism doesn't work exactly as advertised. It's supposed to work like this: When you set JournalFlag to a positive value, then event recording Control calls will be sent to the driver whose reference number is in JournalRef. However, he was getting events even when JournalFlag is zero, which he deduced to mean (I assume correctly) that MacroMaker was changing the journaling mechanism, not just using it. He does have cause to complain if his deduction is correct. This implies that not only do you have to make sure that JournalFlag is zero before you use the machanism, you have to make sure you don't use JournalRef while JournalFlag is zero. This is not something you would guess from Inside macintosh; the way it reads, you should be able to turn off journaling using JournalFlag only; in fact, you have to set both JournalFlag and JournalRef when MacroMaker is running. However, I pointed out that a simple save/restore strategy on JournalRef ought to eliminate his problem, which is why I feel it's not a serious difficulty. If he makes sure that his driver's reference number is only in JournalRef when he has set JournalFlag to negative or positive, and the rest of the time it's set to whatever it was before he set JournalFlag to non-zero, then he and MacroMaker should be able to happily coexist. Unfortunately, the message may not have reached him -- at least, I haven't heard from him whether this worked or not. That's why I'm repeating it now.... -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 If you vote for clowns, you have no right to complain that only clowns make it to the ballot.