Question widget-pools

[KrisM]

When you have the name of a widget-pool, is it possible to get a list of dynamic objects created in this widget-pool ?
When you have a handle to a dynamic object, is it possible to get the name of the widget-pool the object is created in ?

 

[GregTomkins]

I believe the answer to both is NO ... which makes it difficult to look into complicated memory problems ... if someone knows otherwise, I'd like to know about that!

 

[Cringer]

I suppose you could roll your own though? If you can get the handle to the widget pool when it's created, then store it in a TT with the name?

 

[GregTomkins]

I think widget pools predate handles ... far as I know, they're completely opaque.

 

[Cringer]

Ah yes you're right. I had a foggy memory of using

CREATE WIDGET-POOL lv-WidgetPool PERSISTENT NO-ERROR.

But forgot that lv-WidgetPool is a character variable with the name in it.

 

[RealHeavyDude]

Excuse me for stepping in late.

Widget pools are still very relevant with handle-based dynamics objects. They can or do ( when not understood or not used properly ) play a fundamental role in the life cycle of handle-based dynamic objects and thus preventing or supporting memory leaks in unexpecting ways when you are not familiar with them.

Nevertheless, till now, Progress fails to offer functionality within the ABL to examine the contents of widget pools. Therefore there is no way to find out which objects are grouped into which widget pool or to which widget pool an objects belongs unless you already know. This one really bothers me as there is no such thing like a garbage collector ( like the one that was introduced in OOABL for "real" objects ) - and you as a developer have to take full responsibility of the life cycle of handle-based dynamic objects. Widged pools are one way to do that.

The rule of thumb is: If you don't do anything handle-based dynamics objects will most likely wind up in the unnamed widget pool scoped to the ABL session. Therefore coding "create widget-pool no-error." at the beginning of any procedure ( there is a pendant for classes ) will be good practice in most cases. That way the handle-based dynamic objects will wind up in the unnamed widget pool scoped to the procedure and deleted when the procedure goes out of scope. You might create additional named widget pools as you need. They will be automatically scoped to the procedure in which they are created unless you specify persistent which will scope them to the session - which might be a dangerous thing for creating memory leaks.

Heavy Regards, RealHeavyDude.