lecture 6 l.
Skip this Video
Loading SlideShow in 5 Seconds..
Lecture 6 PowerPoint Presentation
Download Presentation
Lecture 6

Loading in 2 Seconds...

play fullscreen
1 / 28

Lecture 6 - PowerPoint PPT Presentation

  • Uploaded on

Lecture 6 The Graphics Interface and Mouse Events THE BASICS The architecture of a basic Windows application will in 99% of cases perform screen output in the WM_PAINT message handler. With graphical input via MOUSE EVENTS we have to modify this and perform output as required.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Lecture 6' - Ava

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
lecture 6
Lecture 6

The Graphics Interface and Mouse Events

the basics
  • The architecture of a basic Windows application will in 99% of cases perform screen output in the WM_PAINT message handler.
  • With graphical input via MOUSE EVENTS we have to modify this and perform output as required.
  • When considering graphical output this must be done in a device independent manner.
  • First therefore we must look at the concepts associated with device independence.
device context
Device Context
  • In handling WM_PAINT the processing is handled between the calls to: BeginPaint() .... EndPaint ().
  • This is to allow the application to acquire the Device Context.
  • The Device Context (DC) has two important features allowing a particular application to communicated with a specific physical devices.
  • Any DC is associated with a particular physical device.
  • The actual software interface to for instance a SVGA display adapter is configured into a particular installation of ‘95 ‘98 or ‘NT.
  • This physical drive software is of no relevance to the architecture of a windows application.
  • An application must be designed with the full understanding that it is to communicate all its graphical output through a DC.
  • Other DC’s exist in any system the other most common DC is the one associated with the printer.
  • The Device Driver or Interface to the physical display etc. is the piece of software within a windows system designated as a VxD.
  • The second major function of the DC is a place holder and container for the storage of a set of graphical attributes such as colour, pen size, brushes (fill patterns) and so on.
  • Attributes can be modified once the application has access to the DC.
  • To understand the concept of DC we can think of it as a artist being instructed to do something on to a canvas. The application itself does not know how to put the physical paint on the canvas, the artist takes the instructions from the application and using the equipment he /she is holding performs the actual visual actions.
graphics objects
  • Graphics objects are surprisingly abstract entities.
  • Within Windows to actually draw graphics shapes is comparatively simple. To draw a rectangle, takes five arguments, four define the dimensions, the fifth specifies the DC.
  • The DC encapsulates every aspect of the drawing process required, width, colour of outline, pattern of the interior and the destination i.e. Screen or Printer.
what are the objects
  • Groups of graphics attributes are encapsulated into objects and stored within the DC. These abstract entities are called graphics objects
  • Drawing a line for instance is controlled by an object called a PEN.
  • Filling the interior of an object is controlled by an object called a BRUSH.
  • To modify or select a particular characteristic
    • Either use a STOCK object one that exists within Windows
    • or a new set of characteristic are CREATED.
  • The PEN object has the basic characteristics
    • Line Style
    • Line width
    • Colour
stock items and brushes
Stock Items and Brushes
  • The advantages of STOCK items is they already exist and do not require any additional system resource.
  • Using CREATE, to build a unique PEN offers nearly an infinite variety of PENS, but uses system resource.
  • The BRUSH object has the basic characteristics
    • Solid or Hatch Pattern
    • Colour
  • Careful consideration to the colour capability of the system the application is likely to run on is important.
  • It is common practice to combine the applications code associated with graphical output between the display and the printer. If screen has a colour palette capability of 256 and the printer only 16 this may cause design compromises.
colour specification
  • Windows ‘95 ‘98 and ‘NT address the problem of specifying a colour hue that can not be dealt with by the physical device by modifying the colour to a best match. Colour images or colour printing is specified by considering the amount of the three primary colours


  • COLORREF - 32 bit value 3 x 8 bit values specify the primary colour intensity.
  • The value of each 8 bit colour intensity can be from 0 to 255 so this gives rise to the availability of 256 shades of red mixed with 256 shades of green and 256 shades of blue a total of 16,777,216 hues of colour.
  • In order to simplify the selection and set up of COLORREF a macro exists RGB that constructs the COLORREF 32 bits correctly.
colorref values
  • Typical RGB Values.
  • Colour Red Green Blue Red Green Blue

Black 0 0 0 Red 255 0 0

Green 0 255 0 Blue 0 0 255

Yellow 255 255 0 Magenta 255 0 255

Cyan 0 255 255 Dark Gray 128 128 128

Olive 128 128 0 Orange 255 128 0

White 255 255 255

warning on colour
  • If an application specifies an RBG(175,37,76) it is very lightly unless the system running the application has a sophisticated display adapter that this will be translated to something far simpler RGB(255,0,128) and possibly dependent on the display adapter some dithering may occur. The moral to this warning is; unless you are doing photographic manipulation applications don’t try and select complex colour hues they probably won’t be available on the majority of systems.
  • The last topic before we look at HOW we interface with the user allowing graphical input MOUSE events etc. Is what are drawing modes?
