Delphi, Javascript and Floating Point Parameters

I recently came across an interesting little problem when using Delphi to call JavaScript in an HTML document loaded into a TWebBrowser control.

The code used the execScript method of the IHTMLWindow interface, which requires that a string containing the JavaScript function call is passed as one of its parameters.

So you have to assemble a string containing the function call and its parameters, something like this:

var
  JSFn: string;
  StrParam: string;
  IntParam: Integer;
  FloatParam: Double;
begin
  StrParam := 'Say \"Hello\"';  // double quotes must be escaped
  IntParam := 42;
  FloatParam := 1234.56789;
  JSFn := Format('Foo(%d, "%s", %.8f);', [IntParam, StrParam, FloatParam]);
  ExecJS(JSFn);
end;

I'll show ExecJS later. It's just a wrapper that ultimately calls IHTMLWindow.execScript with the required JavaScript.

The interesting bit is what happens to the floating point parameter. Delphi consults the current locale when formatting floats, so the decimal separator used in the resulting string depends of the locale. For example, on my UK English system JSFn has value:

Foo(42, "Say \"Hello\"", 1234.56789000);

whereas when I switch to a German locale the value changes to:

Foo(42, "Say \"Hello\"", 1234,56789000);

Now when the function call is passed to the JavaScript engine it has to interpret the string as valid JavaScript. What surprised me at first was the fact that, on the German locale, the float parameter was truncated to an integer value whilst on the UK locale it parsed correctly.

Once I thought about it more it became clear why. When the string containing the function call is passed to the JavaScript engine it has to be parsed. The string must contain valid JavaScript source code. And the JavaScript spec says that decimal numbers use '.' as the decimal separator, which means that any ',' separator is not valid. In fact ',' is the parameter separator so a parameter of '123,4567' is interpreted as two integer parameters: 123 and 4567.

Assume you have an HTML document that contains the following JavaScript in its <head> section:

<script type="text/JavaScript">
  function showNum(n1, n2) {
    alert(
      'n1 = ' + n1 + '\n\n' + 'n2 = ' + n2
    );
  }
</script>

You also have a Delphi program that loads the HTML document into a TWebBrowser control and has the following code attached to a button click:

ExecJS(
  Format('showNum(%.8f, %.8f)', [123.456, -42.56])
);

Running the Delphi program with a UK English locale will work as expected and you see the JavaScript alert box displaying this text:

n1 = 123.456
n2 = -42.56

which is what you expect. Switch to a German locale and run again and you'll get:

n1 = 123
n2 = 45600000

Luckily the fix is simple. We simply get information about the current decimal separator and change it to a '.'.

Here's my first attempt:

function JSFloat(const F: Double): string;
begin
  Result := FloatToStr(F);
  if DecimalSeparator <> '.' then
    Result := StringReplace(Result, DecimalSeparator, '.', [rfReplaceAll]);
end;

This uses the DecimalSeparator global variable that Delphi sets correctly for the current locale when the program starts.

When we change the code that calls the JavaScript function to the following, everything works no matter what the locale.

ExecJS(
  Format('showNum(%s, %s)', [JSFloat(123.456), JSFloat(-42.56)])
);

Using DecimalSeparator is not thread safe, and I think the code is rather clunky, so here's another, thread safe, version of JSFloat that I prefer:

function JSFloat(const F: Double): string;
var
  FS: TFormatSettings;
begin
  GetLocaleFormatSettings(GetThreadLocale, FS);
  FS.DecimalSeparator := '.';
  Result := FloatToStr(F, FS);
end;

This gets the format settings for the current thread's locale and then replaces the decimal separator with the required '.'. It uses the extended version of FloatToStr to convert the float according the provided locale.

Note that this code doesn't change the locale's decimal separator because we're operating on a copy of the locale information. Therefore we won't trample on any other parts of the program that may need the the correct decimal separator for the locale.

One further tweak suggests itself that takes advantage of the fact that the Format routine can take an optional TFormatSettings parameter:

var
  FS: TFormatSettings;
begin
  GetLocaleFormatSettings(GetThreadLocale, FS);
  FS.DecimalSeparator := '.';
  ExecJS(
    Format('showNum(%.8f, %.8f);', [123.456, -42.56], FS)
  );
end;

And finally, the promised implementation of the ExecJS method. Note that this is a method of the form that contains the browser control, which we assume is named WebBrowser1.

