Kbase P11977: Dynamic widgets created in wrong default unnamed widget pool
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
09/05/2011 |
|
Status: Unverified
SYMPTOM(s):
Invalid widget-handle. Not initialized or points to a deleted widget. (3135)
Invalid or inappropriate handle value given to RUN...IN statement. Procedure '<calling-procedure>':<line-number>. (2128)
One closes a window then some widgets disappear in another window
One kills (deletes) the procedure of a dialog or of a window but a zombi dialog or window remains at the screen
Dynamic widget/Objects created in a super procedure of container
Dynamic widget/Objects created in wrong default unnamed WIDGET-POOL
Widgets/Objects are created in the WIDGET-POOL of the SOURCE-PROCEDURE instead of the expected one of the TARGET-PROCEDURE
FACT(s) (Environment):
Progress 9.X
OpenEdge 10.0A
CAUSE:
Known issue that can lead to many different symptoms. In some cases, the unnamed WIDGET-POOL chain of the session is corrupted during a context switch (super procedure mechanism), so the default unnamed WIDGET-POOL might become the wrong one for a while.
One possible case has been reported as 20021120-004 and fixed in 10.0B. However, another case has been reported to development more recently:
When super procedures are involved then dynamic widgets can be created in the unnamed WIDGET-POOL of the SOURCE-PROCEDURE instead of the one of the TARGET-PROCEDURE. For example:
WindowA calls createButton in WindowB. CreateButton is only in a super proc of WindowB and it creates a dynamic button in windowB, but in the
WIDGET-POOL of WindowA (that is the SOURCE-PROCEDURE of createButton) instead of the WIDGET-POOL of WindowB (that is the TARGET-PROCEDURE of createButton).
Note that this problem occurs with both simple SUPER procedures and SESSION SUPER procedures
Note that if no super procedure is involved (createButton is only in windowB) or if there is a dummy entry of createButton in windowB with only 'RUN SUPER', then the button is created in the right widget pool (the one of windowB).
CAUSE:
Bug# 20021120-004 Fixed in 10.0B
FIX:
One solution is to use a named PERSISTENT WIDGET-POOL to create the widgets in. You might use a name such as "MyWp" + STRING(TARGET-PROCEDURE:UNIQUE-ID) to keep it unique. For smartWindows, this WIDGET-POOL should be created in initializeObject, and deleted explicitly in destroyObject with the DELETE WIDGET-POOL Statement.
Now it is possible to fix the problem without using named PERSISTENT WIDGET-POOL's, especially if the problem occurs when dynamic widget/objects are created in a super procedure. Have a dummy entry in the TARGET-PROCEDURE with only RUN SUPER. This makes the entry of the super procedure be called from the TARGET-PROCEDURE instead of another procedure, which puts the WIDGET-POOL chain back in synch with the TARGET-PROCEDURE.