Book Image

Delphi Cookbook - Second Edition

By : Daniele Teti
Book Image

Delphi Cookbook - Second Edition

By: Daniele Teti

Overview of this book

Delphi is a cross-platform Integrated Development Environment (IDE) that supports rapid application development for Microsoft Windows, Apple Mac OS X, Google Android, and Apple iOS. It helps you to concentrate on the real business and save yourself the pain of wandering amid GUI widget details, or having to tackle inter-platform incompatibilities. It also has a wide range of drag-and-drop controls, helping you code your business logic into your business model, and it compiles natively for desktop and mobile platforms. This book will teach you how to design and develop applications, deploy them on the cloud platform, and distribute them within an organization via Google Play and other similar platforms. You will begin with the basics of Delphi and get acquainted with JSON format strings, XSLT transformations, unicode encodings and various types of streams. We then move on to more advanced topics such as developing higher-order functions and using enumerators and RTTI. You will get an understanding of how Delphi RTL functions and how to use FireMonkey in a VCL application. We will then cover topics such as multithreading, using the parallel programming library and putting Delphi on a server. We will also take a look at the new feature of WebBroker Apache modules and then ride the mobile revolution with FireMonkey. By the end of the book, you will be able to develop and deploy cross-platform applications using Delphi .
Table of Contents (10 chapters)
9
Index

Creating a Windows service

Some kinds of application needs to be running 24/7. Usually, they are network servers or data transfer/monitoring applications. In these cases, you probably start with a normal GUI or console application. However, when the systems start to be used in production, you are faced with a lot of problems related to Windows session termination, reboots, user rights, and other issues related to the server environment.

Getting ready

The way to go, in the previous scenario, is to develop a Windows service. In this recipe, we'll see how to write a good Windows service scaffold, and this can be the skeleton for many other services. So, feel free to use this code as a "template" to create all the services that you will need.

How it works…

The project has been created starting from the default project template accessible by going to File | New | Other | Delphi Projects | Service Application and then has been integrated with a set of functionalities to make it "real."

All the low-level interfacing with the Windows Service Manager is done by the TService class. In ServiceU.pas, there is the actual descendant of TService that represents the Windows service we are implementing. Its event handlers are used to communicate with the operating system.

Usually, a service needs to respond to the Windows Service Controller commands independently of what it is doing. So, we need a background thread to do the actual work, while the TService.OnExecute event should not do any real work (this is not a must, but usually is the way to go). The unit named WorkerThreadU.pas contains the thread and the main service needed to hold a reference to the instance of this thread.

The background thread starts when the service is started (the OnStart event) and stops when the service is stopped (the OnStop event). The OnExecute event waits and handles ServiceController commands but doesn't do any actual functional work. This is done using ServiceThread.ProcessRequests(false); in a while loop.

Usually the OnExecute event handler is like this:

procedure TSampleService.ServiceExecute(Sender: TService);
begin
  while not Terminated do
  begin
    ServiceThread.ProcessRequests(false);
    TThread.Sleep(1000); 
  end;
end;

The wait of 1000 milliseconds is not a must, but consider that the wait time should be not too high because the service needs to be responsive to the Windows Service Controller messages. It should not be too low because otherwise the thread context switch may waste resources.

The background thread writes a line in a logfile once a second. While it is in a Paused state, the service stops writing. When the service continues, the thread will restart writing the log line. In the service event handlers, there is the logic to implement this change of state:

procedure TSampleService.ServiceContinue(Sender: TService; var Continued: Boolean);
begin
FWorkerThread.Continue;
Continued := True;
end;

procedure TSampleService.ServicePause(Sender: TService; var Paused: Boolean);
begin
FWorkerThread.Pause;
Paused := True;
end;

In the thread, there is the actual logic to implement the Paused state, and in this case, it is fairly simple: we've to pause the writing of the logfile:

