dillon@CORY.BERKELEY.EDU (Matt Dillon) (06/09/87)
Adding to the discussion of features unknown and unused: 1.2 Supports several new flags for openning screens. One of these is called SCREENQUIET, another is called SCREENBEHIND. SCREENQUIET allows for all the normal screen gadgetry at the top, but makes it invisible so you can still manipulate the screen memory directly without intuition screwing you up!! Please use it!... I'm getting sick and tired of screens which don't allow me to pull them down, or move them to the back. Although I can get back to my workbench screen easily enough, I need to use one of those hot key utilities to get to other screens I have lying about. Use it or Loose it, -Matt
avery@puff.WISC.EDU (Aaron Avery) (06/09/87)
In article <8706090257.AA22852@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > Adding to the discussion of features unknown and unused: > > 1.2 Supports several new flags for openning screens. One of these is > called SCREENQUIET, another is called SCREENBEHIND. SCREENQUIET allows > for all the normal screen gadgetry at the top, but makes it invisible so > you can still manipulate the screen memory directly without intuition screwing > you up!! > I do use it in my application. It works fine for having a window and screen sharing memory. If you have the window covering up the screen's title bar, normally, (w/o SCREENQUIET) when you hit the menu button, the screen's title will be rendered into its bitmap. This problem is fixed with SCREENQUIET. However, if you have a window and screen sharing display memory, and you let the screen's title bar show on top of the window, hitting the menu button will still cause rendering to stay in the display. To fix the problem of not being able to push the screen to the back, I hooked a couple of invisible boolean gadgets to my window in the appropriate places and call ScreenToBack() and ScreenToFront() when they're hit. You still can't drag it down, but if you want the workbench and it (a terminal program) on the display at the same time, you can drag the workbench down. Aaron Avery ({seismo,caip,allegra,harvard,ihnp4}!uwvax!puff!avery) (avery@puff.wisc.edu)
cmcmanis%pepper@Sun.COM (Chuck McManis) (06/09/87)
In article <795@puff.WISC.EDU> avery@puff.WISC.EDU (Aaron Avery) writes:
< ... To fix the problem of not
< being able to push the screen to the back, I hooked a couple of invisible
< boolean gadgets to my window in the appropriate places and call ScreenToBack()
< and ScreenToFront() when they're hit. You still can't drag it down, but if
< you want the workbench and it (a terminal program) on the display at the same
< time, you can drag the workbench down.
< Aaron Avery ({seismo,caip,allegra,harvard,ihnp4}!uwvax!puff!avery)
May I suggest you also put an invisible 'FOLLOWMOUSE' type gadget in the
window, and call ScreenMove() when the user moves it ? That would seem
to solve all of the 'problems' associated with screens and titles no?
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.rokicki@rocky.UUCP (06/10/87)
In article <20733@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > May I suggest you also put an invisible 'FOLLOWMOUSE' type gadget in the > window, and call ScreenMove() when the user moves it ? That would seem > to solve all of the 'problems' associated with screens and titles no? ScreenMove based on mouse events fails, because of the asynchronous nature of the message passing, and the fact that MouseMove are relative to the current screen. Recommendation (to Avery): allow at least a pixel of the screen to be accessed; put a resizing gadget if you *need* the full height. -tom