The answers you got are not wrong at all, but may not give the understanding you need.
First of all I'd state thisform.release() closes a form, no matter what else happens or is done in form code. Stefan and MarK correctly point out the events that happen when you close a form also happen in this case, but one event especially is skipped: The form.QueryuUnload() event, that allows you to check how a form is closed by checking the forms releasetype property.
So in that sense Thisform.Releases ensure the closing of the form, whereas skipping it CLOSE ALL is a command that would also close forms, but that could be hindered whereas thisform.release() can't be hindered to close the form. On the other hand CLOSE ALL closes more things than just thisform, well simply as it says, it closes all.
As Mark pointed out, it's important to know about events and their order of happening, too. CLOSE ALL sounds extreme and enough to end any tidy up everything, but you have to know indeed it could also be called "TRY" CLOSE ALL. As CLOSE ALL only can try to close all file handles, workareas, forms and maybe more I forgot. But in case of forms, for example, it still triggers events like the Destroy) event, the Unload/() event, and also QueryUnload(). And there are ways these events can stop and hinder the closing and keep a form up and open, so after CLOSE ALL there can still be forms open.
All in all, I'd say this code is okay, there's no need to change it from this perspective, because of thisform.release() taking care of releasing the form. Stefan is right, that the further commands could also be put into the form unload event as that always happens. It's a matter of taste if you therefore do split up code and have it in two places.
Overall, it's quite a complicated topic and important to know about, so a good time to study events. Especially form events, as forms have more events than other classes. For example, almost all classes (except the empty class) have an init and destroy event as the initial and last event, the form also has a load and unload on top of that, where form.load() comes even before form.init and form.unload() hppes after form.destroy(). Besides forms have the QueryUnload event, which is yet another event at the end of a form's life. Forms are very intricate about what happens in them, as they are very complex. There's the dataenvironment, too, that's actually its own object with more events all happening also in some order with the forms initial and final chain of events, too.
From a larger perspective, it would even only be a good idea to have CLOSE DATABASES ALL and CLOSE ALL in a final code that's called ON SHUTDOWN on one side and after READ EVENTS on the oher side. Because if you have multiple forms in your application, you don't want the closing of one of them close all data, that's too early and CLOSE ALL then is too rigorous anyway. So this code, if it belongs to a form at all, then only to the main form of the application that's started first and closed last.
It's actually a good idea to not put such code into forms at all, so you always have the option to extend the application further into something that may not only have one main form Maybe it would even start with only the _Screen open and a menu and what form users start is upon them.
Final closing code belongs into either a routine that's triggered by ON SHUTDOWN and then also code that runs after the READ EVENTS should call into that to "close the curtains" and do all tidy up stuff at the end of an application. And you can make that a principle and do it even in case your application only is a single-form application because it's a concern and therefore also a task of the application, not any form, not even the main form of an application. So even though you can consider the close button of a main form the close button of the application at the same time, its still mainly just the close button of the form, and the closing of the application should ideally only be a consequence of the closing of the main form, i.e. what happens after the main form has closed should tidy up and quit the process, not the form itself.
If you know more about events you'll have more insight into why developers might still opt for such solutions. The CLEAR EVENTS command, for example, that causes VFP to continue after READ EVENTS can be hindered to do exactly that by any modal state like a report preview still open. Which makes code easier, that is more rigorous, like CLOSE ALL is.
Chriss
