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)

Other
Windows 95

Tracking

(Not tracked)

RESOLVED WORKSFORME
Future

People

(Reporter: oma00215, Assigned: adamlock)

References

()

Details

Attachments

(1 file)

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.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → REMIND
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.
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
Priority: P2 → P3
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 ago24 years ago
Resolution: --- → WORKSFORME
Attached file Delphi project using the control (deleted) —
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: