Win32 API Programming with Visual Basic

Page 353
  IV. THE WINDOWS GDI (GDI32.DLL PROGRAMMING)  
Page 355
  21. Bitmaps  
   
  So far, we have discussed in some detail the rather low-level concepts of processes and threads, memory, PE files, and windows messages. In this chapter, we begin our look at graphics and text, which is much closer to the user level than the material that we have been discussing.  
   
  Windows exposes its graphics-related functions in the Windows Graphical Device Interface, or GDI library. The GDI functions are implemented primarily in the GDI32.DLL library.  
 
  Rectangles  
   
  We have had some occasion to use the RECT structure previously in the book. Let us repeat the declaration:  
 
  typedef struct _RECT {

   LONG left;

   LONG top;

   LONG right;

   LONG bottom;

} RECT;

  
   
  The GDI makes extensive use of rectangles and the RECT structure, and implements a variety of functions for manipulating rectangles:  
 
  CopyRect

Makes a copy of a rectangle.

  
 
  EqualRect

Returns True if two rectangles are equal.

  
 
  InflateRect

Enlarges a rectangle by increasing the value of one or more members.

  
Page 356
 
  IntersectRect

Gets the intersection of two rectangles.

  
 
  IsRectEmpty

Returns True if the rectangle has no area.

  
 
  OffsetRect

Moves a rectangle.

  
 
  PtInRect

Returns True if a specified point lies within a specified rectangle.

  
 
  SetRect

Sets the members of a RECT structure.

  
 
  SetRectEmpty

Sets the members of a RECT structure to 0.

  
 
  SubtractRect

Subtracts one rectangle from another, provided that the difference is another rectangle.

  
 
  UnionRect

