There is an automated translator that converts Visual Basic projects to Delphi. I have heard from a couple people who have tried using it, and the results seem to be pretty mixed. It's very useful for some people, but not useful at all for others. It is made by:
7 Mountain Rd.
Burlington, MA 01803
Generally speaking, you call the form's Close method. This runs the OnClose event, which may decide it doesn't want to close, for example if there is unsaved data in the form. Close doesn't free the memory associated with the form, unless of course you put a call to Release in the form's OnClose event.
If you want to close a form without giving it a chance to argue, call the form's Release method. This is similar to Free, but it allows event handlers (e.g. OnDestroy) to finish running before the memory goes away.
Modal forms "end their modal state" when you set the form's ModalResult property to anything greater than zero. If you put a button on a modal form and set the button's ModalResult property to some value, then when the user clicks on that button the form will close with the result you specified. You can find out what the result was by calling ShowModal as a function; i.e. result := Form.ShowModal.
There seems to be a feeling that you need to know more about Windows to use Delphi than you do to use Visual Basic. This isn't really true; you can get by in both environments with a very minimal understanding of Windows internals. However, in both environments, you have to know at least a little about the Windows API in order to really make the most of what you have. The difference is that Delphi gives you a lot more power to do all these interesting things, so you feel more limited if you don't know how.
Well, yes, to a point. Delphi's user interface design tools produce object-oriented code. However, if you're familiar with either Visual Basic or Powerbuilder, you probably have enough understanding of OOP to get by. You can do a great deal in Delphi without having to create your own objects, which is the point at which it becomes important to really understand something about them.
The basic structure goes something like this:
p := new(big_thing);
The first line allocates a big block of memory. Then, in the "try" block, we execute several statements, each of which might produce an error--or, in other words, "raise an event." If an error does occur, the rest of the "try" block will be skipped, "finally" blocks will be executed. If there are no errors, then the "finally" block will be entered when the last statement in the "try" block completes. So, either way, the big block of memory gets freed. These "try/finally" blocks will trap anything up to and including a Windows GPF.