Here's an extract:

    Log := TStreamWriter.Create(
      TFileStream.Create(LogFileName, fmCreate or fmShareDenyWrite));
    try
      while not Terminated do
      begin
        if not FPaused then
        begin
          Log.WriteLine('Message from thread: ' + TimeToStr(now));
        end;
        TThread.Sleep(1000);
      end;
    finally
      Log.Free;
    end;

The Boolean instance variable FPaused can be considered thread safe for this use.

Delphi services don't have a default description under the Windows Service Manager. If we want to give a description, we have to write a specific key in the Windows registry. Usually, this is done in the AfterInstall event. In our service, this is the code to write in the AfterInstall event handler:

procedure TSampleService.ServiceAfterInstall(
Sender: TService);
var
Reg: TRegistry; //declared in System.Win.Registry;
begin
Reg := TRegistry.Create(KEY_READ or KEY_WRITE);
try
  Reg.RootKey := HKEY_LOCAL_MACHINE;
  if Reg.OpenKey(
    '\SYSTEM\CurrentControlSet\Services\' + name, 
    False {do not create if not exists}) then
  begin
    Reg.WriteString('Description', 
      'My Fantastic Windows Service');
    Reg.CloseKey;
  end;
finally
  Reg.Free;
end;
end;

It is not necessary to delete this key in the AfterUnInstall event because Windows deletes all the keys related to the service (under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<MyServiceName>) when it is actually uninstalled.

Let's try an installation. Build the project, open the Windows command prompt, and go to the folder where the project has been built. Then, run this command:

C:\<ExeProjectPath>\WindowsService.exe /install

If everything is ok, you should see this message:

How it works…

Figure 11.1: The service installation is ok

Now, you can check under the Windows Services Console and you should find the service installed. Click on Start, wait for the confirmation, and the service should start to write its logfile.

Play with Pause and Continue and check the file activity.

Note

Some text editors could have a problem with opening the logfile while the service is writing. I suggest that you use a Unix tail clone for Windows.

There are many free choices. Here are some links:

http://sourceforge.net/projects/tailforwin32/

http://ophilipp.free.fr/op_tail.htm

http://www.baremetalsoft.com/baretail/

There's more…

Windows Services are very powerful. Using the abstractions that Delphi provides, you can also create an application that, reading a parameter on the command line, can act as a normal GUI application or as a Windows Service.

In the respective recipe folder, there is another recipe called 20_WindowsServiceOrGUI.

This application can be used as a normal Windows Service using the normal command line switches used so far, but if launched with /GUI, it acts as a GUI application and can use the same application code (not TService). In our example, the GUI version uses the same worker thread as the service version. This can be very useful also for debugging purposes.

Run the application with the following command:

C:\<ExeProjectPath>\WindowsServiceOrGUI.exe /GUI

You will get a GUI version of the service, as shown here:

There's more…

Figure 11.2: The GUI version of the Windows Service

Using the TService.LogMessage method

If something happens during the execution of the service that you want to log and you want to log in to the system logger, you can use the LogMessage method to save a message. The message can be viewed later using the Windows built-in event viewer.

You can call the LogMessage method using an appropriate logging type like this:

LogMessage('Your message goes here for SUCCESS', EVENTLOG_SUCCESS, 0, 1);

If you check the event in the Event Viewer, you will find a lot of garbage text that complains about the lack of "description for the event."

If you really want to use the Event Viewer to view your log message (when I can, I use a logfile and don't care about the Event Viewer, but there are scenarios where the Event Viewer log is needed), you have to use the Microsoft © Message Compiler.

The Microsoft © Message Compiler is a tool able to compile a file of messages into a set of RC files. Then, these files must be compiled by a resource compiler and linked into your executable.

More information on Microsoft © Message Compiler and the steps needed to provide the description for the log event can be found at http://www.codeproject.com/Articles/4166/Using-MC-exe-message-resources-and-the-NT-event-lo.