Returns the smallest rectangle that contains the two specified rectangles. (In case you are interested, this is not the union, but rather the convex hull, of the two rectangles.)

  
   
  We will get a chance to use some of these functions in an upcoming example.  
 
  Bitmaps  
   
  The term bitmap (or bitmap image) refers to a graphical image that consists of a rectangular array of picture elements, or pixels (although transparent pixels may make the bitmap appear to be nonrectangular). Each bitmap pixel corresponds to a pixel on the display device, which we will assume to be a display monitor. (Unfortunately, many software programs like to make unauthorized changes to a bitmap in order to print the image. Thus, it is often not the case that a bitmap pixel corresponds to a single printer ''pixel" or printer dot. Life would be so much simpler if the user had easily accessible control over the mapping from bitmap pixels to printer dots but I digress here.)  
   
  The term Windows bitmap file (these files have extension .BMP) refers to a specific set of file formats that Windows uses to render bitmaps on a display device. Each pixel in the bitmap image corresponds to a certain number of bits in the bitmap file, as shown in Figure 21-1.  
   
  The number of bits per pixel in the bitmap file is called the bitmap's color depth and specifies the number of colors supported by the bitmap. A monochrome bitmap, for instance, requires only one bit per pixel, whereas a 256-color bitmap  
Page 357
   
   
   
  Figure 21-1.

Bitmap images and bitmap files

  
   
  will require 8 bits per pixel (color depth is 8). In general, a bitmap with color depth n supports 2n colors.  
   
  As we will see, the pixel values in the bitmap file may or may not describe the actual colors themselves. To express a color requires 3 bytes for each primary color one byte each for red, green, and blue. Thus, it is often the case that each pixel value specifies an offset into a color table that is also contained in the bitmap file.  
   
  Microsoft has enhanced the BMP file format several times over the years, which is why there is more than one bitmap file format extant. Files of the original BMP format are referred to as device-dependent bitmaps, or DDBs. This format is now generally considered obsolete, although files of this type still seem to exist in abundance. All versions of the BMP file format since the first are referred to as device-independent bitmaps, or DIBs. Unfortunately, the term bitmap is often used for these file types as well. For clarity, we will use the term bitmap file when we are referring to the file, and bitmap image when we are referring to the actual graphics image.  
   
  To confuse matters even more, when Windows loads a bitmap file into memory, it removes the file header, thus creating a Windows bitmap memory image. In summary, the term bitmap can refer to a bitmap graphics image, a bitmap file, or a bitmap memory image.  
   
  Scan Lines  
   
  In order to render a bitmap image on a display, the pixels (dot trios) on the inside surface of the display are scanned by electron guns, one row at a time. Hence,  
Page 358
   
  each row of the bitmap file's pixel array (see Figure 21-1) corresponds to a portion of one of the display's scan lines. Sometimes a row of the bitmap file itself is referred to as a scan line. (For more on hardware raster scanning, let me suggest my book Understanding Personal Computer Hardware, published by SpringerVerlag, New York.)  
   
  In this regard, bitmaps can be classified into two categories, distinguished by whether the rows of pixels appearing in the bitmap file are scanned in normal order or in reverse order. In the top-down bitmap file, the first row of pixels in the bitmap file corresponds to the top row of the bitmap image. This means that the origin of the bitmap array, that is, the pixel array entry (0,0) represents the upper-left corner of the bitmap image. In a bottom-up bitmap file, the first row of pixels in the bitmap file corresponds to the last (bottom) row of the bitmap image. Hence, the origin represents the lower-left corner of the bitmap image.  
   
  Simply put, a top-down bitmap file builds the bitmap image from the top down, whereas a bottom-up bitmap file builds the bitmap image from the bottom up.  
   
  Device-Independent Bitmaps  
   
  The main compatibility problem related to bitmaps is the rendering of color. The original device-dependent bitmap (DDB) format, used in Windows 3.0 and earlier, uses a very simple method for representing colors. Each pixel value in the bitmap's data array is an index into a color table that is maintained by Windows itself. In this case, the color table is not part of the bitmap file. Hence, if a bitmap is created on one system and displayed on another system with a different color table, the original colors may be replaced. This is not good.  
   
  To mitigate this problem, the device-independent bitmap, or DIB, was invented. A DIB file contains all of the color information used by the bitmap, thus making it portable.  
   
  To understand how this is done, we must first note that colors are generally represented in a bitmap by the RGB color model, in which each color is described by a 3-byte (24-bit) number 8 bits to specify the intensity of red, 8 bits to specify the intensity of green, and 8 bits to specify the intensity of blue. (The colors red, green, and blue are the primary colors for the model.) Thus, for instance, the color &HFFFFFF indicates full intensity for each color, thus producing white; &H0 produces black; and &H00FF00 produces full intensity (bright) green. You can check this yourself by using a VB picturebox control and executing the code:  
 
  Picture1.BackColor = RGB(0, &HFF, 0)  
   
  Incidentally, there are other color models. For instance, the CYMK color model uses the primary colors cyan, yellow, magenta, and black. The RGB color model is used by display monitors, and the CYMK model is used by color printers. This is one reason why it is so difficult to get screen and printer colors to match.  
Page 359
   
  To understand the format of a DIB file, the place to start is with the way in which the color of each pixel is represented in the file. This depends on how many colors the bitmap supports. The common color depths for a bitmap are:  
   
  1 bit: 2 colors (called monochrome)  
   
  4 bits: 16 colors  
   
  8 bits: 256 colors  
   
  16 bits: 65,536 colors (called high color)  
   
  24 bits: 16,777,216 colors (called true color)  
   
  There is also a 32-bit color bitmap. These bitmaps actually use 24 bits for the primary RGB colors. The extra byte is devoted to the so-called alpha channel, which carries information about the degree of opacity for each pixel.  
   
  Bitmaps with color depth 1, 4, or 8 always use a color table, also called a color palette. This is a table of 3-byte RGB color values, equal in size to the number of supported colors. Each pixel value in the bitmap's data array is simply an index into this color table. Figure 21-2 illustrates the concept of a color table.  
   
   
   
  Figure 21-2.

A color table

  
   
  The real complexity comes with 16-bit color bitmaps, which fall into the gray area between those bitmaps that should obviously use a color table (depth 1, 4, and 8) and those that do not need a color table (depth 24 and 32). A variety of schemes are used to deal with 16-bit color bitmaps, but they basically fall into two categories. Either the pixel value is an offset into a color table or the pixel value is masked into three parts one for each primary color. Of course, each part is less than the full 8 bits that would be used to represent all possible color intensities. For instance, the simplest color mask is to use 5 bits for each color, as in:  
 
  xrrrrrgggggbbbbb  
Page 360
   
  where the most significant bit x is unused. Thus, the low-order 5 bits determines the intensity of blue, for instance. Note that when this 16-bit word is stored in memory, the bytes are reversed (little-endian), so it will appear as gggbbbbbxrrrrrgg.  
   
  It is important to note that even 24-bit and 32-bit color bitmap files may contain color tables. This is because they may need to be rendered on devices that do not support the full range of colors supported by the bitmap itself. To render a 24-bit color bitmap on a monitor that is set to display only 256 colors requires the use of a color table or some other means for replacing each of potentially over 16 million colors by one of 256 colors!  
   
  The BMP file format has evolved through at least four versions and a new version is being implemented for Windows 2000. Since it is not essential to our discussion of the Win32 GDI, we will not discuss bitmap file formats.  
 
  Bitmap Functions  
   
  The Win32 API provides a slew of functions for creating and manipulating bitmaps, and you will no doubt want to take a close look at these functions before programming your next bitmap editing application. However, our discussion will be confined to just two bitmap-related functions: LoadImage and BitBlt.  
   
  BitBlt  
   
  The BitBlt function is one of the workhorses of the Windows GDI. This term BitBlt is shorthand for Bitmap Block Transfer, which tells us that the purpose of BitBlt is to move graphical data from one location to another. However, it is also possible to specify how the source data should interact with the destination data.  
   
  The syntax for BitBlt is:  
 
  BOOL BitBlt(

  HDC hdcDest,  // handle to destination device context

  int nXDest,  // x-coordinate of destination rectangle's upper-left corner

  int nYDest,  // y-coordinate of destination rectangle's upper-left corner

  int nWidth,  // width of destination rectangle

  int nHeight,  // height of destination rectangle

  HDC hdcSrc,   // handle to source device context

  int nXSrc,   // x-coordinate of source rectangle's upper-left corner

  int nYSrc,  // y-coordinate of source rectangle's upper-left corner

  DWORD dwRop  // raster operation code

);

  
   
  Among other things, this function requires handles to device contexts for both the source and the destination. We shall discuss device contexts in detail in Chapter 22. Device Contexts I: Overview. Suffice it to say now that a device context.  
Page 361
   
  provides a means to use the GDI drawing functions for a particular device (which might be the display, a printer, a window, or even a chunk of memory). You may be familiar with the fact that most VB controls (including forms) have an hDC property that returns a handle to a device context. This property is all we need for this chapter.  
   
  The only other non-self-explanatory parameter is the raster operation code dwRop. Table 21-1 shows some of the possible values. The operators AND, OR, and NOT stand for bitwise operations. Thus, for instance,  
 
  1100 AND 1010 = 1000

1100 OR 1010 = 1110

1100 XOR 1010 = 0110

NOT 10 = 01

  
Table 21-1. Some Raster Operation Codes
Code Description
BLACKNESS Fills the destination rectangle using the color associated with index 0 in the physical palette. (This color is black for the default physical palette.)
DSTINVERT Inverts the destination rectangle.
NOTSRCCOPY Destination = NOT Source
NOTSRCERASE Destination = NOT (Source OR Destination)
SRCAND Destination = Source AND Destination
SRCCOPY Copies the source rectangle directly to the destination rectangle. The original destination pixels are lost.
SRCERASE Destination = Source AND (NOT Destination)
SRCINVERT Destination = Source XOR Destination
SRCPAINT Destination = Source OR Destination
WHITENESS Fills the destination rectangle using the color associated with index 1 in the physical palette. (This color is white for the default physical palette.)

   
  Example: Moving Playing Cards  
   
  Before illustrating the BitBlt function, let me digress briefly to explain how I first encountered this function, since it is at least partially relevant to the discussion.  
   
  Sometime in 1994 (I believe), the first continuous speech recognition software became available for the PC. At that time, I was in the process of creating a large database of several thousand high-level mathematics books for a newsletter that I publish. For this, I needed to supply each book with up to three subject classifications out of more than a hundred different subjects (I'll bet you didn't know that there were more than a hundred different subject areas of mathematics). The first few subjects are shown in Table 21-2.  
Page 362
Table 21-2. Subject Classification
Code Subject
AA Abstract Algebra
AGEO Algebraic Geometry
ALG Algorithms
APPL Applied Math
APPROX Approximation Theory
ARITH Arithmetic
ATOP Algebraic Topology

   
  The idea that perhaps this could be done by voice was very exciting to me, since the alternative typing in these subjects was sickening. I wanted to be able to speak words such as:  
  Next Book, Algorithms, Next Subject, Applied Math, Next Subject, Approximation, Next Book  
   
  As it turned out, this worked quite well certainly much better than I was expecting, and it got me very interested in voice recognition.  
   
  In any case, the demo program that came with the voice recognition software was a pointless little video poker game,  and it occurred to me that the company might be able to better demonstrate its software by voice-enabling the traditional solitaire game that comes with Windows.  
   
  Unfortunately, there is no way to voice-enable that particular version because it does not accept keyboard input. So I set out to write a clone of Windows Solitaire using Visual Basic one that could be completely controlled through the keyboard, with commands like JH.QS, meaning Put the Jack of Hearts on the Queen of Spades. This would make it a simple matter to voice-enable the program.  
   
  As it happens, this turned out to be quite a challenge.  
   
  First, I started by placing 52 picture boxes on a VB form. I didn't get very far before VB complained about being out of resources. Next, I tried using image controls instead, but there seemed to be no way to eliminate the major flicker problem when moving these controls. (There were other problems as well, but I can't remember what they were now.)  
   
  The only solution that would not require more resources than were available and would not produce noticeable flicker when the cards were moved was to use BitBlt.  
