• A big thank you to Frank and Michael who made this a very nice event.
• There was a lot of excitement about the new XE2, from the attendees to the speakers to the Delphi team.
• The crowd was not huge, but there was a lot of energy and good vibes.
• Mason Wheeler has a very good report of the Keynote on his blog.
• My thanks to those who attended my sessions. I will clean a bit my material and have it available online… But not before next week.
• Simon Stuart ( of TKinect et al. fame) was not at the conference in San Jose, but I bet he’ll have very interesting sessions at the coming online CodeRage.
• You can help him help the Delphi community here .
• Interestingly, Nick Hodges was there not only as a speaker, but also to recruit for his company Gateway Ticketing.
• And he was in competition with my former company WideOrbit who were there sponsoring the “Meet the Team” event and getting contacts and resumes to fill a lot of jobs openings.

• Delphi XE2 is announced and it surely looks like a very interesting release (and probably with some nasty bugs as well, we’ll see)…
• I take the bet it will up Delphi a bit in the TIOBE index if it creates the buzz I think it will.
• I will speak at the DelphiLive 2011 in San Jose, which I hope will be a good edition with a lot of XE2 goodies….
• Something really cool made with HTML5 (better try it with Chrome).
  You’ll arrive at the top of Lombard street in SF, but when it’s finished you can try with any point having a street view in Google maps.
• Internet is good because it keeps a trace of a lot of code snippets.
  Internet is bad because it keeps a trace of a lot of code snippets.
  My next post should explain…
• We have implemented some panning and zooming features in our Adura System Design application: it’s still cool what you can do with plain old Winapi and Delphi.
  I guess it would be totally sick with FireMonkey (if we do it, but it’s probably a huge rewrite).
• The Silicon Valley Code Camp is back! Saturday and Sunday, October 8th and 9th, 2011. As I said in a previous post, it’s not very Delphi but totally cool.
• Lately I’ve been back into motorcycling (thanks to my lovely and adventurous wife) and I got my first cruiser ever.
  Absolutely gorgeous design but bad UI nevertheless: The control panel is not on the handlebar but on top of the tank with the turn signals indicators at the very bottom, which means you cannot just see them if you have a full face helmet, they are hidden by the chin bar and you have to bow your head and freakin’ look at them.
  And because those turn signals do not go off automatically, I ride quite often with them on for a while and that p..sses me off.
  

As you know, when you want to avoid flickering or multiple partial redraws of your Forms, during a flurry of updates for instance, even though it is very tempting, you must not use LockWindowUpdate. The Windows documentation has been updated from the days when it practically enticed people into using this API call for this wrong purpose and Raymond Chen has explained in detail why:
What does LockWindowUpdate do?
With what operations is LockWindowUpdate meant to be used?
With what operations is LockWindowUpdate not meant to be used?
Final remarks on LockWindowUpdate

Now, just replacing LockWindowUpdate(MyForm.Handle) by SendMessage(MyForm.Handle, WM_SETREDRAW, 0, 0) on the whole Form is not the solution either. Even though I’ve seen it recommended here or there.
Oh, it does a good job at preventing any painting on the Form, and if drawing is re-enabled quickly enough, there is little chance to cause the problem we’ll see below.

Simulate a long calculation that coincides with some visible UI changes.

Create a new VCL Forms application and put 2 Buttons on the Main Form.
In the 1st ButtonClick handler, paste the following code:

procedure TForm1.Button1Click(Sender: TObject);
begin
  Button1.Width := Button1.Width*2;
  Repaint;
  sleep(2000);
  Button1.Width := Button1.Width div 2;
  Repaint;
end;

If you click the button, its size changes, the application stays unresponsive for 2 s (lengthy processing without a background thread) then everything is back to normal. If you click on the Form while it is “frozen” nothing happens unless you have an onClick event, or try to move the Form for instance, and in that case the event action is executed after the Form is unfrozen, when message processing can resume and handle the backlog.

Now, if you don’t want the UI changes to be visible.

You can wrap all that code with WM_SETREDRAW (like you’d be tempted to do with LockWindoUpdate):

