home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / mac / programm / 18256 < prev    next >
Encoding:
Text File  |  1992-11-10  |  1.3 KB  |  31 lines

  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!microsoft!hexnut!ericsc
  3. From: ericsc@microsoft.com (Eric Schlegel)
  4. Subject: Re: Button() not callable from interrupt ?
  5. Message-ID: <1992Nov10.163653.1554@microsoft.com>
  6. Date: 10 Nov 92 16:36:53 GMT
  7. Organization: Microsoft Corporation
  8. References: <ROBERT.92Nov9103642@wsooti11.info.win.tue.nl>
  9. Distribution: comp
  10. Lines: 19
  11.  
  12. In article <ROBERT.92Nov9103642@wsooti11.info.win.tue.nl> robert@wsooti11.info.win.tue.nl (Robert Lukassen) writes:
  13. >I ran into a bit of trouble the other day when I tried to read the state of the
  14. >mouse-button from an interrupt-routine. I know that the state of the button
  15. >is represented by a single bit in some low-memory variable and this works well,
  16. >but why does (the old version of) Inside Macintosh claims that Button() can
  17. >move or purge memory. That is absolutely insane! A simple fetch of a low-memory
  18. >variable can't trigger a memory move or memory purge. What are they doing that
  19. >makes calling Button() so dangerous?
  20.  
  21. Unfortunately, they're checking to see if journalling is on, and if so, making
  22. a call to the journalling driver, which CAN move memory. It's not just a simple
  23. fetch.
  24.  
  25. I had the same problem - currently I'm reading MBState directly, for lack of
  26. a better solution, but I sure wish there was a better way...
  27.  
  28. -eric
  29. ------
  30. My opinions, not Microsoft's.
  31.