Project

General

Profile

Bug #5254

FWD extension control must follow the lifetime of the counterpart 4GL OCX/ActiveX

Added by Greg Shah about 3 years ago. Updated about 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:

Related issues

Related to User Interface - Feature #1818: implement a timer service to replace the PSTimer OCX Closed

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 when CREATE CONTROL-FRAME is used.

The 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.

But this is a common problem for other OCX/ActiveX controls which get converted to FWD extensions:
  • 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.

Also available in: Atom PDF