Session D-OCX2
Erweiterung von VFP
durch OCX-Programmierung
Gerhard Paulus
GNOM SOFT Dipl.Kfm. Gerhard Paulus & Co. GmbH
Ducks.OCX
Ducks.OCX (and the other OCX'es in this session) are initially built using "Control Wizard" of the Control Developer's Kit (CDK) which comes with Visual C++. ControlWiz will generate the following standard files if "Ducks" is the name of the VC project:
Ducks32.MAK : Project file for Visual C++
Ducks.CLW : Repository of ClassWizard
Ducks.ODL : "Object Description Language" file describing the OCX'es type library. This file describes all GUID's (Globally Unique ID's) and interfaces and properties and events in the OCX. This type library is used primarily by OLE Automation clients.
Ducks.RC, Resource.H : Resource file (for bitmaps, dialogs etc.) and its header file.
DucksCtl.BMP : Bitmap used to show the OCX in a toolbar.
Ducks.DEF : Module definition file for this project.
Ducks.H, Ducks.CPP : Header and implementation of the Server-DLL housing the OCX.
DucksCtl.H, DucksCtl.CPP : Header and implementation of the OLE Custom Control proper, which is C++ class 'CDucksCtrl'.
DucksPPG.H, DucksPPG.CPP : Header and implementation of property pages dialog.
If you build this DLL you already have a self-registering OCX. It doesn't do a lot other than painting a circle in its window but you have a functioning template you can work on.
Ducks.OCX will be modelled along the "Connected Objects" sample of chapter 4 in "Inside OLE" (Microsoft Press). Originating from Control Wizard this OCX is based upon the Microsoft Foundation Classes (MFC) libary.
The final Ducks.OCX will paint 3 rectangles in its window with centered labels "Quack", "Flap", "Paddle". Clicking on one of these rectangles will fire a Quack-event, Flap-event or Paddle-event. Seriously <g>.
The standard OCX as generated by ControlWiz will paint a circle in its window. This is coded in method OnDraw of class CDucksCtrl. To paint rectangles this method must be changed so that it looks similar to the following (where rcRect1, rcRect2, rcRect3 are variables of CRect type):
void CDucksCtrl::OnDraw(
CDC* pdc, const CRect& rcBounds, const CRect& rcInvalid)
{
LPRECT rc1= rcBounds;
rc1->bottom = rc1->bottom /3 -3;
rc1->left += 3;
rc1->right -= 3;
rc1->top += 3;
rcDuck1= CRect(rc1->left,rc1->top, rc1->right, rc1->bottom) ;
rcDuck2=rcDuck1;
rcDuck3=rcDuck1;
int offset= rc1->bottom - rc1->top + 6 ;
rcDuck2.OffsetRect(0, offset);
rcDuck3.OffsetRect(0, 2*offset);
pdc->FillRect(rcDuck1,
CBrush::FromHandle((HBRUSH)GetStockObject(WHITE_BRUSH))) ;
pdc->Rectangle(rcDuck1) ;
pdc->DrawText("Quack", -1, rcDuck1, DT_SINGLELINE | DT_CENTER |
DT_VCENTER );
pdc->FillRect(rcDuck2,
CBrush::FromHandle((HBRUSH)GetStockObject(WHITE_BRUSH)));
pdc->Rectangle(rcDuck2);
pdc->DrawText("Flap", -1, rcDuck2, DT_SINGLELINE | DT_CENTER |
DT_VCENTER );
pdc->FillRect(rcDuck3,
CBrush::FromHandle((HBRUSH)GetStockObject(WHITE_BRUSH)));
pdc->Rectangle(rcDuck3);
pdc->DrawText("Paddle", -1, rcDuck3, DT_SINGLELINE | DT_CENTER |
DT_VCENTER );
}
The Class Wizard of Visual C++ has options to map code to windows events. To fire the various "Ducks" events we have to map code to the Windows message WM_LBUTTONDOWN. This message is sent when user clicks the left mouse button on the Cobtrol's window. Mapping code to this message with ClassWiz will chage the message map of the control in DucksCtl.CPP and add an empty method CDucksCtrl::OnLButtonDown.
message map:
BEGIN_MESSAGE_MAP(CDucksCtrl, COleControl)
//{{AFX_MSG_MAP(CDucksCtrl)
ON_WM_LBUTTONDOWN()
//}}AFX_MSG_MAP
ON_OLEVERB(AFX_IDS_VERB_PROPERTIES, OnProperties)
END_MESSAGE_MAP()
After adding code for hit-testing "OnLButtonDown" looks as follows
// CDucksCtrl message handlers
void CDucksCtrl::OnLButtonDown(UINT nFlags, CPoint point)
{
if (rcDuck1.PtInRect(point))
FireQuack();
if (rcDuck2.PtInRect(point))
FireFlap();
if (rcDuck3.PtInRect(point))
FirePaddle();
COleControl::OnLButtonDown(nFlags, point);
}
This looks simple but where are the event firing functions "FireQuack", "FireFlap" and "FirePaddle" defined and implemented ? We have to do this with ClassWiz in the "Events" section. There we can add the external names "Quack", "Flap" and "Paddle" which ClassWiz will automagically associate with functions "FireQuack", "FireFlap" and "FirePaddle". After this operation the Event map in DucksCtl.CPP will look like this:
BEGIN_EVENT_MAP(CDucksCtrl, COleControl)
//{{AFX_EVENT_MAP(CDucksCtrl)
EVENT_CUSTOM("Quack", FireQuack, VTS_NONE)
EVENT_CUSTOM("Flap", FireFlap, VTS_NONE)
EVENT_CUSTOM("Paddle", FirePaddle, VTS_NONE)
//}}AFX_EVENT_MAP
END_EVENT_MAP()
After building the OCX and registrating it (Visual C++ has an option for this on the "Tools" menu) the OCX can be used on a VFP form right away:
DO FORM Ducks && Ducks.SCX is in OCX2\Ducks
You’ll find the C++ sources in DucksCtl.H and DucksCtl.CPP on the companion disk.
SB.OCX
VFP does not have a native ScrollBar control. So we are going to make it now by sub-classing a native Windows ScrollBar control. ControlWiz has an option for this where we select "SCROLLBAR".
ControlWiz will generate additional class methods necessary for sub-classing a Windows control. One of these methods is SBCtrl::PreCreateWindow().
//////////////////////////////////////////////////////////////////
// CSbCtrl::PreCreateWindow - Modify parameters for CreateWindowEx
BOOL CSbCtrl::PreCreateWindow(CREATESTRUCT& cs)
{
cs.lpszClass = _T("SCROLLBAR");
return COleControl::PreCreateWindow(cs);
}
A native Windows control is in fact a Windows window with its own window procedure for processing Windows messages. So for a ScrollBar control a window of pre-registered class "SCROLLBAR" must be created. SBCtrl::PreCreateWindow() will receive as parameter a structure by reference which the framework will use to create the Contol's window.
SB.OCX should fire Scroll Events when user clicks on the arrow buttons, page left/right area or moves the thumb of the ScrollBar. The native Windows ScrollBar control will catch the respective mouse clicks and send Scroll messages to its parent window (usually a form or dialog). For the OCX event firing business these scroll messages have to be sent back so that we can map these messages to code in ClassWiz. This is accomplished by a reflector window which is either implemented by the OCX container app (when ambient property "MessageReflect" is set) or by the OCX itself. Either way, in the message map of the OCX the following line must be added :
ON_MESSAGE(OCM_HSCROLL, OnOcmHScroll)
This will map the original WM_HSCROLL message (reflected as OCM_HSCROLL) with method OnOcmHScroll. The following implementation processes 2 of the various scroll codes (only for clicking the arrow buttons):
LRESULT CSbCtrl::OnOcmHScroll(WPARAM wParam, LPARAM lParam)
{
int nScrollCode = LOWORD(wParam);
int nScrollPos = HIWORD(wParam);
int nCurPos = GetScrollPos(SB_CTL);
switch (nScrollCode)
{
case SB_LINELEFT:
SetScrollPos(SB_CTL, nCurPos-1, TRUE);
break;
case SB_LINERIGHT:
SetScrollPos(SB_CTL, nCurPos+1, TRUE);
break;
}
FireOnScroll(nScrollCode, GetScrollPos(SB_CTL));
return 0;
}
The event firing 'FireOnScroll' function is initiated in ClassWiz (Events section) and takes 2 parameters: ScrollCode (indicating the part of the ScrollBar the user has clicked on) and the current Scroll position of the ScrollBar.
Problem is, if you now build the OCX and test it in a VFP form nothing happens. There are no events fired. This is because the lower and upper limit of the ScrollBar scroll range default to zero. We must increase the upper limit by intercepting the Windows message WM_CREATE and mapping code to it in ClassWiz:
// CSbCtrl message handlers
int CSbCtrl::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if (COleControl::OnCreate(lpCreateStruct) == -1)
return -1;
SetScrollRange(SB_CTL, 0, 100, TRUE);
return 0;
}
In this case the upper limit of the scroll range of the ScrollBar will be 100.
In SB.OCX so far clicking in the page left/right areas has no effect. We can add a class property m_nScrollPage so that the scroll position can be changed programmatically when these events happen. ClassWiz (OLE Automation section) will help us to generate the respective code for such a Get/Set- property.
long CSbCtrl::GetScrollPage()
{
return m_nScrollPage;
}
void CSbCtrl::SetScrollPage(long nNewValue)
{
m_nScrollPage= nNewValue;
SetModifiedFlag();
}
Of course CSbCtrl::OnOcmHScroll has to be modified so that the scroll position is actually changed when user clicks on the Page left/right areas.
LRESULT CSbCtrl::OnOcmHScroll(WPARAM wParam, LPARAM lParam)
{
int nScrollCode = LOWORD(wParam);
int nScrollPos = HIWORD(wParam);
int nCurPos = GetScrollPos(SB_CTL);
switch (nScrollCode)
{
case SB_LINELEFT:
SetScrollPos(SB_CTL, nCurPos-1, TRUE);
break;
case SB_LINERIGHT:
SetScrollPos(SB_CTL, nCurPos+1, TRUE);
break;
case SB_PAGELEFT:
SetScrollPos(SB_CTL, nCurPos-m_nPageScroll, TRUE);
break;
case SB_PAGERIGHT:
SetScrollPos(SB_CTL, nCurPos+m_nPageScroll, TRUE);
break;
}
FireOnScroll(nScrollCode, GetScrollPos(SB_CTL));
return 0;
}
After building the OCX and registrating it (Visual C++ has an option for this on the "Tools" menu) the OCX can be used on a VFP form right away:
DO FORM SB && SB.SCX is in OCX2\SB
You’ll find the C++ sources in SBCtl.H and SBCtl.CPP for this "lightweight" ScrollBar on the companion disk.
BTree.OCX
The purpose of this OCX is to show the difference between VFP and C++ when it comes to instantiate lots (thousands) of objects. The task is to build a binary tree of random numbers using object-oriented techniques.
In VFP such a program could look like this:
**************************************
*** BTreeVFP.prg
**************************************
PARAMETERS nIterations
IF EMPTY(nIterations)
RETURN
ENDIF
oBtree= CREATEOBJECT("BinaryTree",0)
SET DECIMALS TO 4
nStartSeconds= SECONDS()
FOR i=1 TO nIterations
= oBtree.Insert(INT(RAND()*1000))
ENDFOR
nEndSeconds= SECONDS()
? "??? ", nEndSeconds-nStartSeconds && 146.691
= oBTree.Traverse()
*=================================
DEFINE CLASS BinaryTree AS CUSTOM
oLeft = .NULL.
oRight = .NULL.
nData = 0
name= "BTree"
PROCEDURE Init(nNumber)
this.nData = nNumber
ENDPROC
PROCEDURE Insert( nNumber )
IF ( nNumber < this.nData )
IF !ISNULL(this.oLeft)
this.oLeft.Insert( nNumber )
ELSE
this.oLeft = CREATEOBJECT( "BinaryTree", nNumber )
ENDIF
ELSE
IF !ISNULL(this.oRight)
this.oRight.Insert( nNumber )
ELSE
this.oRight = CREATEOBJECT( "BinaryTree", nNumber )
ENDIF
ENDIF
ENDPROC
PROCEDURE Destroy
this.oLeft = .NULL.
this.oRight = .NULL.
ENDPROC
PROCEDURE Traverse
IF !ISNULL(this.oLeft)
this.oLeft.Traverse()
ENDIF
? this.nData
IF !ISNULL(this.oRight)
this.oRight.Traverse()
ENDIF
ENDPROC
ENDDEFINE
What about using the same VFP program but instantiating C++ objects to build the binary tree ? We can do this by developing BTree.OCX. The code of the VFP program would then look as folllows:
**************************************
*** BTreeOCX.prg
**************************************
PARAMETERS nIterations
IF EMPTY(nIterations)
RETURN
ENDIF
oBtree= CREATEOBJECT("BTREE.BtreeCtrl.1")
SET DECIMALS TO 4
nStartSeconds= SECONDS()
FOR i=1 TO nIterations
= oBtree.Insert(INT(RAND()*1000))
ENDFOR
nEndSeconds= SECONDS()
? "??? ", nEndSeconds-nStartSeconds
BTree.OCX is generated by ControlWiz as usual, but this time with the "Invisible at run-time" flag. This will generate (among others) the files BTreeCtl.H and BTreeCtl.CPP, where the Control's class CBTreeCtrl is defined and implemented.
For the job of building a binary tree of random numbers a C++ class is necessary instances of which will become the nodes of the tree.
// in BTreeCtl.H
class BinaryTree
{
BinaryTree * m_pLeft ;
BinaryTree * m_pRight ;
long m_nData ;
public:
BinaryTree() {m_pLeft=NULL; m_pRight=NULL; m_nData=0;} ;
BinaryTree(long nNumber) {m_pLeft=NULL; m_pRight=NULL; m_nData=nNumber;} ;
~BinaryTree() {delete m_pLeft; delete m_pRight;} ;
BOOL Insert(long nNumber);
} ;
// in BTreeCtl.CPP
// BinaryTree implementations
BOOL BinaryTree::Insert(long nNumber)
{
if (nNumber<m_nData)
{
if (m_pLeft)
return m_pLeft->Insert(nNumber);
else
{
m_pLeft = new BinaryTree(nNumber);
return (m_pLeft!=NULL) ;
}
}
else
{
if (m_pRight)
return m_pRight->Insert(nNumber);
else
{
m_pRight = new BinaryTree(nNumber);
return (m_pRight!=NULL) ;
}
}
}
For OLE Automation we also need an "Insert" method for the Control's class as generated by ClassWiz. This method takes a numeric parameter for the random number to be inserted into the binary tree and returns a logical value indicating success or failure of the operation.
BOOL CBtreeCtrl::Insert(long nNumber)
{
return m_pBTree->Insert(nNumber);
}
m_pBTree is an attribute of the control's class (CBtreeCtrl) which is added so that the BinaryTree class can be used from within the OCX. The Control's constructor and destructor must take care of this pointer.
// Constructor
CBtreeCtrl::CBtreeCtrl()
{
InitializeIIDs(&IID_DBtree, &IID_DBtreeEvents);
m_pBTree = new BinaryTree();
}
// Destructor
CBtreeCtrl::~CBtreeCtrl()
{
delete m_pBTree ;
}
After building and registering BTree.OCX we are now in the position to actually test things.
DO BTreeVFP WITH <nIterations> && in OCX2\BTree
DO BTreeOCX WITH <nIterations> && in OCX2\BTree
On my machine this led to the follwing results (time in seconds):
------------------------------------------------------------------ nIterations | 100 1,000 2,000 10,000 ================================================================== VFP+VFP | 0.740 13.139 43.212 forget it ------------------------------------------------------------------ VFP+OCX | 0.080 0.792 1.552 7.832 ------------------------------------------------------------------