home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / amiga / programm / 13102 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  2.2 KB
  1. Path: sparky!uunet!cs.utexas.edu!torn!utzoo!censor!comspec!nsq!entity
  2. From: entity@nsq.uucp (cybernetworx)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Locking Window Input -- How?
  5. Message-ID: <322@nsq.uucp>
  6. Date: 4 Sep 92 14:23:52 GMT
  7. References: <302@nsq.uucp> <sysop.0csc@alphanet.alphanet.ch> <318@nsq.uucp> <34822@cbmvax.commodore.com>
  8. Organization: NSQ
  9. Lines: 31
  10.  
  11. In article <34822@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes:
  12. > 
  13. > If you care to elaborate on the effect you wish to achieve, someone might
  14. > help you with a system-friendly and user-friendly approach.
  15.  
  16. Sure.  All I wanted to do was open up a window on top of a foreign
  17. applications screen and not pass control back to the foreign program until I
  18. have closed my window.  I want it to work under 1.3 as well so public screens
  19. etc are out of the question anyhow.
  20.  
  21. Why do I want to do this?  Essentially I'm writing a patch that will give the
  22. user an easy way to dynamically change the palette per scanline while using
  23. another program such as Dpaint or DigiPaint.  I need to do all kinds of low
  24. level messing around anyhow just to ensure that the system likes my custom
  25. copperlist and to maintain current resolutions/modes etc.  I could go the easy
  26. route and simply disable multitasking while my code is going, but I wanted to
  27. keep multitasking alive and so I'm doing the 'hardware level/system friendly'
  28. approach ;-)  For game and demo designers, this program would be invaluable. 
  29. I can just imagine all the agony the artist for 'agony/psygnosis' went through
  30. without a utility such as this :)
  31.  
  32. If you have any ideas on how to lock the window input to only MY window then
  33. great -- email me the solution.  Requestors are not a viable solution.  I
  34. don't mind setfunctioning etc. because I already have a VB interrupt which
  35. tells me when I'm on my applicaitons screen or not, so I can doa passthrough
  36. when it's not my application, and otherwise intercept it.  I already do this
  37. with CloseScreen() to make sure the application (eg. dpaint) doesnt shut down
  38. while my window is still active.  In other words, I AM trying to make it very
  39. system friendly... just the individual approaches in themselves would normally
  40. not be considered 'good programming practice'.  Such is life.
  41.  
  42.