Resource Leakage
A common resource utilization issue encountered in Windows applications is that when you close a window not all of the resources associated with it are freed up for reuse. This is called ‘resource leakage’ and if left unchecked it may eventually cause your application to fail or act unpredictably. To help you in this area the VLF includes a simple diagnostic tool to track some resource leakage at a high level.
These facilities are only activated when you use the VLF as a designer.
If you open and close a secondary Framework window and see a message like the example below, it indicates a resource leakage detected by the VLF:
This message is saying that a VL component (in this case a command handler instance named DF_DET1) was not destroyed when the window was closed.
In other words, DF_DET1 has ‘leaked’ resources. You should investigate the cause of this and try to prevent it. If you can’t work out why this message is being displayed you should consult your Visual LANSA mentor for VL application design advice.
In VLF applications of simple to medium complexity you are unlikely to see this message. However as the sophistication of your VLF and VL application components increases you may encounter this message.
A common cause of this message is what is called a ‘circular reference’. This is where one VL component (say, a command handler ‘A’) contains a reference to some other object (say, a reusable part named ‘B’) which itself contains a reference back to command handler ‘A’.
The circular reference path may be even more complex. Component ‘A’ might refer to ‘B’ which refers to ‘C’ which refers to ‘D’ which refers back to ‘A’. This is a much longer path, but it is still circular in nature.
Some rough guidelines for avoiding circular references:
- Try to avoid using Reference(*Dynamic) variables or object reference collections that are scoped across an entire BEGIN_COM/END_COM block (that is, across your whole VL program).
- When they are used, make sure that structured logic is in place (and used) to remove or nullify any object references that they may contain.
- When Scope(*Application) variables or collections are used to track object references make sure that logic is in place (and used) to remove the references again at the appropriate time.
In other words, imagine you are an object instance called ‘A’ and that other objects store references to you in their variables or collections. If you want ‘A’ to be destroyed, then you need to make sure all referencing objects drop all their references to ‘A’ first. Object ‘A’ will not be destroyed as long as any object holds a single reference to ‘A.
Important Disclaimer: This VLF facility is a diagnostic feature. It only tracks resource leakage in objects that are ‘known’ to the VLF runtime environment. As you create more sophisticated VLF applications they could in turn create and destroy many objects that the VLF runtime does not know about and therefore cannot track or report on. Just because you do not see the preceding message box it does not mean that your application is not leaking resources.