uses

SysUtils, WinTypes, WinProcs, Messages, Classes, Graphics, Controls,

Forms, Dialogs;

These are the default units which are available to all new forms. You don't need to add any of them to your project; Delphi does this for you. Their presence in the uses clause makes their functionality available from within the form. Some of these are significant. For example, WinProcs and WinTypes add all of the functions of the core Windows API. Some of these such as Classes, Graphics, Controls and Forms are required by Delphi to make forms work within your application. You should remove units from this default list with care. In most cases, you won't touch this list because if no functionality from a particular unit is exploited, the code for that unit is not linked in. If you would like to exploit the functionality of Unit1 inside of Unit2, you need to include Unit1 in a uses clause within Unit2.

Like modules, units may contain procedures, DLL declarations, user-defined types and global variables and constants. There are two sections to a unit, the interface and the implementation. The interface is the "public" area of the unit and functionality defined in that area is available anywhere in the application where that unit is listed in a uses clause. The implementation portion of a unit defines the "private" area of that unit so variables, constants and functions defined only there are available only within that unit. This is discussed further in the discussion of variable scope and procedures below.

So, remember that adding a unit to a project is just a convenience for editing and compiling. If you want to access the functionality of that unit, it must find its way into a uses clause in your code.

In Visual Basic, if you use the Dim keyword inside a procedure definition, you are defining a variable which is local to that procedure. Likewise if you add a variable to the var section of a procedure in Delphi, you are defining a local variable. There is no equivalent to a static variable in Delphi, but a static variable is really just a module level variable which is used in only one procedure. It is a naming convenience more than anything else.
In Visual Basic, if you use the Dim keyword in the declarations section of a module or form, you are creating a module level variable. Likewise, if you place a variable in the Var clause of the Implementation section of a unit, you are defining a unit level variable (i.e. one which can only be seen from within that unit).
In Visual Basic, if you use the Global keyword in the declarations section of a module, you are defining a global variable. In Delphi, you simply put a variable in the var clause of the interface section of a unit and that variable is available to any other unit which includes the variable's unit in its uses clause. The following code segment helps to clarify:

unit MyUnit;

interface

uses

WinProcs, WinTypes; {these are the units used by this unit}

var

globalInt:integer;

globalStr:string;

implementation

var

unitInt:Integer;

unitStr:String;

procedure unitProc;

const

staticInt:Integer = 0;

staticStr:String = '';

var

localInt:Integer;

localStr:String;

begin

{code goes here}

end;

end.

The preceding was a complete unit with an interface and an implementation section. The variables defined in the interface section are global. The variables defined in var clause of the unit are unit level and finally those defined in the var section of the procedure are local.
Be aware that unit-level variables created inside a form are available across multiple instances of that form. In other words, unlike in Visual Basic, those variables exist only once per application so even though you might have multiple instances of a form, unit level variables are shared. The way around this is to define a set of variables as part of the new form class you are creating. A typical form definition might look something like this:

type

TForm1 = class(TForm)

Button1: TButton;

Button2: TButton;

private

{ Private declarations }

public

{ Public declarations }

end;

You can create the equivalent of VB's "form level" variables by adding them to the private section of the form definition. So the change might look something like this:

type

TForm1 = class(TForm)

Button1: TButton;

Button2: TButton;

private

{ Private declarations }

formInt:Integer;

formStr:String;

public

{ Public declarations }

end;

If you don't create multiple instances of your forms in your applications, you'll never know the difference between unit level and form level variables. However, a great many MDI applications begin as single form applications so it is best to use the most restrictive level of scoping you can for flexibility in the future.

OpFlag := TButton(Sender).Caption[1];

to assign the first character of a string to a variable of type char. Remember from above that you cannot use the case statement on a string but you can on a single character. This statement allows you to retrieve the first character of a string as its ASCII value for use in a case statement.

Likewise, if you need to create an LPSTR to pass to an API function, you can construct one in a string and pass its address like this:

procedure TForm1.Button1Click(Sender: TObject);

var

S:String;

begin

S := 'Hello World'#0;

MessageBox (0, @S[1], 'Test', 0);

end;

The actual Delphi data type that corresponds to the LPSTR in C is the PChar which is a pointer to a character array. There are a series of functions designed to manipulate PChar-style strings for such things as assignment, concatenation and comparison. Search for "String-handling routines (null-terminated)" in online Help for a list of the relevant functions. The above code implemented using PChars would look something like the following:

procedure TForm1.Button1Click(Sender: TObject);

var

P:PChar;

begin

P := StrAlloc (256);

StrPCopy (P, 'Hello World!');

MessageBox (0, P, 'Test', 0);

StrDispose (P);

end;

A few important things to notice are that you don't have to explicitly include the null character in the assignment, you can use StrAlloc to create a string much bigger than 255 characters and finally you don't have the use the @ symbol when passing a PChar to an API function because the PChar is already defined as a pointer.