2111 - Mozilla Layout control does not work properly in a Borland Delphi 4 compiled program.

Status: RESOLVED WORKSFORME

(Core Graveyard :: Embedding: ActiveX Wrapper, defect, P3)

Description

[oma00215]

I am not sure if this is a bug or just sloppy programming on my part.
However, I attempted to use the Layout control dated 12-29-98 in a
program written in Borland Delphi 4.0 Professional.  In doing so, I
got a repeated Invalid Floating Point operation error.

When I ran the program outside of the IDE, I got an invalid floating
point operation in modual MSVCRT.DLL (address: 00001ED8) after
attempting to load something from a web site such as
(http://www.wvnet.edu/~oma00215/) and (http://www.mozilla.org).

I can provide the complete project source-code and the .EXE upon
request.  I did not want to post an unwanted binary to this news
group.  If it is simply due to my errors, I apologize for this
message.  If you wish to reply, please CC me a copy.

The code for the main form is included below:

==
unit navfrm;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms,
Dialogs,
  StdCtrls, ActnList, Buttons, ComCtrls, ExtCtrls, Menus, OleCtrls,
  MOZILLACONTROLLib_TLB;

type
  TfrmBrowserSample = class(TForm)
    mozBrowser: TMozillaBrowser;
    mmnuMainMenu: TMainMenu;
    File1: TMenuItem;
    actBrowserSample: TActionList;
    pnlBrowserSample: TPanel;
    sbrBrowser: TStatusBar;
    sbtnHome: TSpeedButton;
    Navigate1: TMenuItem;
    actFileExit: TAction;
    actNavigateHome: TAction;
    actNavigateBack: TAction;
    actNavigateForward: TAction;
    actNavigateHome1: TMenuItem;
    Back1: TMenuItem;
    Forward1: TMenuItem;
    Exit1: TMenuItem;
    sbtnBack: TSpeedButton;
    sbtnForward: TSpeedButton;
    edtURL: TEdit;
    lblURL: TLabel;
    sbtnGo: TSpeedButton;
    actGo: TAction;
    N1: TMenuItem;
    Go1: TMenuItem;
    procedure actFileExitExecute(Sender: TObject);
    procedure edtURLKeyPress(Sender: TObject; var Key: Char);
    procedure mozBrowserProgressChange(Sender: TObject; Progress,
      ProgressMax: Integer);
    procedure actGoUpdate(Sender: TObject);
    procedure actGoExecute(Sender: TObject);
    procedure mozBrowserTitleChange(Sender: TObject;
      const Text: WideString);
    procedure mozBrowserNavigateComplete2(Sender: TObject;
      const pDisp: IDispatch; var URL: OleVariant);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  frmBrowserSample: TfrmBrowserSample;

implementation

{$R *.DFM}

procedure TfrmBrowserSample.actFileExitExecute(Sender: TObject);
begin
  Close;
end;

procedure TfrmBrowserSample.edtURLKeyPress(Sender: TObject; var Key:
Char);
begin
  If Key = #13 then
  begin
    actGo.Execute;
    Key := #0;  {prevent beep when enter is pressed}
  end;
end;

procedure TfrmBrowserSample.mozBrowserProgressChange(Sender: TObject;
  Progress, ProgressMax: Integer);
begin
  if ProgressMax <> 0 then
    sbrBrowser.Panels[1].Text := IntToStr(Progress) + ' of
'+IntToStr(ProgressMax)+' ('+IntToStr(Trunc((Progress/ProgressMax) *
100)) + '%) Complete'
  else
    sbrBrowser.Panels[1].Text := IntToStr(Progress);
end;

procedure TfrmBrowserSample.actGoUpdate(Sender: TObject);
begin
  actGo.Enabled := (edtURL.Text <> '')
end;

procedure TfrmBrowserSample.actGoExecute(Sender: TObject);
var o : OleVariant;
begin
  o := edtURL.Text;
  mozBrowser.OleObject.Navigate(o);
end;

procedure TfrmBrowserSample.mozBrowserTitleChange(Sender: TObject;
  const Text: WideString);
begin
  Caption := 'Mozilla Browser Sample - '+Text;
end;

procedure TfrmBrowserSample.mozBrowserNavigateComplete2(Sender:
TObject;
  const pDisp: IDispatch; var URL: OleVariant);
begin
  edtURL.Text := URL;
end;

end.

Comment 1

[locka]

After investigation the bug appears to be "floating" up from the NGLayout.
Something in the base classes is causing the x86 FP status register to indicate
a floating point error. The Delphi client is checking the register and
reporting the error to the user.

I have tried to catch the error in the control as it happens using signal() and
try/catch blocks but have yet to succeed. It could be that something further
down is already catching the bug before I ever see it.

Further investigation is required. In the meantime, I have put a kludge fix
into the control that clears the status register in certain circumstances to
prevent Delphi from detecting the problem.

Comment 2

[Blake Ross]

reopening, marking Future, and updating QA contact

Comment 3

[Adam Lock]

*** Bug 39155 has been marked as a duplicate of this bug. ***

Comment 4

[Adam Lock]

Reassigning to myself.

Comment 5

[Adam Lock]

The current Mozilla control seems to be working pretty well in Delphi, so I'm 
marking WORKSFORME. I'm attaching a sample browser written in Delphi that uses 
the control.

Comment 6

[Adam Lock]

Attachment: Delphi project using the control