After installing D2009 on a clean Win7 machine I was happy to see that Windows 7 really is what Vista should have been. It works snappy and has a lot of productivity features. But then when I started compiling and debugging a couple of my existing Delphi applications I experienced Debugger crashes almost everytime when I terminated an application.

Unfortunately no matter if you press “Yes” or “No” on that screen – you have to restart the whole Delphi IDE – which basically makes debugging impossible. In some (actually many) cases you even have to terminate Delphi using Windows TaskManager. I tried all of the compatibility settings Win7 offers, as well as running Delphi as Administrator – but no luck.

Some research on Google, QC and RAID showed that similar exceptions were reported with older Delphi versions, but apparently only on 64bit Windows editions. As the message already suggests, the problem appears to be an invalid call to a SetThreadContext API call. Some tests showed that you can easily reproduce this issue once you have more that just a single thread in your Delphi application. As you might know, I am doing quite a lot of Web application server development – which by nature create many threads…

I created a RAID entry for that (actually an existing one was updated with detailed reproduction steps – iirc) and joined a discussion thread on that topic to see if others are reporting that too. Because of time constraints I did not revisit that issue over the last couple of weeks, but yesterday when I was talking to Daniel Magin, we together found a solution someone had posted on a German Forum a few weeks ago. The original idea is from an MS TechNet posting though (credits go to a guy called Xelax Ax).

He posted a workaround that basically disables the check for a possible error returned by SetThreadContext, i.e. the debugger ignores the error and does not crash because of the Assert that checks fro no error returned. As Andreas Hausladen already correctly mentioned, this is really just kind of a weak workaround, because the debugger might misbehave after that and we just do not know why SetThreadContext fails at all. The point is though that with this fix I can work effectively again with D2009 on Win7/64bit and as this error only happens when the debugger is about to shout down anyway, so the danger of unwanted side effects is not too high imho.

Be careful! No waranties! I am not responsible for lost files etc.! Back up first!

Workaround steps:

1. Close Delphi
2. Locate bordbk120N.dll (C:\Program Files (x86)\CodeGear\RAD Studio\6.0\bin)
3. Make a backup copy
4. Check step 3
5. Open bordbk120N.dll in a Hex editor (UltraEdit works fine)
6. Search for “01 00 48 74 47 80 3D”
7. Make sure this is found once only
8. Replace “74” with  “EB”
9. Save
10. Restart Delphi. Error should be gone.

This might work on older Delphi versions as well, but I did not test that yet.

Update 1

I talked to some CodeGear Q&A guy and he tested their current internal Weaver build under the conditions where D2009 fails. The good news is that the error seems to be gone there – so the next Delphi Version will probably be good. For those who want to get started now: please see Update 2 below.

Update 2

LordByte sent me his automatic patch tool for Delphi 2007 and Delphi 2009. Just click “Apply patch” and you are done.

Get the patcher here: Delphi_2007_2009_WOW64_Debugger_Fix.zip (169 KB)

Note: Provided as is for free. Use at your own risk.

As far as I understand this technology, you would even be able to keep your Delphi (or any other Embarcadero product) on a USB-stick, and run it on any computer you like.  Just plug in the stick and run the exe. Very cool!

I’m excited to get a first demo of this in my hands!

Here is the online-version of the (German) newsletter announcing this technology.

Update: The AllAccess information page also contains the note about “InstantOn. In fact it was already mentioned in the earlier press release of AllAccess – but apprently it didn’t get much attention.

Quote: “On-Demand Power with Embarcadero InstantOn™

A unique, innovative capability in All-Access is Embarcadero InstantOn. With InstantOn, you can simply click-and-run the selected tool on-demand, either locally or over your network, without full installation on your local machine. InstantOn saves valuable time by allowing quick access to tools, even in locked-down desktop environments where installing software is problematic.”

The conference is organized by S&S Media and supported by Embarcadero/CodeGear.

