Date: 02-16-2022
Return to Index
created by gbSnippets
'Rather than act directly on a physical device (screen, printer, ...),
'the various GDI API interact with device drivers on behalf of applications.
'More specifically, GDI API act on a device context (DC), which represents the
'drawing surface of a device (display screen, printer, ...). A display DC can be
'the entire screen or a specified window (i.e., a dialog or a control). Normally
'a DC represents the client area of a window, but can include the non-client area.
'Graphic Objects =====================================================================
'From a programming viewpoint, a DC is a structure that defines a set of graphic
'objects and their attributes. In particular, the following objects are supported:
' - bitmap for copying or scrolling parts of the screen
' - pen for line drawing
' - brush for painting and filling
' - palette defines set of available colors
' - font for printing text
' - region for clipping
' - path to control painting/drawing operations
'Each of these objects are covered in separate tutorials. When a DC is created
'a default pen, brush, palette, font and region are automatically placed in the
'DC. There is no default bitmap or path.
'Attributes of the graphic objects include:
' - bitmap size (bytes), hxw (pixels), color, compression, and more
' - brush style, color, pattern, and origin.
' - palette colors and size (or number of colors).
' - font typeface name, width, height, weight, characters set, and more
' - path shape
' - pen style, width, and color
' - region location and dimensions
'In addition to graphic objects which may be "selected" into the DC, a DC
'supports various graphic modes which affect how output is displayed.
'Device Contexts and PowerBASIC GRAPHIC Statements ===================================
'GDI and PowerBASIC GRAPHIC statements both create/modify Windows compatible device
'contexts. This means that graphics created by either approach can be passed for use
'by the other via device context operations (i.e.,the handle of a device context can
'be used interchangeably with both types of code).
'Getting a Handle to a DC ============================================================
'GDI API work with device contexts via a handle to the device context,
'usally written as hDC or some variant. At it's simplest, the GetDC GDI API
'is used to get a handle to the DC for a window, dialog, or control. PowerBASIC
'only provides a means of getting the DC for a graphic target. Here's the code for both:
hDC = GetDC(hWnd) 'gets a handle to the DC of a window, dialog, or control
Graphic Get DC To hDC 'gets handle to DC of the current graphic target
'While PowerBASIC does not provide a statement to get the DC for other controls, you
'can get the DC for any control by first getting the control handle and then using
'GetDC to get the handle to the DC. There are both API and PowerBASIC statements for
'getting the handle to a control:
'1. Use DDT to get the handle to a control, then use the GetDC API to get the DC to the control.
Graphic Handle hDlg, %ID_Control To hControl 'get handle of control
hDC = GetDC (hControl) 'get handle to DC of control
'2. Use an API to get the handle to a control, then use the GetDC API to get the DC to the control.
hControl = GetDlgItem(hDlg, %ID_Control) 'get handle of control
hDC = GetDC(hControl) 'get handle to DC of control
'In addition to GetDC, there are 3 other API which may be used to get the handle to a DC.
' API Arguments
' - BeginPaint hWnd, PS client area
' - GetDC hWnd client area
' - GetDCEx hWnd, hrgnClip, flags client area
' - GetWindowDC hWnd includes non-client area
'Ideally, an application carries out most of its drawing operations during
'processing of WM_PAINT messages. In that case, the application retrieves a
'display device context to the dialog by calling the BeginPaint function.
'If an application draws at any other time, it calls the GetDC or GetDCEx
'function to retrieve the display DC. See the tutorial "Painting and Drawing"
'for more information on when to use each of the API.
'Persistence ======================================================================
'The content of a DC is not persistent. That is, when another window covers and
'then uncovers the DC surface, the drawn content of the window disappears and
'must be redrawn by the application.
'Fortunately, when a Window is uncovered, a %WM_Paint message is sent to
'the application. So programmers typically place the drawing code with
'the %WM_Paint Event.
'Compilable Example: (Jose Includes)
#Compiler PBWin 9, PBWin 10
#Compile EXE
#Dim All
%Unicode=1
#Include "win32api.inc"
Global hDlg As DWord
Function PBMain () As Long
Dialog New Pixels, 0, "Draw on Dialog",20,20,250,250, %WS_OverlappedWindow To hDlg
Control Add Button, hDlg, 101,"DDT", 20,20,50,20
Control Add Button, hDlg, 102,"GDI", 80,20,50,20
Control Add Button, hDlg, 103,"Mix", 140,20,50,20
Control Add Graphic, hDlg, 300,"", 40,125,150,100, %WS_Border
Dialog Show Modal hDlg, Call DlgProc
End Function
CallBack Function DlgProc() As Long
Local PS As PaintStruct, hDC As DWord, hWnd As DWord
Select Case CB.Msg
Case %WM_Paint
'draw on dialog
hDC = BeginPaint(hDlg, PS)
Ellipse hDC, 50,50,100,100 'draw a circle
EndPaint hDlg, PS
Case %WM_Command
Select Case CB.Ctl
Case 101 'DDT
'draw on control with GRAPHIC statements
Graphic Attach hDlg, 300
Graphic Ellipse (20,20)-(50,50), %Red
Case 102 'API
'draw on control with GRAPHIC statements
Case 103
? "103"
'draw on control with GRAPHIC statements
Graphic Attach hDlg, 300
Graphic Get DC To hDC
Ellipse hDC, 20,20,50,50 'draw a circle
Control Handle hDlg, 300 To hWnd
ReleaseDC hWnd, hDC
End Select
End Select
End Function
'gbs_00492
'Date: 03-10-2012
http://www.garybeene.com/sw/gbsnippets.htm