FiveTech Support Forums

I know of FONT.
I am not sure about brush and pen.
Are there others?

Thanks in advance
Otto

Generally speaking, any resources that you explicitly create you have to explicitly release.

EMG

Otto,

It is a good idea to call the End() method of every object you create; even if it is not actually needed. This way you don't have to remember which ones need it and which don't.

This is also why I suggest including an End() method in any class you create.

James

James,

You don't need to explicitly End() TGets, TComboBoxes, TDialogs, etc.

EMG

Enrico,

You don't need to explicitly End() TGets, TComboBoxes, TDialogs, etc.

Controls like gets and comboboxes, no, but I always end dialogs. How else do you close them?

I was just saying that if you are not sure if you need to call End() then it is better to just do it and then you don't have to worry about resource leaks, files left open, etc.

James

James Bott wrote:Controls like gets and comboboxes, no, but I always end dialogs. How else do you close them?

Generally is the user that closes the dialog.

James Bott wrote:I was just saying that if you are not sure if you need to call End() then it is better to just do it and then you don't have to worry about resource leaks, files left open, etc.

I don't think this is a correct approach. It's always better to know what's going on. It's even possible (but I'm not sure) that double release can cause some kind of problems.

EMG

If you review Class TWindow Method Destroy() you will see that all the resources used by a window are automatically End()ed.

This applies to dialogs and controls too as they both inherit from Class TWindow

Enrico,

Generally is the user that closes the dialog.

Ah, I guess you mean using the close button on the title bar. I remove those, so the user has to use the buttons on the dialog and the OK or Close button has to call oDlg:end().

I don't think this is a correct approach. It's always better to know what's going on.

I agree. I guess we would need a complete list of which classes need to be ended by the programmer and which don't.

It's even possible (but I'm not sure) that double release can cause some kind of problems.

I have never run into such a problem, but I suppose it is possible.

James

Please review Class TWindow Method Destroy() source code

Any other GDI object that is not listed there as a DATA, has to be End()ed manually, as Enrico has pointed.

Anyhow, Windows automatically will take care of those GDI objects even if we don't explicity release them, when the app finsihes.

The problem only comes when a GDI object is created again and again from the application, so the the GDI memory is wasted and Windows won't act as it doesn't know if they are still needed or not.

James Bott wrote:Ah, I guess you mean using the close button on the title bar. I remove those, so the user has to use the buttons on the dialog and the OK or Close button has to call oDlg:end().

Ops! Yes, you are right. I forgot oDlg:End() in Close button.

James Bott wrote:I guess we would need a complete list of which classes need to be ended by the programmer and which don't.

As I already said, any resource you explicitly create (and I add now, you don't attach to a dialog or to a window) you have to explicitly release.

EMG

Antonio Linares wrote:Anyhow, Windows automatically will take care of those GDI objects even if we don't explicity release them, when the app finsihes.

Are you completely sure? Please, can you point me to where, in the Windows docs, this is clearly stated?

EMG

Enrico,

http://msdn.microsoft.com/en-us/library/ms724291(VS.85).aspx

"Handles to GDI objects are private to a process."

So when the process is finished, all its environment is cleared, unless you have created global handles (i.e. using GlobalAlloc()).

http://msdn.microsoft.com/en-us/magazine/cc301756.aspx

"... the documentation states that Windows takes care of releasing the resource used by a process when it exits ..."

Anyhow, Windows automatically will take care of those GDI objects even if we don't explicity release them, when the app finsihes.

Even though they will be cleaned up when the app ends, unreleased GDI objects can become a problem if the app is run for a long time. So for such apps as order entry, reservations systems, etc. which may be run continously it is more important to release these manually.

James

Antonio Linares wrote:Enrico,

http://msdn.microsoft.com/en-us/library/ms724291(VS.85).aspx

"Handles to GDI objects are private to a process."

So when the process is finished, all its environment is cleared, unless you have created global handles (i.e. using GlobalAlloc()).

Sorry, but the docs says:

GDI objects support only one handle per object. Handles to GDI objects are private to a process. That is, only the process that created the GDI object can use the object handle.

"can use" doesn't mean that the GDI objects are automatically released when the process exits.

Antonio Linares wrote:http://msdn.microsoft.com/en-us/magazine/cc301756.aspx

"... the documentation states that Windows takes care of releasing the resource used by a process when it exits ..."

Sorry again, the docs says:

Even if the documentation states that Windows takes care of releasing the resource used by a process when it exits, this is not enough for server applications that must be extremely reliable.

Note "this is not enough".

EMG

Enrico,

There are only two ways to manage the memory: locally and globally.

Global memory is shared by the entire operating system. Local memory is allocated from the heap of a process. The heap is local to a process and when the process is released, its heap is also cleared.

This is common to all operating systems.

Anyhow if you want to read the exact words from Microsoft, then lets keep googling for it