We have got all the top speakers, including Cary Jensson, Marco Cantu and Ray Konopka.

Many (most?) members of Delphi R&D team (including Barry Kelly – “The Delphi Compiler”) will be at the conference and there will be of course "Meet the Team" sessions.

All Sessions are online and registration is now open. The speakers list includes all those who already submitted their bio and photo. For a complete list of speakers please refer to the list of sessions for now.

If you register before April 10th, 2009, then you can take advantage of the Early Bird rebates.

When : May 13 – 16, 2009
Where: San Jose, CA, USA

More information: www.delphilive.com

S&S Media is a book/magazine publisher and software conference organizer. S&S is well known in the Delphi community for their Delphi focused "EKON" conferences and "Entwickler" magazines.

For comments, questions or concerns you may use the contact form on the DelphiLive web site, or just leave a comment here.

As an Advisory Board member I am proud to post this official pre-announcement for the next, long awaited physical Delphi conference.

Where: San Jose, CA, USA
When: May 13th – 16th 2009
Who: All Delphi developers, let it be Delphi Win 32, Delphi Prism or Delphi for PHP ones.

We will try to get all the known top speakers, from the US and Overseas to make this event absolutely rocking. The conference will be organized by Software & Support Verlag, supported by CodeGear / Embarcadero. San Jose was chosen as location as it is close to CodeGear’s HQ, so that CodeGear staff can show up easily.

Attendees

For now, block this event in your calendar if you are interested. We will keep the price affordable – details will be posted asap.

To register, please go to the DelphiLive 2009 Website – which will go online in the next two weeks. We will send announcement emails through CodeGear’s Developer Network as soon as registration is open. Make sure you are signed up at CodeGear Developer Network and CDN emails are not blocked by your spam filters.

Speakers

If you want to present sessions at Delphi Live 2009, then please stay tuned for the official Call For Papers, which will be made public in the next 2 days or so.

Topics

We will cover from basics to advanced topics all around Delphi. The final topic list will be made available as soon as the call for papers is closed.

Following is a draft of tracks:

• Architecture / Design
• OOP
• Database
• IDE, Tools & Components
• Core Development
• Basics / Fundamentals
• Native Delphi
• Delphi Prism
• Delphi & .NET
• Delphi & Web
• Delphi & PHP
• Delphi & Ruby on Rails

If you have suggestions for specific topics you would like to be covered (and which you do not want to present yourself), then feel free to post these suggestions as comments to this blog. The same goes for speakers which you would definitely like to see in San Jose.

To make it clear: it’s not just Delphi users reporting issues with these Logitech drivers, some other applications seem to affected as well. Google for lvprcinj.dll – I find the word “injection” in that dll pretty scary btw.

Apparently even with the latest Logitech drivers (11.1.0.2030 at the time of writing this), this error is still there (or maybe there again) and affects Delphi 2009 too.

So if you experience this odd AV as demonstrated on Nick’s blog, then you have terminate lvprcsrv.exe at least.

TEmployee = class(TPerson)
private
FHoursPerWeek: Double;
FWeeklyRate: Double;
FHourlyRate: Double;
procedure SetHourlyRate(const Value: Double);
procedure SetHoursPerWeek(const Value: Double);
function GetWeeklyRate: Double;
public
property HourlyRate: Double read FHourlyRate write SetHourlyRate;
property HoursPerWeek: Double read FHoursPerWeek write SetHoursPerWeek;
property WeeklyRate: Double read GetWeeklyRate;
end;

...

{ TEmployee }

function TEmployee.GetWeeklyRate: Double;
begin
Result := HourlyRate * HoursPerWeek;
end;

procedure TEmployee.SetHourlyRate(const Value: Double);
begin
FHourlyRate := Value;
end;

procedure TEmployee.SetHoursPerWeek(const Value: Double);
begin
FHoursPerWeek := Value;
end;