Page 363
   
  The idea is to add a separate form with a single picture box called Deck. In that picture box, I place d the set of 52 cards, as in Figure 21-3. Whenever a card needed to be drawn somewhere on the gaming table, I just used BitBlt to copy it from the picture box to the main form.  
   
   
   
  Figure 21-3.

The cards for a solitaire program

  
   
  To illustrate the process, the CD includes a small BitBlt example project called rpiBitBlt. The program just draws randomly chosen cards from a small deck of 20 cards onto the main form frmTable. You can use the mouse to drag these cards around the main window without interfering with the other cards. Figure 21-4 and Figure 21-5 show sample before and after pictures.  
   
  The bulk of the action in this program takes place in the MouseMove event.  
   
  When a card is moved, we first identify the rectangles that are uncovered by this move (UnRect1 and UnRect2). Figure 21-6 shows these uncovered rectangles when the card is moved down and to the right. Of course, the location of the rectangles will depend upon the direction of movement of the card.  
   
  Here is the code that corresponds to Figure 21-6:  
 
  ElseIf CardLocation (iCurrentCard).Left > CardPrevRect.Left And _

   CardLocation(iCurrentCard).Top > CardPrevRect.Top Then

   ' Moved right and down

   UnRect1.Top = CardPrevRect.Top

   UnRect1.Bottom = CardLocation(iCurrentCard).Top

   UnRect1.Left = CardPrevRect.Left

   UnRect1.Right = CardPrevRect.Right

   UnRect2.Top = CardLocation(iCurrentCard).Top

   UnRect2.Bottom = CardPrevRect.Bottom

   UnRect2.Left = CardPrevRect.Left

   UnRect2.Right = CardLocation(iCurrentCard).Left

  
