Introduction

This article is for Delphi developers who want to learn Prism. It covers the most significant changes to the old Delphi language
and the basics about the new parallel computing support.

Delphi Prism is a .NET language based upon Delphi. You might say it is the Delphi.NET. The name also stands for a Visual Studio extension
that makes coding in Prism comfortable. It is a Visual Studio Shell application, so it integrates into an existing VS 2008 (if it is installed
on the machine) or runs as a standalone IDE.

Why should you use Prism at all? First, there are Linux and Macintosh. Maybe you want to write platform independent code for Mono.
Second, desktop applications are not always adequate and Delphi's ISAPI support is not state of the art. Third, you might be switching
from native to managed development in general. Learning to use a new platform will be easier with a language you already know.

There's a fourth possible reason: Your applications are designed for multicore computers.
Delphi Prism is designed especially for heavy multithreading and high responsiveness.

In this absolute beginner's tutorial, we'll write an address book using the Lucene.NET library.
To introduce desktop and web at the same time, there'll be a WPF application to fill the search index and a web page to search it.

Index Builder: Your First WPF Project

Create a new Delphi WPF project. Visual Studio shows you the Forms Designer, where you can design the main dialog as usual.
Change to the code editor. Delphi developers will be surprised: instead of a unit the code generator has declared a namespace.
In the class definition, you find the new keywords partial and method. The latter replaces procedure
as well as function, because .NET doesn't make a difference between those two. (Rather every method has a return value,
for procedures it is void.) The name Create for constructors is replaced by nothing at all: objects get created
with new, just as in the C-like languages.

Let's begin with the address book. A list of names has to be filtered and added to the search index. The new way to search lists
looks quite confusing: the common Delphi developer is used to declare all variables above the procedure! But thanks to LINQ,
there are lists without a defined type (that means, not defined in code), which don't even have to be declared.

Index Searcher: Your First Web Project

The newly built search index is to be searched by a web form. Create a new Delphi ASP.NET project!
Again, Visual Studio shows you a designer window. Open the code behind to meet another new keyword.
partial splits the Delphi class into an editable file Default.aspx.pas and the designer generated file
Default.aspx.designer.pas. While you're typing ASP code, the designer fill its file with all necessary declarations.
Your file will rarely be touched by the designer, unless the generated code must be edited by you. Now, double-click a button
on the web form to insert an event handler.

By the way, this is a good point to introduce the double compare operator. You can make your code more readable using
"0.2 <= score < 0.5" instead of the long version "0.2 <= score and score < 0.5".

More CPUs, Please!

Performance has always been an argument for using Delphi. Prism focuses on parallel programming and scores with handy new keywords which save lots of code and chaos.

The most handy one is async which simply declares a method as asynchronous. An asynchronous method is executed
in a separate thread - automatically! That way a single word in the declaration line can prevent the main thread from being slowed
down by log output calls. In the declaration of a variable, async is the promise that the variable will - in the future - contain a certain value.
The value itself is calculated in a separate thread. If another thread accesses the variable before the calculation is finished, that thread is blocked until
the value is available. But the most impressive news is the asynchronous block:

When is line 04 executed? Assuming there are enough processors, simultaneously with line 07.
async makes the block run in another thread. The future variable myBlock is your handle for that thread,
so you can wait for it in line 08. The method call myBlock() doesn't execute the block! Only if it hasn't yet finished, it waits for the thread to end.

Inside the asynchronous blocks, you may call other asynchronous methods. But be careful: the main thread doesn't wait for them.
Waiting for an asynchronous block means waiting for this one thread, not for any "nested" threads that have been started by the block.

To visualise all that parallel stuff, the web page contains four checkboxes. They'll be evaluated in the background, when the user already sees the response page in his browser.

The StreamWriter seems to be initialised with an empty path. But the keyword future causes the assignment
in the declaration line to be executed shortly before the first access to the object. At that time, the path already is assigned.
The method WriteLog is async, so it always runs in the background.

In the async block's thread, a for each matching loop iterates through all controls that are checkboxes.
Every iteration can call another asynchronous method. When in the end the main thread waits for the block to finish, it waits only
for the block's thread, not for any additional thread started by the block. The WriteLog calls can still run in the background,
maybe waiting for a free CPU, when the user already sees the complete response.

The Source

To compile the demo applications, you need the assembly Lucene.Net.dll.
If the latest stable release doesn't work, try version 2.0.004.

A 30 days trial version of Delphi Prism can be downloaded from Embarcadero.
Sadly, they don't offer a free Express version.

I've noticed that when running async methods in Delphi Prism they are dispatched immediately but there appears to be significant latency in actually loading/executing the async method.

I'd very much like to your thoughts and/or explanation on what's happening or how to improve that.

I've included a demo (console app) below that shows how async mehtods are immediately "dispatched" but are NOT immediately executed.....

I at first thought the app was being throttled due to thread availability but as the demo shows the threads are all eventually allocated to execute the async method it just takes a long time for the methods to load.

Hello Delphier! Delphi is very rare on CodeProject, but that doesn't mean we should go somewhere else ... no, it means we need more Delphi articles!By the way, I don't call myself "Delphier" but "Delphin". That's the German word for "dolphin". Cute coincidence, is it?

In China we call ourself 'Delphier'.Haha,'Delphin' sounds good,I like.Now I use Delphi 2007 for win32 ,Write Components for UI;what about u?sorry,my En.. is poor..I'll take more practice here,so sometimes I need ur helps,3q.

Thanks for your reply. I'll let you know when I'll have something to post on CodeProject. I don't have too much free time, but I've started a framework recently and when I'll have something cool to show I'll do it. All the best!