peter@sugar.UUCP (Peter da Silva) (09/27/87)
How do you open an invisible window in a screen, like the little window in the corner of the screen uShow uses to emulate a close gadget? Do you have to create a window and copy stuff from the screen's bitmap (I hope not)? Alternatively, how can you get mouse events in a screen? I'm trying to display a screen without copying the bitmap over from an internal buffer. That works... but I also want to get mouse events. Opening a SUPERBITMAP window doesn't work, because that kills the front/back/drag gadgets. Making a small window for the close gadget, and making it superbitmap, and giving it the window's bitmap doesn't work either. What does uShow do? Perhaps a source posting would help, if it's not in assembly... -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
ewhac@well.UUCP (10/01/87)
In article <828@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >How do you open an invisible window in a screen, like the little window >in the corner of the screen uShow uses to emulate a close gadget? Do you >have to create a window and copy stuff from the screen's bitmap (I hope >not)? > >Alternatively, how can you get mouse events in a screen? > I found your question somewhat opaque, but I ran into the same problem recently i.e. needed IntuiEvents, but wanted full control of the screen. I wanted the clipping of several on-screen layers, but wanted IntuiEvents coming out of only one port. What I ended up doing was opening a full-screen BORDERLESS | BACKDROP | SIMPLE_REFRESH window. I then set up my own LayerInfo structure and started making layers. Worked great. The nature of BACKDROP windows also left me with the screen drag bar, which is what I wanted. I'm not sure what your application is, but a BACKDROP | BORDERLESS window should help. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) (10/02/87)
In article <828@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >How do you open an invisible window in a screen, like the little window >in the corner of the screen uShow uses to emulate a close gadget? Do you >have to create a window and copy stuff from the screen's bitmap (I hope >not)? > >Alternatively, how can you get mouse events in a screen? > >I'm trying to display a screen without copying the bitmap over from an >internal buffer. That works... but I also want to get mouse events. I ran into similar problems with my first see-an-ilbm-in-a-screen program. You can build a viewport around an existing bitmap, you can build a screen around an existing bitmap, but you can only open a SuperBitmap window with an existing bitmap. Other windows don't have their own bitmap, and they CLEAR the screen's bitmap under themselves when they are opened. (So, if you HAD your picture in the screen, it's gone after you open the window). My solution was to break out of the ILBM loading procedure when I found the picture size information (BMHD), open an appropriate screen and BORDERLESS|BACKDROP window (with no title, no system gads), do a ShowTitle(screen,false), LoadRGB4 an all black color table, then pass the address of the screen's BitMap structure (and planes) to the loader so it could load the picture there. Then LoadRGB4() the real colors. I faked closegadget, etc. by getting MOUSEBUTTONS events and checking the msg->MouseX and msg->MouseY to see if the mouse was clicked where a closegadget normally is. BTW, You can't get input events from a screen. An alternate suggestion along the tiny window line, would be to build the screen around your BitMap, open a SCREENQUIET screen, save a small square area where the closegadget would be, open a small square BORDERLESS MOUSEBUTTONS events window there, copy the small square of bitmap data to the small window. I don't know how well this will work, just giving you something to try if you are set on building the display around existing in-memory bitplanes. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CATS >>Commodore Amiga Technical Support<< UUCP ...{allegra,ihnp4,rutgers}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
keithd@cadovax.UUCP (Keith Doyle) (10/05/87)
Hey gang, I was wondering what the Commodore approved method for changing
IntuitionBase->MaxXMouse and IntuitionBase->MaxYMouse is, so your pointer
can move wherever needed on an overscan screen. Without modifying them,
the mouse will only move within a 320x200 rectangle within a 352x220
screen. MaxXMouse and MaxYMouse are in the 'Don't you dare mess with these'
section of struct IntuitionBase. Well, ok, I won't mess with them directly,
assuming I have an alternative. All I need to know, is what that alternative
might be.
Keith Doyle
# {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/06/87)
>Hey gang, I was wondering what the Commodore approved method for changing >IntuitionBase->MaxXMouse and IntuitionBase->MaxYMouse is, so your pointer >can move wherever needed on an overscan screen. Without modifying them, >the mouse will only move within a 320x200 rectangle within a 352x220 >screen. What version of the OS are you using? My mouse has no problems with an overscan screen. -Matt
keithd@cadovax.UUCP (Keith Doyle) (10/13/87)
In article <8710060554.AA05630@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>Hey gang, I was wondering what the Commodore approved method for changing >>IntuitionBase->MaxXMouse and IntuitionBase->MaxYMouse is, so your pointer >>can move wherever needed on an overscan screen. Without modifying them, >>the mouse will only move within a 320x200 rectangle within a 352x220 >>screen. > What version of the OS are you using? My mouse has no problems with >an overscan screen. Well, try this, and see if you still say that: 1) start from a STANDARD 640x200 workbench screen. 2) invoke a 'C' program that does a: a) OpenScreen of an overscan screen b) waits so you can try stuff 3) Try moving the mouse on this overscan screen. You will notice the mouse still thinks it's got a standard 640x200 screen space and will not move all the way to the lower right corner. This happens on V1.2. According to Carolyn at CBM, this has been a problem because the MaxXMouse etc. values are in 'don't mess with it' space in IntuitionBase. Carolyn indicated they may be coerced into not moving this stuff because there is presently no alternative but to modify these values and we need the functionality. Using MoreRows on a WB does not exhibit this problem, because it gets around it by configuring Preferences so that the system will automatically start up with the correct parameters in MaxXMouse etc. Only if you start with a smaller screen and do an OpenScreen of an overscan screen do you get in trouble. BTW, Here's one vote for CBM not moving these values, as it will definately break our soon-to-be-released program. (or rather, our program will probably break something else, by modifying stuff that isn't there anymore). Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/14/87)
:>dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
:> What version of the OS are you using? My mouse has no problems with
:>an overscan screen.
:
:Well, try this, and see if you still say that:
:
:1) start from a STANDARD 640x200 workbench screen.
Whoops.... my apologies. I *was* using morerows.... In fact, I haven't
seen a standard 640x200 workbench for months!
See ya'll at BADGE (at least those in the bay-
area). Hopefully my late entry made it to
Tom's door in time.....
-Matt