Can some throw light on rules/recommendations of where to use the USE-WIDGET-POOL.
Assume that I am creating a class such as
CLASS gs.daGsCalculate:
End Class
This class has static definitions of temp tables and datasets.. and the methods in this class also has a static difintions of QUERY and Datasources such as
DEFINE QUERY qry FOR mydb.contract.
DEFINE DATA-SOURCE src FOR QUERY qry.
And there are no object dynamically created and there are no UI/Ultra controls etc in this class.
Do I still have to use the USE-WIDGET-POOL cluase in class definition or its in unnecessary in above scenario ??
Or does Progress recommends to use the USE-WIDGET-POOL at all times ??
thanks
This is a very interesting question.
We have pondered about it a lot and it drives you crazy once you start thinking about USE-WIDGET-POOL at different levels in inherited classes.
I believe our final consensus was that it never hurts to use USE-WIDGET-POOL and that we would have liked it to be the default.
I am curious to find if others arrived at different conclusions.
For your example, you don't need widget pools at all. But that can change with a single statement.
My counter-question is: can you give an example where USE-WIDGET-POOL hurts? Are there any other downsides, such as resource usage?
First of all UltraControls and other class based objects have absolutely nothing do to with widget pools. That are two different strategies for garbage collections.
Here's my suggestion, don't know if Progress recommends different:
A widget pool is for everything that is dynamically created (explicit or implicit like OUTPUT TABLE-HANDLE parameters) and can be referenced by a variable of type HANDLE (WIDGET-HANDLE).
When you don't create anything dynamically there's no need for a widget pool! In your sample that seems to be the case.
When all widgets/database objects that are created dynamically in that class/object are just scoped to a single object instance then the USE-WIDGET-POOL in the class definition is a good idea, a safety net, because the widgets/database objects will be deleted automatically with the object instance that created them.
But when an object passes the handle of created widgets/database object to another object then you may need to care about the USE-WIDGET-POOL. Think of one object creating a dynamic buffer object and another using that. This might be the case when you have an utility class (maybe a singleton for creating and preparing things like dynamic queries etc.). In this case somebody else may be responsible for deleting those widgets/database objects.
A good question is, if the USE-WIDGET-POOL in a class that creates nothing dynamically is an overhead or not ???
rbf schrieb:
I believe our final consensus was that it never hurts to use USE-WIDGET-POOL and that we would have liked it to be the default.
Good idea for an ERS, I'd say. Similar behaviour to the ROUTINE-LEVEL error handling flag in the new class wizard..
For your example, you don't need widget pools at all. But that can change with a single statement.
Exactly.
My counter-question is: can you give an example where USE-WIDGET-POOL hurts? Are there any other downsides, such as resource usage?
Those rare cases where a class is just a producer, a factory for some widgets that may have to live longer than the factory. In this case the rule, if you create it, delete it should be modified to if you let someone create it for you, delete it.
My counter-question is: can you give an example where USE-WIDGET-POOL hurts? Are there any other downsides, such as resource usage?
Those rare cases where a class is just a producer, a factory for some widgets that may have to live longer than the factory. In this case the rule, if you create it, delete it should be modified to if you let someone create it for you, delete it.
Theoretically. For me it is hard to imagine a factory that is terminated before the end of the session as these are singletons or statics by nature. But I guess it is something to take into consideration.
Theoretically. For me it is hard to imagine a factory that is terminated before the end of the session as these are singletons or statics by nature. But I guess it is something to take into consideration.
Agreed with both.
And for us these query factories as implemented as static classes, so they never get away before the session ends.
But it's some of these cases where I'd say, never say never. Or at least: Be aware that there may be exceptions to the good rule.
To answer the question about overhead: Yes, there is a little overhead from using USE-WIDGET-POOL, even when there's nothing created that goes into the widget pool. On 32-bit Windows, for example, it was 56 bytes for the structure that's used for managing the pool when I checked just now.