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.