procedure TForm1.Button1Click(Sender: TObject);
begin
  SendMessage(Handle, WM_SETREDRAW, Ord(False), 0);
  try
    Button1.Width := Button1.Width*2;
    Repaint;
    sleep(2000);
    Button1.Width := Button1.Width div 2;
    Repaint;
  finally
    SendMessage(Handle, WM_SETREDRAW, Ord(True), 0);
  end;
end;

Try it again. Seems good, the button size does not appear to change. But, wait!
Try to click anywhere on the form while it is “busy”.
Oops! Clicked through it, like it did not even exist!
It’s even more obvious when the form is above the Delphi editor: as soon as you click the button, the cursor changes from the regular Arrow pointer to the text IBeam.

Try with Notepad.

In case you’d believe it is some defect special to the VCL Forms, you can try and paste the following code in the 2nd Button OnClick handler. It opens Notepad for a new text document, prevents redrawing on it for 3s then re-enables it.
Note: If the window title is different (non English Windows…), you may have to adapt the 2nd FindWindow parameter or use an empty string.

procedure TForm1.Button2Click(Sender: TObject);
var
  h: THandle;
begin
  ShellExecute(Handle, nil, 'Notepad.exe', '','', SW_SHOWNORMAL);
  sleep(100);
  // you may have to change the default title in non English Win7 or put ''
  h := FindWindow('Notepad', 'Untitled - Notepad');
  if IsWindow(h) then begin
    SendMessage(h, WM_SETREDRAW, Ord(False), 0);
    try
      sleep(3000);
    finally
      SendMessage(h, WM_SETREDRAW, Ord(True), 0);
    end;
  end;
end;

Try to click anywhere on the Notepad window when it is “locked”, you’ll get right through it just as well!

What if you need to prevent drawing on the Form while doing some processing?

As it is very rare that the UI controls subject to unwanted drawing are directly placed on the Form, the easiest solution is to prevent drawing for the utmost parent, very often a Panel or a Tab/PageControl (the ClientWindow would not work).
And if you don’t have a master parent, you can always insert a Panel with alClient as a main container between the Form and the rest of the controls.
Useful tip: Contrary to DisableControls/EnableControls for the DataSets, WM_SETREDRAW does not care about nested calls, it does not matter how many times you call WM_SETREDRAW False (although avoiding sending unnecessary messages flying around is always desirable). You just have to guarantee that you’ll call WM_SETREDRAW True when you are done with your updates.

Why do we have this strange behavior?

Practically, WM_SETREDRAW default behavior is for the Window receiving it to disappear, but without causing the screen to be refreshed to show what’s behind. We are left with a “ghost” painting of the current Window, and is truly very static indeed.
It has been explained, sort of, by Raymond Chen in a very recent post:
There’s a default implementation for WM_SETREDRAW, but you might be able to do better

I was at work investigating some bizarre behavior of our application when dealing with a big customer file and I had ReportMemoryLeaksOnShutdown turned on as it was very likely there was some memory leaked.
So, I donned my LeakBuster suit, armed my LeakBlaster and started hunting the leaks, trying different workflows with different code-paths, putting some Breakpoints here or there with some Watches, and sure enough, I got a bunch of memory leaks reported upon closing the application. But those were somewhat bizarre, mainly UnicodeStrings with unhelpful stacktraces into the VCL like:
A memory block has been leaked. The size is: 36
This block was allocated ... and the stack trace (return addresses) at the time was:
4043E2 [System.pas][System][@GetMem][2979]
20036
The block is currently used for an object of class: Unknown
or
A memory block has been leaked. The size is: 20
This block was allocated ... and the stack trace (return addresses) at the time was:
404972 [System.pas][System][System.@GetMem][3693]
407B5B [System.pas][System][System.@NewUnicodeString][16751]
407D8C [System.pas][System][System.@UStrFromPWCharLen][17431]
...
407E63 [System.pas][System][System.InternalUStrFromPCharLen][17601]
The block is currently used for an object of class: UnicodeString

It took me some time to find a relatively simple workflow showing consistently a leak where I was pretty sure the code was OK and should not leak. Then I tried to run the application without debugging and it did not leak. And again within the debugger and it leaked again.
So, the debugger was leaking memory. I don’t remember ever seeing that before, except in the cases where calling some buggy code from the Evaluate dialog or in the Watches was causing a leak.