In the example above “HourlyRate” is what an employee get’s paid per hour. This value can be read and set. “WeeklyRate” is a read/only calculated value, which depends on “HourlyRate” and “HoursPerWeek”.

This all looks fine and we know how to deal with that since years. And it works the same way in Delphi Prism.

But sometimes, when you design a new class, do you always follow the “property-hides-field” pattern? Even if Delphi makes life easy with “Ctrl-Shift-C”, the code may look pretty much bloated, esp. if you have standard properties, not doing anything special. So you might just use “simple” Fields where possible. This is bad design of course, as if you need to change to a “real” property later, because you need to calculate something in a get or set method, you would have to change your classes signature, which may break compatibility …

Delphi Prism introduces two new language features to Pascal, which may prevent code from bloating and actually helps readability.

Implicit Fields

Implicit fields are fields which are created by the compiler automatically for properties which do not have any read or write accessors.

This is how the example would look like using implicit fields:

TEmployee = class(TPerson)
private
FWeeklyRate: Double;
function GetWeeklyRate: Double;
public
property HourlyRate: Double;
property HoursPerWeek: Double;
property WeeklyRate: Double read GetWeeklyRate;
end;
implementation

{ TEmployee }
function TEmployee.GetWeeklyRate: Double;
begin
Result := HourlyRate * HoursPerWeek;
end;

So this already look much less bloated. Implicit fields are not an invention of Delphi Prism though, but they were introduced with C# 3.0 Implicit Fields exist in Prism since 2004. They were introduced to C# 3.0 just a moment later, in 2008 , and they are called Auto-Implemented Properties here. The beauty of Pascal gets apparent though, once you compare Prism’s syntax with its C# equivalent:

class TEmployee
{
public Double HourlyRate {get; set;}
public Double HoursPerWeek {get; set;}

...
}

In Pascal there is no need to write these “stub” get and set calls.

Technically, it’s important to notice that Prism automatically creates a “get” and “set” method, plus a hidden private field for these properties. These hidden fields cannot be accessed in the classes code,  just use the Property itself everywhere. If you are not convinced that there are really hidden fields, then lets have a look at the IL code behind that (extracted using Red Gate’s Reflector):

.method public hidebysig specialname instance void set_HoursPerWeek(float64 'value') cil managed
{
.maxstack 3
L_0000: ldarg.0
L_0001: ldarg.1
L_0002: stfld float64 WindowsApplication5.TEmployee::@p_HoursPerWeek
L_0007: ret
}

The field gets obviously hidden by using “@” in it’s name which is not valid for Pascal, thus cannot be accessed. In C#, they are using brackets in the hidden private field name for the same purpose:

<HoursPerWeek>k__BackingField

Inline Expressions

With inline expressions you can make the code look even nicer. And best of all, to my knowledge there is no C# equivalent

Inline expressions may be used directly after the “read” keyword. This may drastically improve the readability of your code. Compare the final code example with the one at the very top!

TEmployee = class(TPerson)
public
property HourlyRate: Double;
property HoursPerWeek: Double;
property WeeklyRate: Double read HourlyRate * HoursPerWeek;
end;

Yes, this the complete TEmployee definition. No further implementation needed. Just 6 Lines, compared to the initial roughly 25 ones!

The Delphi Prism Wiki has an entry about “Class Properties”, which explains a few more details. (The “Implicit Fields” feature is a bit “hidden” though)

This is a “Customer” class definition with a manual mapping to a “Customers” table on a SQL Server 2005:

type
[Table(Name := 'Customers')]
Customer = class(Object)
private
protected
public
[Column(IsPrimaryKey := true)]
property CustNo:Double;
[Column]
property Name: String;
[Column]
property Country: String;
end;

This is the actual LINQ to SQL code that relies on the class definition above:

