Bug #5254
FWD extension control must follow the lifetime of the counterpart 4GL OCX/ActiveX
0%
Related issues
History
#2 Updated by Greg Shah about 3 years ago
- Related to Feature #1818: implement a timer service to replace the PSTimer OCX added
#4 Updated by Greg Shah about 3 years ago
Reproduced from #3952-4 (from Constantin and Ovidiu):
After a discussion with Ovidiu and some inspection of
<customer_application>
4GL code, I'm posting this here, but this may be a larger problem whenCREATE CONTROL-FRAME
is used.The
But this is a common problem for other OCX/ActiveX controls which get converted to FWD extensions:CONTROL-FRAME
is a widget which can be added to a widget-pool (and the application adds it to an unnamed widget pool). When we convert PsTimer, we don't add it there - I fixed this to add it at least to the unnamed widget pool, if there is one; so when the unnamed widget pool gets deleted, the PSTimer thread gets cleaned up, too.
- don't know how FWD conversion rules behave if we have
CREATE CONTROL-FRAME ... IN WIDGET-POOL
- does this emit the named widget pool name?- if the CONTROL-FRAME (or its widget-pool) gets deleted, does the OCX/ActiveX get unloaded in 4GL, for every kind of OCX/ActiveX?
- TABSET is a widget, this is automatically added to the unnamed widget pool. Don't know if the named widget pool works or not.
- MsgBlaster has some protections that it deletes itself if its HWND widget is no longer alive - so I'm leaving this for now as it is.
The short part is: a FWD extension control must follow the lifetime of the counterpart 4GL OCX/ActiveX - and we are currently at least missing some WIDGET-POOL behaviour.