You can try yourself in D2010 or XE with this very simple application: Create New VCL Form Application, double click in the Form designer to create a FormCreate handler and replace the empty procedure by this code:

function Test(s: string): string;
begin
  Result := 'test: ' + s;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  ReportMemoryLeaksOnShutdown := True;
  ShowMessage(Test('toto'));
end;

As you can see, this code cannot possibly leak. Run it and, as expected, it does not leak.
Now put a break point on the ShowMessage line and create a watch to execute Test(‘boo’), checking the “Allow side effects and function calls” in the watch dialog. Run the application, it stops before the ShowMessage and you can see the ‘test: boo’ string value in the watch. Resume the execution, you get the ShowMessage and you can close the Application when the Main Form is shown.

Now, you get the dreaded Memory Leak Report dialog:
—————————
Unexpected Memory Leak
—————————
An unexpected memory leak has occurred.
The unexpected small block leaks are:85 – 92 bytes: UnicodeString x 1
—————————

The funny thing is that if you save this project “as is” and close Delphi, next time you restart Delphi and run it, it might not necessary leak even though you see the watch expression evaluated; you’d have to run it again or even open the watch dialog explictly and then boom! you’ll get the leak….
Anyway, as using “Evaluate” or “Watch” are common use cases when debugging, it’s very easy to find yourself with some strange memory leaks.

I have experienced this with D2010 and XE, with or without the full FastMM4. I don’t recall having this with D2007 or previous versions.