method MainForm.button2_Click(sender: System.Object; e: System.EventArgs);
var
LCustomers: Table<Customer>;
LDBMain: DataContext;
LConnectionString:String;
begin
LConnectionString := 'Data Source=.\SQLEXPRESS;Initial Catalog=DBDEMOS;Integrated Security=True';
LDBMain := new DataContext(LConnectionString);
LCustomers := LDBMain.GetTable<Customer>();
var USCustomers := from Customer in LCustomers where Customer.Country = 'US' select Customer;

for each Customer in USCustomers do begin
listBox1.Items.Add(Customer.Name);
end;
end;

Interesting to note is that Prism has a very nice name scope mechanism. Even though “Customer” is a Class name, it is also used as local variable in the LINQ and FOR constructs. I am not saying that this is a good practice though

Technically, both “Customer” variables are different variables – which is quite important to understand.

The full demo source can be downloaded here: [download#2].

The good news is, RemObjects implemented all required compiler support! Excellent!

See the simple example below:

method MainForm.button1_Click(sender: System.Object; e: System.EventArgs);
var
lCustomer: Customer;
lCustomers : List<Customer>;
begin
lCustomers := new List<Customer>;

lCustomer := new Customer;
lCustomer.Name := 'Olaf';
lCustomer.Country := 'Germany';
lCustomers.Add(lCustomer);

lCustomer := new Customer();
lCustomer.Name := 'Jim';
lCustomer.Country := 'USA';
lCustomers.Add(lCustomer);

//Inline declaration using type inference
var GermanCustomers :=
from Customer in LCustomers
where Customer.Country.Equals('Germany');

//Has nothing to do with LINQ, but that's type inference too:
for Customer in GermanCustomers do begin
listBox1.Items.Add(Customer.Name);
end;
end;

Interesting to notice is how the variables “GermanCustomers” and “Customers” are declared. They are both declared inline using type inference – which is one of the important enhancements over Delphi Win32.

See the Prism Wiki for details on LINQ.

DevExpress is a component set and productivity plugin vendor who serves the VCL and .NET market. DXCore is a base library which is heavily used by their CodeRush and Refactor products.

To finally enable Sync Editing after installing DXCore you need to copy one file manually. Just follow the steps in this  Prism Wiki article.

Delphi Prism

Delphi  Prism is basically a plugin for Visual Studio, which delivers the Pascal Language plus some exciting extra features to Microsoft’s .NET development platform.

Get a trial version from CodeGear’s Code Central. Delphi Prism is part of RAD Studio 2009,  the ISO (1.4 GB!) offered for download on that page contains Prism only though.

Prism has to be activated by a license key. You can request a 14 day trial license on the same page and/or use a purchased RAD Studio 2009 license key. In other words the ISO contains the full product.

The Prism product page does not yet have a “purchase” link, but the marketing department is currently working on getting an announcement e-mail blown out. I guess that the purchase link will be activated while that happens. As the ISO contains the full product, you can switch from trial to full after the 14 days, just by entering a new license key.

Technical Information

Prism is not an upgrade of what you may know as Delphi.NET from RAD Studio 2007 or earlier. Prism is a complete new tool. It has been developed by a partner of CodeGear’s, RemObjects and comes as the solution for .NET and Mono in RAD Studio 2009. It completely “integrates” with the .NET framework. It does not bring any “Delphi Win32” dependencies. This means all executables/assemblies you will create with Prism will be “pure” .NET (or Mono) ones. No more P/invoke weirdness.

Porting Delphi Applications

The good news are: Prism Pascal is very compatible to Delphi Native Pascal. There are a couple of differences, which are well documented.

The bad news are: There is no VCL on Delphi Prism. In other words you can port business code more or less easily, but you have to re-implement your GUI code. After all I don’t think that’s  too bad though. You have all .NET possibilities instead. System.Windows.Forms, WPF, Silverlight …

If you want to dig into the technical details, then have a look at the Delphi Prism Wiki. As Delphi user you might want to start with Delphi Prism syntax compared with Delphi Win32 syntax.

More information to come (including German Prism Workshop in Darmstadt) …