The TWebBrowser component in Delphi XE2 seems to be seriously buggy. Is there some sort of code I have to run in order to instantiate it in some special way?
Create new Delphi project
Drop a TWebBrowser component onto the form.
In Form1.FormCreate() call WebBrowser1.GoHome (to google).
If I compile this 32-bit and go to some specific webpages I get error messages.
google (ncbi nucleotide blast) and click the first link.
In addition to these javascript errors if I click a link which usually opens in a new window, it opens in IE (a separate application).
The 64-bit version seems even more broken. By going to that same site (ncbi nucleotide blast) I get the entire program crashing due to a 'divide_by_zero' error.
Regarding the floating point exceptions, TWebBrowser expects to operate with floating point exceptions masked. It looks like you are using Delphi default floating point settings and have exceptions unmasked. I suspect that if you mask exceptions then your problems will disappear.
Do that like so:
SetExceptionMask(exAllArithmeticExceptions);
And as others have said, you silence the Javascript popups by setting Silent to True.
Related
When I add a file or form to a Delphi project, often I get an access violation. Then I have to restart Delphi, open the project and try it again. Then it sometimes workes, sometimes I get the same Access violation. I am having this issue in all Delphi versions since XE8.
Other Delphi programmers seems to have the same problems, as here on the Community of Embarcadero: https://community.embarcadero.com/forum/programming/9387-creating-a-new-unit-or-new-form-in-delphi-10-2-3-causes-access-violation
Some people say that it's caused by third part libraries. I doubt that. When you look at the stacktrace, there is no third party library.
To reproduce:
Work in a (somewhat) larger project and make some code changes before adding a unit.
Add a new unit/form: File>New>Unit - or add an existing file using drag and drop or 'Add file to project' - Or delete a file from a project.
I contacted Embarcadero about this. They know about this issue and they replied as following:
It's due to some Castalia code, that's merged in Delphi since XE8. It's only possible to reduce this issue, so it will happen less often. Use: Tools - Options - Editor Options - Color - Structural Highlighting and switch everything off.
Looking at how the code is integrated into the IDE, this results in less editor parsing and repainting. Irrespective of that, the handler that causes the Access violation is still attached to the editor.
So basically, we will have to wait for this to be fixed in 10.3.
But a while later, I discovered, that the Access violation only occurs if you have closed the project's 'dpr file'. So as a work-around:
Don't close the dpr-file and you won't get the Access violation.
I am experiencing a crash / exception when using a simple TOpenDialog with VCL Styles enabled.
Without the styles enabled, the dialog is of course working fine. The issue occurs with C++ Builder 10 and 10.1 Professional.
To reproduce:
create a simpe VCL Form that uses styles
add a TComboBox, a TButton and a TOpenDialog to the form
add the following code to the OnClick event for the button
OpenDialog1->Execute();
for(int i=0; i<100; i++)
ComboBox1->Items->Add("test text");
ComboBox1->ItemIndex = 1;
run the application, click the button and select a file
For me, this yields to an exception 'Out of system resources'
This bug could be reproduced on Windows 7 Enterprise and Windows 8.1 Pro.
Having the same issue with a TSaveDialog.
The weird thing for me is that regarding this exception, I can't find similar issues on the web. In my opinion, with only VCL styles and TOpenDialog required to have this, I would expect more information about this on the web.
I only found something remotely similar, but not an exception there and also no solution in terms of native VCL styles:
Using custom styles shows invalid characters when right-clicking a file in TOpenDialog
I tried also to disable SystemHooks shDialogs (please see screenshot) which I read somewhere regarding another problem with VCL styles, but to no avail.
* Edit 2016/05/26 *
Remy Lebeau is asking for a MCVE. I tried to put everything in the question, but for clarity here an abstract for a MCVE:
create new VCL project with default settings
drop a TComboBox, a TButton and a TOpenDialog into the form
add the following code to the OnClick event for the button:
void __fastcall TForm1::Button1Click(TObject *Sender)
{
OpenDialog1->Execute();
for (int i=0; i<100; i++)
ComboBox1->Items->Add(L"test text");
ComboBox1->ItemIndex = 1; // <- exception occurs here
}
enable a VCL style 'Smokey Quartz Kamri' in the project options
run program, press button, select any file and select OK in TOpenDialog
Here, this is really all it takes for the exception.
In my opinion, the call to Execute() messes up some VCL structures (only if styles are enabled) and then the access to another VCL item (combobox in my case) leads to the crash.
I am now aware that not every one has this crash. So forgive me if it is not a 100% verifiable example for each of you.
But me and my colleague can't be the only ones who have this crash (tested now on 4 different computers with 3 different OS versions), can we?
* Edit 2016/05/27 *
Regarding Tom Brunberg's request for single step, the exception occurs somewhere within WndProc, in the screenshot at address 005459F4 within the call.
If I step further, I am landing somewhere in TCustomCombo.WndProc. After that is is very hard to follow further because of repeating loops in WndProc, can't seem to reach the final place where the exception fires.
* Edit 2016/05/27 second *
OK I managed to pinpoint the exact location of the crash. Is in in the function CopyBitmap within VCL.Graphics. In the first screenshot, exception occurs at line:
Result := GDICheck(CreateCompatibleBitmap(ScreenDC, bmWidth, bmHeight))
In the function GDICheck() in the second screenshot, the variable Value is zero in the debugger, so in turn function GDIError is called. There, ErrorCode is zero as well, this leads to the call to OutOfResources.
Hope this helps to narrow it down further.
* Edit 2016/07/19 *
Since nobody here seemed to have the issue, we gave it a different try:
A colleague of mine in the company did a fresh C++ Builder 10.1 Berlin install, in English (thought maybe the German IDE is the culprit),
and first thing after the install, recreated the StylesCrashTest App. Result is the same, it crashes at once after selecting a file and hit 'open' in the dialog.
I have uploaded the test project here
http://fboom.me/file/9904e22ddd22b/StylesCrashTest.zip
and our generated release exe here
http://fboom.me/file/368d0b62cc1a7/StylesCrashTest.exe
The exe is tested with many antivirus scanners on virustotal.com.
https://www.virustotal.com/de/file/e96f2e7eb80c162c2e5998decc15f26615c9fc76efec73379dd2e2140e4eba08/analysis/1468952442/
It would be helpful if you guys could test the exe and the test project and this could lead to separate the issue to either computer related or related to the installed IDE/generated exe. This of course only if someone can reproduce the issue.
With this exe, the app crashes here on two Windows 7 x64 Enterprise computers in a commercial environment.
It does not, however, crash on my private computer with Windows 8.1 x64 Prof.
Right now I am at a dead end, nobody outside the town of Munich seems to be able to reproduce the issue, but we have it definitely on two different computers.
The issue is also filed with Embarcadero (login required):
https://quality.embarcadero.com/browse/RSP-15019
Sadly, at the moment, this is a shop stopper for us for using VCL styles.
I found a fix to get rid of the crash. After some more debugging, it was discovered that the exception occurs every time TBitmap::SetSize is called with a negative parameter on the VCL styled TComboBox.
Please see the call stack in the attached screenshot:
TComboBoxStyleHook::ListBoxWndProc
TComboBoxStyleHook::DrawListBoxVertScroll
TBitmap::SetHeight
TBitmap::SetSize
After editing SetSize() in Vcl.Graphics.pas to exit on negative numbers the exceptions seems to be gone.
This is no fix for the cause of the exception, because why the parameter is set to -1 in DrawListBoxVertScroll is still unknown (bug?, could also be the result of a lot more sub calls within this routine), but at least it is
a fix to prevent the exception. Tested on all our machines where the exception took place with positive results.
Would love to hear the opinion of some real VCL experts like Remy Lebeau or even the VCL developers about it, though.
Again, I realize that not everybody can even reproduce the exception, but with the test project linked above, the exception is inevitable on our systems.
Situation:
a DLL that:
is written and compiled with Delphi XE3 32bit
exports a function that displays a modal VCL-form:
function EditOptions(AIniFileName: PAnsiChar; ALCID: Integer): Boolean; stdcall;
is also a COM-server
an installer created with InnoSetup 5.5.4:
imports said DLL function via external 'EditOptions#files:mydll.dll stdcall'-directive and calls it when needed
explicitly unloads the DLL before registering the COM server via the Inno utility function UnloadDLL
Problem:
When...
Windows is using a theme other than Classic
the modal dialog from the DLL is displayed during installation
the installer hangs upon unloading the DLL
no error messages are shown
logs indicate no runtime exceptions
Please note that to keep this brief, I deliberately left out the explanations for some of the more idiosyncratic details, e.g. why I'm explicitly unloading the DLL or why a COM server needs to have custom exports. Let me know if you think these details would be relevant and should be added.
To further analyse this I created a dummy host EXE that calls the DLL function so I can easier run the whole thing in the debugger. Doing so leads to an AV being raised in TUxThemeStyle.UnloadThemeData on the line that calls CloseThemeData(). When placing a breakpoint directly on that line and stepping forward from the stop, I actually get a "too many consecutive exceptions" error eventually. I can only reproduce the error when I enable runtime themes for the host EXE.
Going back through our git history it appears that this issue exists ever since we switched from Delphi 2010 to XE3 (unfortunately, the installer was not part of our regular test suite so this only cropped up now as work on the actual release comes to a close as the DLL exports exist exclusively for the benefit of the installer).
Any ideas what might be causing this? Could this really be theme-related (I have no custom theme-related code in this project) or is that maybe just a symptom of memory corruption caused somewhere else entirely? E.g. I once had an error that manifested in the form of AVs in the theme tear-down code before but in that case it actually turned out to be caused by the leaking of anonymous method references from initialization sections...
Update: I've worked hard trying to produce a dumbed-down sample project to demonstrate the issue in isolation but so far without luck. I have managed to narrow down a few more things, though. First, here are some more facts about the code:
The dialog I'm showing is a third-degree descendant of TForm. The ancestors accomplish several things:
TAppModalDialog implements a special constructor CreateOnTop that ensures it appears as the topmost window in the current process (the project is a plugin that loads into multi-windowed third-party hosts that do unfortunately not communicate their window handles for use as modal parents) - it accomplishes this by manipulating the global Application.Handle.
TTabbedDialog is part of an interface-based framework that allows registration of "pages" (actually TFrame-descendants) via a factory pattern - at runtime the form will dynamically create TTabSheets in a TPageControl and instantiate and parent the registered page frames to them
I've replaced the call to the actual dialog with a dummy, gradually working myself through the inheritance chain from a blank TForm up to my TAppModalDialog and eventually to my TTabbedDialog class. The problem only starts to occur at that last level. I also commented out all page registrations around the project so that the dialog comes up with an empty page control (this rules out code in any of the pages as the cause for the problem). I then commented out all code and data members in the routines of the TTabbedDialog class itself, leaving only empty method bodies to fulfill the interface implementation requirement and the TPageControl component (along with two empty TImageLists and a TBalloonHint component) -> the error still occurs.
I then copied the call to the dummy dialog into a new DLL project that contains nothing else but this and the tabbed dialog framework. If I load that DLL into my dummy host EXE, the problem does not occur anymore... sigh
So, my suspicion is still that there must be some sort of memory corruption occuring somewhere else entirely and the error I see is only a symptom of that. So the real question is how can I finally get to the bottom of this?
I will now continue by commenting out / removing bits from the production DLL...
Delphi XE2 Update 4 Hotfix 1 and Help Update 6 for XE2.
If I am in the IDE, highlight an object name such as TLabel, then hit F1, I am transported to the description of Vcl.StdCtrls.TLabel in Delphi's help application. The page gives me information for both the Delphi and C++, but I can click on Display Preferences in the top right and 'un-tick' C++ so only the Delphi information is displayed. But now, if I click on TEdit (either by clicking within the help page under See Also or by selecting and F1-ing in the IDE), the Display Preferences automagically reverts to both Delphi and C++ when the TEdit Help is displayed.
If, on the other hand, I go directly to embarcadero online help, for example: http://docwiki.embarcadero.com/Libraries/XE2/en/Vcl.StdCtrls.TLabel to get the same information (using Chrome), the browser (?) remembers my Display Preferences and, once I have un-clicked C++, will only show me the Delphi information if I click on TEdit or further pages.
This drives me to distraction, as I am not the least interested in C++. Have I missed some option within XE2 to only select Delphi in Help's Display Preferences, or is this a 'feature'.
I don't think there's anything you can do with XE2's docs to fix this.
This was improved on in XE3's documentation, and improved even further in XE4's and since there have been four versions released since XE2 there won't be any further updates to it.
(You can't compare the online documentation with the local disk documentation; the first uses the functionality of the web browser, while the second uses the functionality in the MS documentation viewer, which happens to contain a web browser control but implements the functionality in the app itself instead.)
Answer by Ken White
Make a Delphi 2007 application, TForm as main window.
Run application. Try to drag the form using the caption bar. The debugger shows an unending stream of error messages, complaining it can't find some unnamed routine. Escape and Break don't work. 3 finger salute doesn't work.
Clicking in some other window and then back to the Delphi application stops the avalanche of error messages and allows the application to function in its original location (the form itself hasn't moved).
Strangely, on occasion I've had related behavior using Firefox -- clicking in the browser window doesn't work 'til I click in some non-Firefox window, after which the browser window is active again.
Anyone seen related behavior? Suggestions? Might it be a mouse driver problem? Toshiba laptop with ALPS touchpad mouse.
This doesn't sound related to Delphi specifically. The "stream of error messages, complaining it can't find some unnamed routine" sounds very odd. Could you post one or two of the actual messages, please?
In the meanwhile, my guess is some form of hook or injected code. Try looking for programs that do that kind of thing and disable them one by one:
Mouse drivers (as a poster above
said)
Antivirus, especially the "big ones"
like Norton etc
Some display driver "enhancement"
utilities
If you have two screens and you're
running a second taskbar program, try
that
and so forth.
It's probably worth doing a virus scan too, you never know :)
I know there was a Logitech driver hook problem when starting a Delphi project in Delphi: it gave an exception on the first line of the .dpr. Outside Delphi it worked OK.
So do you get those exceptions/problems only in Delphi? What kind of error/exceptions?