Feedback Search Top Backward Forward
EDM/2

Introduction to PM Programming

Written by Larry Salomon, Jr.

 

Introduction

The purpose of this column is to provide the readers out there who are not familiar with PM application development the information necessary to satisfy their curiosity, educate themselves, and give them an advantage over the documentation supplied by IBM. Of course, much of this stuff could probably be found in one of the many books out there, but the problem with books in general is that they don't answer the questions you have after you read the book the first time through.

I will gladly entertain feedback from the readers about what was "glossed over" or what was detailed well, what tangential topics need to be covered and what superfluous crap should have been removed. This feedback is essential in guaranteeing that you get what you pay for. <grin>

It should be said that you must not depend solely on this column to teach you how to develop PM applications; instead, this should be viewed as a supplement to your other information storehouses (books, the network conferences, etc.). Because this column must take a general approach, there will be some topics that you would like to see discussed that really do not belong here. Specific questions can be directed to me via email and I will do my best to answer them in a timely fashion.

Last Month

Last month, we finished the WC_LISTBOX class and I asked for feedback. I did receive some, for which I am very grateful, but the majority of them were requests for advanced topics, like the container and the notebook controls. We will eventually cover these window classes, but it is essential that we look at the rudimentary ones first, so that you can better appreciate what these advanced classes do for you.

This month, we will look at the WC_TITLEBAR and WC_STATIC window classes. Since both of these classes are not too involving, covering them both should not be a problem.

The Titlebar

The titlebar class (WC_TITLEBAR) is usually not created directly, but is created for you by the frame window through the WinCreateStdWindow() call. It has two primary functions: 1) to display the text of the standard window to which it belongs, and 2) to act as a shortcut to two primary windowing functions, move and maximize/restore.

The titlebar does accept two messages: TBM_SETHILITE and TBM_QUERYHILITE.


TBM_SETHILITE
This message sets the highlight state of the control.

Parameters

SHORT1FROMMP(mpParm1) - the new highlight state of the control.
TRUE Draw the control in highlighted state.
FALSE Draw the control in normal state.

Returns

SHORT1FROMMR() - success indicator.
TRUE Successful completion.
FALSE Error occurred.


TBM_QUERYHILITE
This message returns the highlight state of the control.

Returns

SHORT1FROMMR() - highlight state of the control.
TRUE The control is drawn in highlighted state.
FALSE The control is drawn in normal state.
Highlight state is used to indicate that the window has the focus. Normally, you do not need to use these messages, since the frame control will use them on your behalf.

To set or query the text displayed in the titlebar, use WinSetWindowText() and WinQueryWindowText(). Again, the frame makes this easy by setting or querying it for you whenever you set or query the frame window's text.

For reference, it should be noted that, whenever the user attempts to move or maximize/restore the window using the titlebar, the titlebar sends its owner (the frame usually) a WM_QUERYTRACKINFO message. The owner can fill in this structure according to its needs to restrict movement or resizing as necessary. We will not discuss this further.

That's all there is to the WC_TITLEBAR class.

The Static

The static control is just that: static. It never changes. The point of the static control is to display text, rectangles, icons, bitmaps, etc. A table of the static styles is shown below:
Style Results in
SS_AUTOSIZE Automatically size to contain the text, icon, or bitmap
SS_BITMAP Bitmap
SS_BKGNDFRAME Unfilled rectangle painted with the background color
SS_BKGNDRECT Filled rectangle painted with the background color
SS_FGNDFRAME Unfilled rectangle painted with the foreground color
SS_FGNDRECT Filled rectangle painted with the foreground color
SS_GROUPBOX Groupbox
SS_HALFTONERECT Filled rectangle painted with a halftoned color
SS_HALFTONEFRAME Unfilled rectangle painted with a halftoned color
SS_ICON Icon
SS_SYSICON System icon
SS_TEXT Text
All but the first style are mutually exclusive. The first style can only be used with SS_TEXT, SS_BITMAP, SS_ICON, or SS_SYSICON. Additionally, if SS_TEXT is used, you may also or one of the constants from each of the following groups to align the text in a specific manner.

Horizontal alignment
Constant Alignment
DT_LEFT Left aligned
DT_CENTER Center aligned
DT_RIGHT Right aligned

Vertical alignment
Constant Alignment
DT_TOP Top aligned
DT_VCENTER Center aligned
DT_BOTTOM Bottom aligned

Window text for SS_TEXT statics can be set and queried using the WinSetWindowText() and WinQueryWindowText() functions. They accept no messages, nor send any messages.

Using SS_ICON, SS_BITMAP, and SS_SYSICON statics

When creating one of these three types of static controls, the question arises about how one specifies the icon, bitmap, or system icon to display. The answer is in the window text. For the first two, the text must be in the form "#n" where n is the ASCII representation of the resource identifier of the icon or bitmap to be displayed. A noteworthy caveat is that the icon or bitmap must reside in the .EXE resources; this can create problems if you're writing a general purpose DLL that cannot make assumptions about the .EXE resources. For the last one, the number represents the ASCII representation of the appropriate SPTR_* constant corresponding to the system icon that you wish to be displayed.

Opportunities for Mayhem

Because the static control does nothing except "just sit there," there are plenty of opportunities to create quick-n- dirty solutions to problems by creating a static window and then immediately subclassing it with the intent of enhancing its behavior.

That's It!

That's it for this month. Next month, we'll begin looking at the WC_MENU window class and we will see how it has become a staple in the bag of tricks that every OS/2 programmer has. Again, I will gladly accept any feedback that you have regarding this column and its future.