Kbase 21591: What Rules Are Involved With ActiveX Programming Technique?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
28/11/2007 |
|
Status: Verified
GOAL:
What Rules Are Involved With ActiveX Programming Technique?
FACT(s) (Environment):
Progress 8.x
Progress 9.x
OpenEdge 10.x
CAUSE:
In general, Progress guarantees that the 4GL client will not fail with a General Protection Fault (GPF). Thus, if it does GPF, this usually indicates a Progress bug. However, when either ActiveX Controls or ActiveX Automation objects are involved there can be causative factors that are not attributable to Progress.
FIX:
Every time a COM-HANDLE variable is set to an object Progress calls the object to tell it to add a reference to itself so that it knows that someone is using it.
When the 4GL does a RELEASE OBJECT on a COM-HANDLE variable, we call the object to tell it to subtract a reference to itself. If the ActiveX component adheres to the rules, the object should only go away when all references to it, or to its sub-objects, goes to zero.
Unfortunately, some ActiveX Controls or Automation objects do not implement this properly. In particular, it is not uncommon for an ActiveX Control with sub-objects to destroy itself when references to the top-level object have gone to zero but when there are still outstanding references to sub-objects. Because of this, it is important that correct coding practices be used when dealing with COM-HANDLEs.
The rule is that the 4GL application is responsible for calling RELEASE OBJECT on all COM-HANDLEs that it obtains. If it doesn't, Progress will attempt to do the release when the Progress session terminates. However, if the ActiveX object has not followed the standard rules, a GPF might occur at this time.
One exception to this rule is that the handle for an ActiveX Control, will be released automatically when DELETE WIDGET is used on its CONTROL-FRAME. Therefore you do not have to explicitly call RELEASE OBJECT on the COM-HANDLE for the control. However, if there are COM-HANDLES that refer to sub-objects of that control, the application should have already released them before it calls DELETE WIDGET. If the application calls RELEASE OBJECT on the sub-objects after it does DELETE WIDGET this also could potentially result in a GPF.
In Progress Version 9.1D and beyond, we applied the technology to prevent these particular GPF's. However, it is still strongly recommended that applications be coded correctly, according to the rules above. Without adherence to these rules, an inverse problem may occur. When the OCX or Automation object *does* follow the rules, if COM-HANDLES are not released appropriately, resources may be held long past the time they are being used.
Below is an example of an incorrectly coded program. In this example, chCtrlFrame is a handle to a TreeView ActiveX control.
NOTE: that the COM-HANDLE chParent is reset without either doing a RELEASE OBJECT or saving the value so that RELEASE OBJECT can be called later on in the application:
/* incorrectly coded */
DEFINE VARIABLE chParent AS COM-HANDLE NO-UNDO.
DEFINE VARIABLE hMainBranch AS COM-HANDLE NO-UNDO.
hMainBranch = chCtrlFrame:TreeView:Branches.
chParent = hMainBranch:Add ( 1, 0, 'Node 1':U).
chParent = hMainBranch:Add ( 1, 0, 'Node 2':U).
chParent = hMainBranch:Add ( 1, 0, 'Node 3':U).
One correct way to code this would be:
/* correctly coded */
DEFINE VARIABLE chParent AS COM-HANDLE NO-UNDO.
DEFINE VARIABLE hMainBranch AS COM-HANDLE NO-UNDO.
hMainBranch = chCtrlFrame:TreeView:Branches.
chParent = hMainBranch:Add ( 1, 0, 'Node 1':U).
IF VALID-HANDLE(chParent) THEN
RELEASE OBJECT chParent.
chParent = hMainBranch:Add ( 1, 0, 'Node 2':U).
IF VALID-HANDLE(chParent) THEN
RELEASE OBJECT chParent.
chParent = hMainBranch:Add ( 1, 0, 'Node 3':U).
IF VALID-HANDLE(chParent) THEN
RELEASE OBJECT chParent.
/* After the TreeView control is no longer needed */
RELEASE OBJECT hMainBranch.
References to Written Documentation:
Progress Solutions:
Solution 18250, "ACTIVEX - How to Avoid Getting GPF's."
Solution 18762, "ACTIVEX - One Way to Manage Your COM-HANDLE References."
Solution 18800, "ACTIVEX - How We Handle Object References (COM-HANDLES)."