As most non-trivial applications require, you've
probably found yourself creating secondary forms when designing
your applications. And you've probably discovered that this is very easy to do with Power++.
However, there is a hard lesson to be learned by most programmers
(including myself) when trying to dismiss these secondary forms.
The situation is this: your parent form creates a new modeless
form using the new
operator and the Create method.
The parent form then continues on its merry way, and the
secondary form is left to its own devices. The code might look
Form2 * f2 =
( this );
After the secondary form performs some
operations, it is ready to close itself. The crux is that using
the Close method
does not free all of the resources associated with the form; it
only frees resources that were allocated using the
Create method, not those
allocated when using the new operator. Without some additional effort,
however, the secondary form has no way of notifying its parent
that it is done and that the parent should perform a delete on
it. Thus most programmers assume that Close
performs all necessary cleanup; this leads to some rather major
memory leaks if secondary forms are opened frequently. For those
of you who know C++ relatively well, you also know that using
this ) is an unacceptable
alternative, as it may interfere with event handles, and also
causes execution of the method that called the
delete operator while the
memory associated with the method has already been deleted.
In anticipation of this
problem, Power++ includes functionality to make the task of memory
cleanup much easier. In the WApplication
class is a method called RegisterDeleteObject. This
method will take a WObject
argument, and slate the object to be deleted at a time when it is safe
to do so. Thus, we can easily add the method call to the Close
event of the form. The code might look like that at right.
Please note that the RegisterDeleteObject
call must be in the Close
event of the form for Power++ version 1.5. If you call this
method after the Close
event has executed, you will get a page fault.
RegisterDeleteObject method has be enhanced for version 2.0 so
that it may be called from anywhere safely.
To see this in action, you can choose
the View|Debug Log
from the main Power++ window, and then choose
see the available debug options. This window appears at left. By selecting
the second option, we can have a summary of allocated and freed
memory at the termination of the application. There are other
options related to debugging and tracing, and can be seen. The
first option will check to see if any memory within the
application is overwritten (outside of the application will cause
a Page Fault), the third option is for more detailed memory
allocation examination, as is the fourth.
The graphic at right is the output of
the debug log after the application has terminated. It is an
example of the type of memory leak that might occur without the
in the Close event
of the form. Five forms were allocated, then removed with the
Close event only - this
is why there is a smaller number of deallocations than
allocations, indicating unreleased memory. In this example, we
can see that 12K remains unfreed; the form that was created was
very basic - more complicated forms with more controls and
resources associated with them will leave a much greater amount
On the left we have the same program
with the necessary call to RegisterDeleteObject in the Close
event of the form. You can see that the numbers are now as they
should be - there are the same number of deallocations as there
are allocations, and the same applies to the number of bytes.