Do you Delphites out there see that behavior?
(not yet logged in QC, but it looks very similar to QC# 73762, so maybe that one just needs more visibility and more votes, and this new Use Case).

So, this post will be more like a pot-pourri of little tidbits a la Nick Hodges.

• It’s kind of irritating when in Delphi’s editor the parenthesis matching goofs and counts those embedded in strings:

Format('I have %d closing )', [n])

• You don’t appreciate the comfort of doing software in a software realm, with pretty stable APIs, some sort of object model and a stuff called specifications, until you begin to deal with hardware devices that can make darwinism look like immobilism.
• Delphi is back in the top 10 of the TIOBE Index this month. I guess it is a good sign. Don’t know if one can read too much in it…
• Certainly, there is more to do to bump Delphi’s name recognition. My son is back home for the holidays from his college. He started this year in Software Engineering at a well known university. He has yet to hear about Delphi (except by myself at home).
• It’s certainly time to wish you all very happy holidays. Enjoy time with you family and take care!

FYI, the old CodeRage 4 session (in English) is also available from Embarcadero: “Speech Enabling Delphi Applications (zip)”

  while not ADataSet.Eof do
  begin
    [...]
    ADataSet.FieldByName('MyFieldName1').SomePropertyOrMethod;
    ADataSet.FieldByName('MyFieldName2').SomePropertyOrMethod;
    [...]
    ADataSet.Next;
  end;

Using FieldByName in a case like this is certainly very convenient and has a lot of advantages:

• Clarity and readability. The intent of the code is obvious and there is no question about which Data point you work with.
• Proximity. You create your Field reference exactly where you need it.
• Flexibility. You’re not stuck with design-time Fields, your DataSet can represent multiple queries, you just need to know that you have a ‘MyFieldName’ column in this context.
• Security. FieldByName never returns nil because it raises an exception if the Field does no exist. So, you’re sure not to get an AV when directly using a property or method.

But is has a major problem:

• It is searching -again- for the same already found Field at each and every record of the DataSet. Like this code has Alzheimer.
• Knowing that each call to FieldByName is mainly a call to FindField, that can introduce up to 3 new sub-loops within your main loop. With our 2-Field example above, that’s 6 sub-loops that can be added for every row.

It does not seem that bad if it is just an example or some demo code, but as soon as it is published, someone will grab a snippet and a few copy’n'haste later it ends up in production code.

And indeed, I can tell you that this (untold) company’s production code actually contained dozens of cases like the following (anonymized but real) code:

  aQuery.ParamByName('Zone_mask').DataType := ftLargeint;
  aQuery.ParamByName('Zone_mask').Value    := aZoneMask;
  aQuery.ParamByName('Start_date').AsDateTime := fStartDate;
  aQuery.ParamByName('End_date').AsDateTime   := fEndDate;

  aQuery.Open;
  while not aQuery.EOF do
  begin
    effectiveDeviceInfo :=
      TEffectiveDeviceInfo.Create(
         aQuery.FieldByName('Device_code_name').Value,
         aQuery.FieldByName('Device_descr').Value,
         aQuery.FieldByName('Toggle_times').Value,
         aQuery.FieldByName('Comments').Value,
         aQuery.FieldByName('Effective_start_date').Value,
         aQuery.FieldByName('Effective_end_date').Value);

    fChannelDevice.AddObject(
      self.MakeSortKey(
        aQuery.FieldByName('Device_code_id').Value,
        aQuery.FieldByName('Channel_int').Value),
      effectiveDeviceInfo);

    aQuery.Next;
  end;
  aQuery.Close;

That’s between 8 and 24 added loops for each record in this dataset which could have tens of thousands of records!
Granted, that would be small loops if the number of fields is reasonable, but still…

So, I cringe when I see someone posting on StackOverflow a code snippet that looks good (verify Active, DisableControls, try..finally) but has the FieldByName inside the loop:

begin
  Assert(AdoQuery1.Active, 'Dataset is not active!');
  try
    AdoQuery1.DisableControls;
    AdoQuery1.First;
    while not AdoQuery1.Eof do
    begin
      AdoQuery1.Edit;
      AdoQuery1.FieldByName('MyFieldName').Value := Edit1.Text;
      AdoQuery1.Post;
      AdoQuery1.Next;
    end;
  finally
    AdoQuery1.EnableControls;
  end;
end;

And kudos to the poster who changed it after just a little nudge to create a local Field variable before the loop. It adds 2 more lines per Field, but the code is much better:

var
  AField : TField;  // <= line added
begin
  Assert(AdoQuery1.Active, 'Dataset is not active!');
  try
    AdoQuery1.DisableControls;
    AField := AdoQuery1.FieldByName('MyFieldName'); // <= line added
    AdoQuery1.First;
    while not AdoQuery1.Eof do
    begin
      AdoQuery1.Edit;
      AField.Value := Edit1.Text;
      AdoQuery1.Post;
      AdoQuery1.Next;
    end;
  finally
    AdoQuery1.EnableControls;
  end;
end;

Now, don’t go “premature optimization” on me, as the cases where the number of records is too small to benefit from ousting the FieldByName from the DataSet loop are pretty rare.

I would be curious to know what you get if you do a grep in your code base to find FieldByName or FindField in loops…
Do you have any?

As promised, I have uploaded the material used for the session:

- powerpoint (FR): fgaillard.com/download/Speech_FR.ppt

- source code (EN/FR): fgaillard.com/download/Speech_FR_Src.zip

Note: the source code does not include the Speech Type Library (needed for Dictation project), you’ll have to import it directly in your Delphi.

Disclaimer: Be warned, the source code is bad and useless… It might not even have any educational purpose… Yadda yadda yadda try at your own risk yadda yadda yadda no warranty… et cetera!

Let me know if there are any problems…

The agenda for CodeWay 4 has it at 17:00 Paris time. That’s 8am here in San Francisco and 11am in Quebec and on the East Coast.

Here’s the menu:

•Vue d’ensemble
•Synthese
•Dictee
•Contrôle
•RichEdit 4.1
•Delphi Prism

Well, it happened that when I wanted to do the Delphi Prism demo, with the .Net API, it was nowhere to be found on my machine. I tried to install and re-install multiple times the runtime and the SDK: Microsoft.Speech.dll refused to be installed.

Fortunately, I found the newer 10.2 version, and this one did install correctly and I could record my .Net demo.

Unfortunately, the stupid bug where SpeechSynth is not able to send the audio stream to the standard audio output is still there!

Microsoft Speech Platform Server Runtime v10.2: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=bb0f72cb-b86b-46d1-bf06-665895a313c7&displaylang=en.

Microsoft Speech Platform SDK v10.2: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1b1604d3-4f66-4241-9a21-90a294a5c9a4.

Microsoft Speech Platform languages v10.2: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=47ffd4e5-e682-4228-8058-dd895252a3c3&displaylang=en.