Date:	Tue, 18 May 93 10:01:28 CST
From:	(csaba AT vuse DOT vanderbilt DOT edu) <csaba AT vuse DOT vanderbilt DOT edu>
To:	kiwi AT stud DOT ee DOT ethz DOT ch
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: Pattern Origin change & Mouse/Keyboard Event problem

On Tue, 18 May 1993 12:03:37 +020,
  Rene Mueller writes:

>>From MAILER-DAEMON AT stud DOT ee DOT ethz DOT ch Tue May 18 11:59:52 1993

>I try to porting a small window system on PC and one low-level function is
>to draw a colored bitmap, in GRX a GrPattern, but when I draw it by 
>PrPatternFilledBox, the origin of the pattern is the root 0,0. But I would
>like to change the origin of the pattern that I can draw a pattern like an
>image to a special coordinate.

Patterns are exactly what their name implies: FILL PATTERNS and NOT IMAGES 
or ICONS. They are anchored at (0,0) (and not only in GRX!) for two very 
good reasons: 

1) When filling two adjacent or overlapping areas you could get a "break" 
   in the pattern if the pattern was anchored at the primitive instead of 
   the screen origin.

2) Where exactly do you suggest anchoring patterns for circles, ellipses,
   filled arcs, irregular polygons, etc.. other than the screen origin?

If you want to control the look of the pattern on the screen, draw with it 
first into an off-screen context and transfer (a portion of) this image to 
the screen. This way you get to control the alignment. There is an 
alternative solution for bitmap patterns only: create eight versions of the 
pettern with the bits rotated in all 8 possible ways and with the bit 
buffer holding twice the number of the bitmap row count. Based on your 
X alignment requirements select the pattern to use and adjust its start 
address based on the Y alignment requirement. 

>
>Another problem I found is, that when I ask for an event with MouseGetEvent
>with the mask of M_EVENT (include KEYPRESS), then it waits truely first of
>an action by mouse (motion or press), then I can receive by the ways also
>the pressed key. I don't know whether it is a bug or I read the documentation
>wrong, but if I would like to receive also keyboard events without any action
>of the mouse ... M_POLL seems to have problems with showing the mouse, but
>maybe you have an better idea without polling.
>

Looks like you are using 'MouseGetEvent' in polled mode. Using the 
interrupt-driven (event queue) mode will solve your problem. Just issue
'MouseEventMode(1)' before the first 'MouseGetEvent' call. However, if you 
are using GO32 1.09 I suggest that you wait until 1.10 comes out (should be 
soon), as GO32 1.09 has some problems with the event queues. If are still 
using GO32 1.08 you can do the above change right now.

>   ,
>Rene (kiwi AT iis DOT ethz DOT ch)
>

Csaba Biegl
csaba AT vuse DOT vanderbilt DOT edu

- Raw text -