procedure TForm1.ExecJS(const Fn: string);
var
  Doc: IHTMLDocument2;      // current HTML document
  HTMLWindow: IHTMLWindow2; // parent window of current HTML document
begin
  // Get reference to current document
  Doc := WebBrowser1.Document as IHTMLDocument2;
  Assert(Assigned(Doc));
  // Get parent window of current document
  HTMLWindow := Doc.parentWindow;
  Assert(Assigned(HTMLWindow));
  // Run JavaScript
  HTMLWindow.execScript(Fn, 'JavaScript') // execute function
end;
Source code highlighting by DelphiDabbler PasHi.

Comments

  1. Emyleen7:58 am

    Hello, I just read your article on the execution of a JavaScript
    in Delphi, it is very interesting!

    I wonder if you know a way to recover a Delphi
    value returned by a javascript function?

    Thank you in advance:)

    ReplyDelete
  2. Delphidabbler11:27 am

    I have an old blog post called Call JavaScript in a TWebBrowser and get a result back that might be what you want. Also read the comments to that post - there's an alternative suggestion there.

    Hope that helps.

    ReplyDelete
  3. Anna Schafer7:49 am

    So you have to assemble a string containing the function call and its parameters, something like this:psd to drupal

    ReplyDelete
  4. Delphidabbler3:06 am

    jowdjbrown: Something wrong with you comment - missing text or broken link!

    ReplyDelete

Post a Comment

Comments are very welcome, but please don't comment here if:

1) You have a query about, or a bug report for, one of my programs or libraries. Most of my posts contain a link to the relevant repository where there will be an issue tracker you can use.

2) You have a query about any 3rd party programs I feature, please address them to the developer(s) - there will be a link in the post.

3) You're one of the tiny, tiny minority who are aggressive or abusive - in the bin you go and reported you will be!

Thanks

Popular posts from this blog

Deleting elements from a dynamic array

In my blog " Initialising Dynamic Arrays " I mentioned I have been writing some unit tests that needed numerous repetative array initialisation operations. Well, one of the other common operations I found myself writing was the deletion of items from dynamic arrays. So I decided to find a generic way of doing this. Assuming we know the index of the item to be deleted we need the equivalent of Delphi's built-in Delete procedure for strings. If you read the previous post you won't be surprised to learn that I decided to further extend the Generics.Collections.TArray class by adding to the TArrayEx class I introduced there. My first attempt emulates Delphi's Delete procedure by deleting the array element in-place: i.e. it updates the array passed as a parameter. Unsurprisingly the method is called DeleteInPlace . Here's how it goes: type TArrayEx = class ( TArray ) public .. . class procedure DeleteInPlace < T > ( var A :
Read more

Initialising dynamic arrays

When writing some unit tests a while ago I found myself needing to initialise some dynamic arrays with test data. It would be nice if we could do something like this: var A : array of Integer ; begin A := ( 1 , 2 , 3 , 4 ) ; // !! WRONG end ; but we can't. So I decided to write some functions to initialise dynamic arrays to the contents of another array, be it a constant, a literal or another dynamic array. The result was a set of overloaded routines, one for each data type I needed to handle, for example for Integer and string arrays I had: function CloneArray ( const A : array of Integer ) : TIntegerDynArray ; overload ; var Idx : Integer ; begin SetLength ( Result , Length ( A ) ) ; for Idx := Low ( A ) to High ( A ) do Result [ Idx - Low ( A ) ] := A [ Idx ] ; end ; function CloneArray ( const A : array of string ) : TStringDynArray ; overload ; var Idx : Integer ; begin SetLength ( Result , Len
Read more

New String Property Editor Planned For RAD Studio 12 Yukon 🤞

Image
This blog post is based on a pre-release version of the RAD Studio software and it has been written with specific permission by Embarcadero. No feature is committed until the product GA release. It seems I'm getting very excited about multi-line strings of late. My previous post was about multi-line string literals for Delphi  and this time I'm talking about the new multi-line string property editor being slated for the RAD Studio 12 IDE. For more years than I care to remember, I've been frustrated by the inability to enter multi-line strings in the Delphi IDE object inspector. That meant having to resort to code to initialise some multi-line labels. So frustrated was I that I wrote a little property editor of my own ( stringpe ), way back in 2004. It's still around and on GitHub. Here's what it (sometimes) looks like: Yeah, I know this is Vista - I used an old screenshot Sometimes? Well it looked like that until it got installed on DPI aware Delphis, and then it sh
Read more