Memory management is also an issue for other object types that are not discussed in this guide, but which this section mentions briefly:

  • MEMPTR — A MEMPTR is a pointer to an area of your computer’s memory that you allocate and use independently of any ABL objects. You are fully responsible for controlling this memory. You allocate memory using the SET-SIZE function. You deallocate it by using SET-SIZE to set the size to zero. There are other functions that manipulate memory allocated with a MEMPTR, but the AVM does not recognize the form of the contents in any way.
  • ActiveX control — You can extend the visual content of your user interface and other aspects of an application that runs on MS Windows using ActiveX controls. You access an ActiveX control through a special handle called a COM-HANDLE. You are responsible for using a special RELEASE OBJECT statement to release memory associated with the object. Because ActiveX controls operate outside the bounds of objects known to ABL, and because they can do so much on their own, they can be a major source of memory leaks. You need to use and test them very carefully.
  • Socket — A socket is a connection to a process running outside the OpenEdge session, possibly on another machine. OpenEdge provides access to other procedures through its support for sockets. A SOCKET is another kind of dynamic object you can create and use from ABL. You must clean up sockets just like any other objects. There is a special SESSION:FIRST-SOCKET attribute that lets you access the head of the chain of all the sockets allocated in your session.
  • Asynchronous request — You can run a procedure in another OpenEdge session with a special ASYNCHRONOUS keyword to allow your session to continue to run until the other session responds. A procedure run in this way is kept in memory even after the request is complete so that you check the completion status. You must take special care to delete these procedures when you are done with them. There is also a SESSION:FIRST-ASYNC-REQUEST attribute that identifies the chain of all outstanding asynchronous requests in your session.

There is a certain amount of information on these special types in the ABL Reference, but you will find detailed information in OpenEdge Programming Interfaces.

Conclusion

Memory management in ABL is not that difficult if you establish a standard set of templates for your procedures and an architecture that makes it clear what procedures are responsible for creating dynamic objects and deleting them, and when your session is done using them. If you are organized in your design and test your application carefully, you should have no trouble creating a reliable application that makes appropriate use of the power and flexibility of dynamic objects. Just remember the basic rule: You create it, you delete it!