background etc
BackGround etc.
  • If an application specifies draw a line, it expects this line to appear on for instance the screen (we will assume the DC specified is the screen). The line should appear in the line style, width and colour specified by the PEN selected into the DC.
  • However, the world of graphic drawing is not as simple as that. What about the background ?
  • This may be a variety of colours either solid or banded and the line may disappear in certain regions because the PEN colour and the background colour are the same.
what can we do
  • The answer in Windows and many other graphical based GUI’s is to have Drawing Modes or Raster Operations. This is another set of attributes held in the DC which determine how the graphical operation is to be performed.
rop s
  • There are a vast array of these some are very obscure but looking at the most common we can identify
  • ROP Constant Line Drawn on background Colour

R2_Black Always Black

R2_White Always White

R2_NOP Same as background so invisible

R2_NOT Inverse of background so always visible

R2_COPYPEN Same as Pen Colour (default)

R2_NOTCOPYPEN Inverse of Pen Colour

more on rop s
  • The most common is R2_COPYPEN, (the default) simply uses the Pen Colour specified.
  • R2_NOT is very important it draws as the inverse of the background so is always visible no matter what colour or range of colours on the background. Of course the inverse of Black is White and the inverse of White is Black, but things do get complicated when the background is some other colour.
r2 not
  • An interesting feature of R2_NOT is that if we draw one line then draw over that line again it will disappear since the inverse of the inverse get us back to the original background colour. This is a very simple but important idea, that w will investigate more fully when w look in a moment at acquiring drawing input from the user via the Mouse events.
the mouse and user events
The Mouse and User Events
  • User Input.
    • You use the mouse or tracker ball to indicate points on the screen to draw and drag graphics objects.
  • We have already seen that by encapsulating the attributes for the actual drawing features Windows can provide a simple set of API’s to place geometric elements; lines, ellipses and rectangles on the screen.
wm mousemove
  • lParam in the 16 bit environment contains in the low word the X-co-ordinate and the high word the Y-co-ordinate.

16 bits 16 bits


High Word Y-coordinate Low Word X-coordinate

standard macro s
  • Two standard macros are available to extract these unsigned integer value correctly


  • wParam indicates carries information on whether the user has pressed mouse keys or any special keys.

wParam Constant Meaning in WM_MOUSEMOVE

MK_LBUTTON Left Button was down

MK_RBUTTON Right Button was down

MK_MBUTTON Middle Button was down

MK_CONTROL CTRL key on keyboard down

MK_SHIFT SHIFT key on keyboard down

typical mouse control
  • So a typically you can test wParam with code of the form

if (wParam & MK_LBUTTON)

  • This will be true if the mouse moved while the user held the left button.
  • To light a single Pixel on the screen when the user moves the mouse with the left button held we would need a piece of code of the form
some typical code

if (wParam & MK_LBUTTON)


hDC = GetDC(hWnd); // Get the default screen DC for this Window

// hWnd is the windows handle returned during

// create window.

SetPixel (hDC, LOWORD(lParam), // X-coordinate

HIWORD(lParam), // Y-coordinate

RGB(0,0,0)); // Colour for Pixel in this case Black

ReleaseDC(hWnd,hDC); // Release the DC


This code being the action to take on receipt of a WM_MOUSEMOVE message in the message handling procedure for the particular window.

draw a line
  • Now we could simply use the Pixels to draw the line but this would be tedious for the user and it does not offer the user the chance to change the direction of the line.

if (wParam & MK_LBUTTON)


hDC = GetDC(hWnd); // Get the default screen DC for this Window

// hWnd is the windows handle returned during

// create window.

PtNew = MAKEPOINT (lParam);

// Ptnew is a standard structure of type POINT

// which using the MAKEPOINT macro

// will store the X-coordinate and Y-coordinate

SetROP2(hDC, R2_NOT); // we have seen this is draw mode

// in which the colour is inverse of // background

code cont

MoveTo(hDC,Original.x, Original.y)// What is Original ?

// We will see we get this set by // another message

LineTo(hDC, PtOld.x,PtOld.y); // What is PtOld its were we drew // the line last time

MoveTo(hDC,Original.x, Original.y)// What is Original ?

// We will see we get this set by // another message

LineTo(hDC, PtNew.x,PtNew.y); // Draw the new line in...

ReleaseDC(hWnd,hDC); // Release the DC

PtOld = PtNew; // Update for next time .


  • Now as indicated this is the code for WM_MOUSEMOVE messages, but we also need a very simple bit of code for the message generated when the user first presses the left button.
the last on mouse draw
The Last on Mouse Draw
  • Windows provides a WM_LBUTTONDOWN message sent when the user first presses the left button.

Original = MAKEPOINT (lParam); // set up and save start point

PtOld = PtNew;

  • Windows provides a WM_LBUTTONUP message sent when the user releases the left button.

hDC = GetDC(hWnd); // Get the default screen DC for this Window

// hWnd is the windows handle returned during

// create window.

MoveTo(hDC,Original.x, Original.y); // back to start

LineTo(hDC, PtNew.x,PtNew.y); // Finish the line