Page 364
   
   
   
  Figure 21-4.

Before

  
   
  Once the rectangles UnRect1 and UnRect2 have been identified, we next fill them with the color of the tabletop (the form) using the FillRect GDI function:  
 
  FillRect Me.hdc, UnRect1, COLOR_BTNFACE + 1

FillRect Me.hdc, UnRect2, COLOR_BTNFACE + 1

  
   
  (In case you are wondering about the +1, here is what the documentation says:  
  If specifying a color value for the hbr parameter, it must be one of the standard system colors (the value 1 must be added to the chosen color).  
   
  Next, we copy the card being moved to its new location using a BitBlt:  
 
  ' Place current card at new location

i = CardIndex(iCurrentCard)

BitBlt Me.hdc, _

   CardLocation(iCurrentCard). Left, _

   CardLocation(iCurrentCard). Top, _

   CARD_WIDTH, _

   CARD_HEIGHT, _

   frmCards.Deck.hdc, _

   DECK_X_SPACING * (i Mod DECK_COL_COUNT), _

   DECK_Y_SPACING * (i \ DECK_COL_COUNT), _

   SRCCOPY

  
Page 365
   
   
   
  Figure 21-5.

After

  
   
   
   
  Figure 21-6.

Card movement

  
   
  Of course, the uncovered rectangles may intersect some of the other cards. To check that, we use the IntersectRect function. Here is an excerpt:  
 
  ' Get rectangle for card

SetRect Card, CardLocation(i).Left, CardLocation(i).Top, _

   CardLocation(i).Left + CARD_WIDTH, CardLocation(i).Top + CARD_HEIGHT

 

  

Page 366
 
  ' Get intersection of Unrect1 and card

IntersectRect FixupRect, UnRect1, Card

' If not empty then redraw FixupRect

If IsRectEmpty(FixupRect) = 0 Then

   BitBlt Me.hdc, _

      FixupRect.Left, _

      FixupRect.Top, _

      FixupRect.Right - FixupRect.Left, _

      FixupRect.Bottom - FixupRect.Top, _

      frmCards.Deck.hdc, _

      DECK_X_SPACING * (CardIndex(i) Mod DECK_COL_COUNT) _

      + (FixupRect.Left - CardLocation(i).Left), _

      DECK_Y_SPACING * Int(CardIndex(i) / DECK_COL_COUNT) _

      + (FixupRect.Top - CardLocation(i).Top), _

      SRCCOPY

End If

  
   
  The entire MouseMove code is shown here:  
 
  Private Sub Form_MouseMove(Button As Integer, Shift As Integer, _

x As Single, y As Single)

Dim i As Integer

Dim UnRect1 As RECT

Dim UnRect2 As RECT

Dim FixupRect As RECT

Dim Card As RECT

If Not bProcessMouseMove Then Exit Sub

' Adjust card location

CardLocation(iCurrentCard).Left = x - iCardOffsetx

CardLocation(iCurrentCard).Top = y - iCardOffsety

CardLocation(iCurrentCard).Bottom = CardLocation(iCurrentCard).Top + CARD_HEIGHT

CardLocation(iCurrentCard).Right = CardLocation(iCurrentCard).Left + CARD_WIDTH

' Get uncovered rectangles

If CardLocation(iCurrentCard).Left = CardPrevRect.Left Then

   ' Vertical move

   SubtractRect UnRect1, CardPrevRect, CardLocation(iCurrentCard)

   SetRectEmpty UnRect2

ElseIf CardLocation(iCurrentCard).Top = CardPrevRect.Top Then

   ' Horizontal move

   SetRectEmpty UnRect1

   SubtractRect UnRect2, CardPrevRect, CardLocation(iCurrentCard)

ElseIf CardLocation(iCurrentCard).Left > CardPrevRect.Left And _

   CardLocation(iCurrentCard).Top > CardPrevRect.Top Then

   ' Move right and down

   UnRect1.Top = CardPrevRect.Top

   UnRect1.Bottom = CardLocation(iCurrentCard).Top

   UnRect1.Left = CardPrevRect.Left

   UnRect1.Right = CardPrevRect.Right

 

  

Page 367
 
     UnRect2.Top = CardLocation(iCurrentCard).Top

   UnRect2.Bottom = CardPrevRect.Bottom

   UnRect2.Left = CardPrevRect.Left

   UnRect2.Right = CardLocation(iCurrentCard).Left

ElseIf CardLocation(iCurrentCard).Left > CardPrevRect.Left And _

   CardLocation(iCurrentCard).Top < CardPrevRect.Top Then

   ' Move right and up

   UnRect1.Top = CardLocation(iCurrentCard).Bottom

   UnRect1.Bottom = CardPrevRect.Bottom

   UnRect1.Left = CardPrevRect.Left

   UnRect1.Right = CardPrevRect.Right

   UnRect2.Top = CardPrevRect.Top

   UnRect2.Bottom = CardLocation(iCurrentCard).Bottom

   UnRect2.Left = CardPrevRect.Left

   UnRect2.Right = CardLocation(iCurrentCard).Left

ElseIf CardLocation(iCurrentCard).Left < CardPrevRect.Left And _

   CardLocation(iCurrentCard).Top > CardPrevRect.Top Then

   ' Move left and down

   UnRect1.Top = CardPrevRect.Top

   UnRect1.Bottom = CardLocation(iCurrentCard).Top

   UnRect1.Left = CardPrevRect.Left

   UnRect1.Right = CardPrevRect.Right

   UnRect2.Top = CardLocation(iCurrentCard).Top

   UnRect2.Bottom = CardPrevRect.Bottom

   UnRect2.Left = CardLocation(iCurrentCard).Right

   UnRect2.Right = CardPrevRect.Right

ElseIf CardLocation(iCurrentCard).Left < CardPrevRect.Left And _

   CardLocation(iCurrentCard).Top < CardPrevRect.Top Then

   ' Move left and up

   UnRect1.Top = CardLocation(iCurrentCard).Bottom

   UnRect1.Bottom = CardPrevRect.Bottom

   UnRect1.Left = CardPrevRect.Left

   UnRect1.Right = CardPrevRect.Right

   UnRect2.Top = CardPrevRect.Top

   UnRect2.Bottom = CardLocation(iCurrentCard).Bottom

   UnRect2.Left = CardLocation(iCurrentCard).Right

   UnRect2.Right = CardPrevRect.Right

End If

' Color the uncovered rectangles with the table color

FillRect Me.hdc, UnRect1, COLOR_BTNFACE + 1

FillRect Me.hdc, UnRect2, COLOR_BTNFACE + 1

' Place current card at new location

i = CardIndex(iCurrentCard)

BitBlt Me.hdc, _

   CardLocation(iCurrentCard).Left, _

   CardLocation(iCurrentCard).Top, _

 

  

Page 368
 
     CARD_WIDTH, _

   CARD_HEIGHT, _

   frmCards.Deck.hdc, _

   DECK_X_SPACING * (i Mod DECK_COL_COUNT), _

   DECK_Y_SPACING * (i \ DECK_COL_COUNT), _

   SRCCOPY

' Do the uncovered rectangles intersect any cards?

' If so, repaint cards

For i = 0 To DECK_CARD_COUNT - 1

   ' Skip the moving card

   If i = iCurrentCard Then GoTo NotThisCard

   ' Get rectangle for card

   SetRect Card, CardLocation(i).Left, CardLocation(i).Top, _

      CardLocation(i).Left + CARD_WIDTH, CardLocation(i).Top + CARD_HEIGHT

   ' Get intersection of Unrect1 and card

   IntersectRect FixupRect, UnRect1, Card

   ' If not empty then redraw FixupRect

   If IsRectEmpty(FixupRect) = 0 Then

      BitBlt Me.hdc, _

         FixupRect.Left, _

         FixupRect.Top, _

         FixupRect.Right - FixupRect.Left, _

         FixupRect.Bottom - FixupRect.Top, _

         frmCards.Deck.hdc, _

         DECK_X_SPACING * (CardIndex(i) Mod DECK_COL_COUNT) + _

            (FixupRect.Left - CardLocation(i).Left), _

         DECK_Y_SPACING * Int(CardIndex(i) / DECK_COL_COUNT) + _

            (FixupRect.Top - CardLocation(i).Top), _

         SRCCOPY

   End If

   ' Get intersection of Unrect2 and card

   IntersectRect FixupRect, UnRect2, Card

   ' If not empty then redraw FixupRect

   If IsRectEmpty(FixupRect) = 0 Then

      BitBlt Me.hdc, _

         FixupRect.Left, _

         FixupRect.Top, _

         FixupRect.Right - FixupRect.Left, _

         FixupRect.Bottom - FixupRect.Top,

         frmCards.Deck.hdc, _

         DECK_X_SPACING * (CardIndex(i) Mod DECK_COL_COUNT) + _

            (FixupRect.Left - CardLocation(i).Left), _

         DECK_Y_SPACING * Int(CardIndex(i) / DECK_COL_COUNT) + _

            (FixupRect.Top - CardLocation(i).Top), _

         SRCCOPY

   End If

NotThisCard:

Next

 

  

Page 369
 
  ' Save for next time

CardPrevRect = CardLocation(iCurrentCard)

End Sub

  
 
  Using Bitmaps in Menus  
   
  If anyone asks you why he or she would want to program the Win32 API under Visual Basic, you can always cite the following example as a good reason. In this example, we will place a bitmap in a VB menu, as shown in Figure 21-7.  
   
   
   
  Figure 21-7.

A bitmap in a menu

  
   
  The key to doing this is the ModifyMenu function:  
 
  BOOL ModifyMenu(

  HMENU hMnu,       // handle to menu

  UINT uPosition,   // menu item to modify

  UINT uFlags,      // menu item flags

  UINT uIDNewItem,  // menu item identifier or handle to drop-down menu/submenu

  LPCTSTR lpNewItem // menu item content

);

  
   
  When the uFlags parameter is set to MF_BITMAP, the lpNewItem parameter is expected to contain the handle to a bitmap. Accordingly, we declare the ModifyMenu function in VB as follows (note that the last parameter is declared as a long):  
 
  Declare Function ModifyMenu Lib "user32" Alias "ModifyMenuA" ( _

   ByVal hMenu As Long, _

   ByVal nPosition As Long, _

   ByVal wFlags As Long, _

   ByVal wIDNewItem As Long, _

   ByVal lpNewItem As Long _

) As Long

  
   
  To get a handle to a bitmap, we use the LoadImage function:  
 
  HANDLE LoadImage(

  HINSTANCE hinst,   // handle of the instance containing the image

  LPCTSTR lpszName,  // name or identifier of image

  UINT uType,        // type of image

  int cxDesired,     // desired width

 

  

Page 370
 
    int cyDesired,     // desired height

  UINT fuLoad        // load flags

);

  
   
  By setting hInst to NULL and uLoad to LR_LOADFROMFILE, we can put the path/ filename of a bitmap in lpszName.  
   
  Here is the entire code to do the job:  
 
  Sub MenuBitmap()

Dim hMenu As Long

Dim hSubMenu As Long

Dim lMenuID As Long

Dim hBitmap As Long

Dim hImage As Long

' Get handle of top menu

hMenu = GetMenu(Me.hwnd)

' Do we have a valid menu handle

If IsMenu(hMenu) = 0 Then

   MsgBox "Menu handle invalid", vbInformation

   Exit Sub

End If

' Get handle of submenu 0 (File menu)

hSubMenu = GetSubMenu(hMenu, 0)

' Do we have a valid submenu handle

If IsMenu(hSubMenu) = 0 Then

   MsgBox "Submenu handle invalid", vbInformation

   Exit Sub

End If

' Need menu item ID (item 1 is second item)

lMenuID = GetMenuItemID(hSubMenu, 1)

' Load bitmap

hImage = LoadImage(0, "d:\bkapi\0code\atten.bmp", IMAGE_BITMAP, 0, 0, LR_

LOADFROMFILE)

' Stick it in menu

ModifyMenu hSubMenu, 1, MF_BITMAP Or MF_BYPOSITION, lMenuID, hImage

End Sub

  
Related

Категории