POOL
Memory pools provide a local memory heap that can be used to dynamically allocate string, structure or objects using the NEW keyword.
Pools do not have a fixed size and are identified by an opaque number that can be used in the optional USING clause of a NEW expression.
Pools are associated with the enclosing stack frame and any function can get the identifier of the pool for that function by using GET POOL. These pools are automatically destroyed when the function returns and its stack frame is cleaned up. A pool and the objects in the pool will be available to the function and any functions executed inside that function. Once the pool has gone out of scope all the objects in its pool will be destoyed and the PTR references to them will be invalid.
Because forms are stack based objects they have their own pools that you can access using the .pool property.
Because pools are associated with the stack, you can only use GET POOL inside a subroutine. However it is also possible to create pools with CREATE POOL where the application takes responsibility for cleaning up the pool using DELETE POOL. If these are created with a USING; they will be created as a child allocation of the USING poolid and will be cleaned up automatically when that is deleted. These may be given an optional name; if one is provided, it can be retrieved with 'KCML_Debug_GetPoolName$().
Status
Experimental.
Compatibility
Introduced with KCML 7.00.
Syntax examples:
mylocalpool = GET POOL
myglobalpool = CREATE POOL
DELETE POOL myglobalpool
See also: