Closed
Bug 2111
Opened 26 years ago
Closed 24 years ago
Mozilla Layout control does not work properly in a Borland Delphi 4 compiled program.
Categories
(Core Graveyard :: Embedding: ActiveX Wrapper, defect, P3)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
Future
People
(Reporter: oma00215, Assigned: adamlock)
References
()
Details
Attachments
(1 file)
(deleted),
application/octet-stream
|
Details |
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.
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•24 years ago
|
||
reopening, marking Future, and updating QA contact
Status: RESOLVED → REOPENED
QA Contact: cpratt
Resolution: REMIND → ---
Target Milestone: --- → Future
*** Bug 39155 has been marked as a duplicate of this bug. ***
Reassigning to myself.
Assignee: locka → adamlock
Status: REOPENED → NEW
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.
Status: NEW → RESOLVED
Closed: 26 years ago → 24 years ago
Resolution: --- → WORKSFORME
Updated•13 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•