Delphi

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.

It is sometimes desirable to write code that deals with databases but is not associated with any particular form or user-interface details. To do this, you declare variables of type TDatabase, TTable and/or TQuery, and set their properties in code just as you would in the design environment. Make sure that you include the DB and DBTables units in your uses statement, or you will get "unknown identifier" errors during compilation.

There is no way to do this within the Delphi VCL. Seems like a pretty serious omission to me. However, it is possible to do it by talking directly to the Borland Database Engine through the interface provided by the DBIPROCS and DBITYPES units. You call DbiDoRestructure, but set all the "number of" variables to zero, which makes it leave the existing values intact. I have code to do this, but it's a bit too long to included here. E-mail graham (at) mhn.org if you want it.

If you look at the declaration, the Sender object is of type TObject, which is the class from which (almost) all other objects are derived. You're probably trying to access a property that isn't defined in TObject, like Text or Caption or something. For this reason, "Sender.Text" will fail, but if (for example) you know that the sender is of type TEdit, then you could use "(Sender As TEdit).Text". If you aren't certain that the Sender object will always be the same type, you can check it with "if (Sender is TEdit) then < blah> ;". See section 5.14.

By default, the internal debugger will halt any time there is an exception, even if the exception is trapped by code. This can often be useful for debugging purposes. If it offends you, turn it off. You control it from the Options/Environment menu.

Based on the number of postings to comp.lang.pascal, it would seem that by far the largest number of problems calling Windows API functions or non-Delphi DLLs are caused by passing Pascal-style strings to functions that expect null-terminated (PChar) strings. This is the first thing you should check if you get a GPF or other strange results when calling an external function. See section 6.11 for more information on which type of strings go where.

Just like C: You can get a far pointer to your callback procedure (you have to remember to declare it with the "far" qualifier, unless you have {F$+} in effect to force all calls to be far), pass the pointer to the Windows callback function, and there it is.

Delphi always assumes that the color of the bottom left-hand corner pixel is the background color and should be displayed as transparent. Yes, it took me a while to figure this out. It's not documented anywhere, but if you have the VCL source, you can look at the code in BUTTONS.PAS.

Use the Application.OnException event. Look in the help under "application events" for details of how to create and attach an event handler to the application variable.

Each form has a property called Handle, which contains the form's hWnd. Many controls also have hWnd properties. However, don't try to pass Canvas.Handle to an API function expecting a hWnd, because TCanvas's Handle property is a hDC, not a hWnd.