I have a working code that is working on IE6,7,8 & 9 Beta but crashes on IE9 RC.
I can see that the web page is using the ActiveX's interface successfully but when I try to call IDispatch::Invoke from the ActiveX , the ActiveX crashes.
My application is constructed from a CHtmlView (IE container) a web page (GUI) and an ActiveX (the application itself), I see that the webpage uses the ActiveX's interface successfully but when I try sending data back to the webpage I crash.
After debugging the code (vs2005 c++) I found that all IDispatch functions cause a crash, but this behavior only reproduce with the RC version, our product is already running for a bout 3 years without a problem and now every client that upgrades to the RC cannot use our product anymore.
Were there any changes that can cause such a behavior? according to the documentations on-line I couldn't find anything.
Thanks.
IE9RC introduced ActiveX Filtering:
Internet Explorer 9 RC allows you to block ActiveX controls for all
sites, and then turn them back on for only the sites that you trust with
the new ActiveX Filtering option.
After tiresome struggle I found the answer (2 years ago).
Back then I closed the questions on the IE9 forum but I forgot to close this thread.
Thank you #Paul Sweatte for reminding me.
Our framework worked as followed:
The activex and the web had a set of known strings such as: "onStart" , "onPause" etc...
The web would register the function in the engine.
The activex would call the callback when needed
The second part was the problem, apparently in old IE versions, the javascript eval function would create IDispatch objects, and you could pass the objects to the activex.
In IE9 along with many other changes this changed too, and eval would return something else.
The crush would happen when the activex tried to execute the callback.
It was ... VERY hard to debug.
Related
I have the community edition 10.3 of Delphi on Windows 10 and trying to use the JEDI (JVCL v3.50) TJvHidDeviceControllerClass (v 1.0.35) to control my HID device in a VCL form application.
This exception also gets thrown when I start up Delphi and when closing it down showing a dialog, provided that the component is already present on the form when loading the project. When ran with the OnDeviceCreateError() event handler assigned, the application behaves OK as I set the debugger to let the application handle this particular exception and setting the "Handled" boolean to true inside the OnDeviceCreateError() handler. It also works fine when run outside the Delphi GUI.
I have been searching for clues about fixing this issue and have seen that other people have encountered it as well. As most of the posts about this is quite old I wonder if I don't have the correct version of the library (https://github.com/project-jedi/jvcl).
The JEDI library was fetched from github just a week ago using the instructions on the readme page. My local repo was cloned from the master branch. I built it and installed it locally with no hassle.
Albeit working fine when running the application this exception is a bit of a nuisance as it messes with the Delphi GUI itself during startup (the exception dialog is shown, parts of the GUI goes missing after clicking OK).
I don't think that my code is the culprit here as the problem presents itself before any application code has even begun executing. I suspect that Delphi itself runs the constructor for the component before the OnDeviceCreateError() handler has been assigned and so the exception propagates all the way up to the GUI during palette placement or startup. Why the exception shows while shutting Delphi down is harder for me to explain.
Is there a fix to this or a setting to prevent Delphi running the constructor at design time?
Should I create the TJvHidDeviceControllerClass instance during form creation instead?
Thanks in advance /Thom
After some trial and error I worked around the problem by removing the component from the form designer and adding the TJvHidDeviceControllerClass manually with method bindings to the class in code instead.
The default constructor should not be used as it does not bind the exception handler at create time. Use the other one that does the binding.
It now works fine without stray exceptions at start/stop times.
When creating manually, be shure to explicitly free the TJvHidDeviceControllerClass object instance at form close.
I'm new to StackOverflow, and generally find the answers I'm looking for here. Except this time. I'm confuzzled. Here goes:
Some weeks back, I downloaded Revision 306 of Delphi Chromium Embedded, and installed it on a fresh copy of Delphi XE. Now, this was grabbed from the "Downloads" section of the DCEF Google Code page.
First thing I noticed was that the site mentions that Delphi XE is supported, but there is no project package included specifically for XE. Naturally, I installed the package meant for Delphi 2010, as the one for XE2 won't work due to FMX, and perhaps a few other things (?).
Having used an older build on D7 in the past, I naturally dropped a TChromium on the form, set the default URL to http://foundry-local/assist/node/, and ran the app. Here's what I was greeted with:
Exception EExternal Exception in libcef.dll ... External Exception 80000003.
Couldn't post anything in their new Google Group (they disabled the issue tracker on the Code page), so I thought I'd come here to figure out what happened. But just before that, I decided to checkout the latest code-build from the trunk. Installed it successfully (still no package for XE), dropped a TChromium on a blank form, and ran the app. This time I was greeted as follows:
Exception EReadError in module FoundryAssistNodeManager.exe at 0004BE24. Error reading Chromium1.Options.AcceleratedCompositingEnabled: Invalid property path.
And hence: I am really confuzzled.
(Edit: The app can see the core libraries, and they are being picked up.)
Has anybody else been having problems using DCEF on Delphi XE? If so, anyone had some kind of solution?
See, I'm building a customised help platform for my to-be-released products. Using IE is unreliable, and Gecko's components are no longer in development.
Any tips, guidelines would be great. Thanking you all in advance.
Technically speaking, this is not an answer to my question, but I feel it is necessary to show viewers of this question the best route to take.
Quite simple really: Upgrade to DCEF3.
Some developers local to me have also reported the same problem, with no apparent fix. Using version 3 solves the problem.
To the commenters above, thank you for helping as far as you could. Much appreciated.
We're in the process of moving a slew of our applications from Windows XP to Windows 7 and have run into an old problem with Word Automation.
We had an issue in one of our applications where we would get "Call rejected by Callee" when trying to connect to Word, unless it was already open. We worked around it in Delphi 2000 / Windows XP with the following code:
WordApp.Connect;
WordApp.Visible := True;
WordApp.Documents.Add(Template, EmptyParam, EmptyParam, EmptyParam);
WordApp.ChangeFileOpenDirectory(jdir);
WordApp.Visible := False;
WordDoc.ConnectTo(WordApp.ActiveDocument);
This no longer does the trick under Windows 7 - and recompiling under XE2 doesn't seem to help.
I've seen a related question here which pertains to Visual Studio - anyone know how to apply that to Delphi (XE2 would be fine at this stage)
Dan
"Call rejected by callee" errors happen when the instance that you are connected/connecting to is currently in an interactive mode: an open dialog for example. Or, in Excel, a cell being edited, or even being in a state where a cell being edited was interrupted by the user switching away from the application - when (s)he returns it may look that the edit was completed, but the interactive mode is not ended until a different cell is selected.
Because of this I don't understand why you were getting this error when connecting unless another instance was already open. If there is no instance open (and visible), Word cannot be in interactive mode and you shouldn't have been getting the error. Is it possible your remedy merely circumvented the real problem?
No matter what though, you are in a situation where you are trying to connect to an instance that is in interactive mode. Either beforehand, or caused by your code. As you switched from XP to Windows 7, UAC does come to mind as a possible culprit.
I'd do away with the work-around, and see where that takes you.
For Word automation I always make sure that:
I connect to a dedicated instance by using a ConnectKind of ckNewInstance and
make sure I do not make my dedicated instance visible or
make sure I only make it visible after I am all done and can turn the instance over to the user.
If you have no option but to automate against a visible (and thus non-dedicated) Word instance, you will simply have to deal with the possibility of this error coming up. When it does, alert the user to what is happening and make sure you offer a retry.
Update
The thread on the Embarcadero forums mentioned in the comments by #Hendra includes a link to some very useful MSDN documentation: Fixing 'Application is Busy' and 'Call was Rejected By Callee' Errors
This is a continuation of my last question. In that question I showed a problem involving TWebBrowser generating threads that persisted after the Browsers destruction. While noone could provide a solution to the problem, it was suggested that the problem could be a non-fixable one (a flaw with the TWebBrowser component itself).
Because of this I have attempted to download and use the Delphi Chromium Embedded Framework. I downloaded the components and added them to Delphi, added one to a new form and attempted to run the program, at which point it throws up a CPU break point at
5264DF81 6A01 push $01
Module Load: icudt46.dll. No Debug Info. Base Address: $562C0000. Process DCEFTestRun.exe (3080)
There is no error message, but when the program is continued manually it closes. I have had no experience with DCEF before, nor any experience using 3rd party components and the DCEF site is sorely lacking in documentation.
I suppose the easiest thing i'm asking for is a simple walkthrough (very basic) of what to download/install and where to get the Chromium Components to work.
Thankyou in advance.
You are missing the Chromium Embedded Framework (CEF) core libraries. It is enough to copy the content of the ..\dcef\bin\Win32 folder (from your downloaded package) into your project's output directory (or into some of the known folders location reachable from your project's executable).
This is occurring on 2 machines that are both running Windows XP Pro SP3, yet it runs OK on my development machine within in or outside the Delphi IDE.
Running Windows XP Pro. Exe compiled under Delphi 2010.
When I run the exe I get the Windows Reporting error "Neopos.exe has encountered a problem and needs to close. We are sorry for the inconvenience"
I know it is happening somewhere in the form create of the main form.
Application.Initialize; //Runs this
Application.CreateForm(TfmMain, fmMain); //FAILS HERE
It does not get to: procedure TfmMain.FormCreate(Sender: TObject); in the Main Form and I don't know how to track down this error and debug it.
What happens between: Application.CreateForm(TfmUDF, fmUDF); AND procedure TfmMain.FormCreate(Sender: TObject) in my main form.
How can I trace this to find out what the hell is causing the Windows Error.
Of course the Windows Error report contains a long listing of information. Where can I look in that to find the cause or at least a clue on the cause of the error.
This error has now stopped all development work (and ruined my weekend) so I urgently need to fix this.
The most straightforward route to take would be to include a product like MadExcept or JCL Debugger into your application, to get a full call stack (including line number) of the point of failure. We've rolled our own years ago, and it has been a tremendous help in situations like this.
One alternative, but lots more cumbersome, would be to generate a MAP file from your project, use MAP2DBG to generate a .MAP file, and use the Windows Debbuging Tools to get about the same information. This approach is a lot more hardcore, and only advisable if you really want to learn a lot about the internals of windows debugging (and enjoy working with arcane tools).
Another alternative would be to attach to the failing application from your development environment using Remote Debugging. Only applicable if you have a fair amount of control over the failing machines.
#user576639, here are some debugging ideas:
Look into the System's Event Viewer
If you got the exe has encountered a problem and needs to close chances are you'll find something about it in the System's Event Viewer. That should be your first step.
Any special DLL's required?
Do you need MIDAS.DLL?
Are you using an database engine? Does it require some sort of client library?
I'm talking from experience here: My development machine obviously has all the libraries I might need. Most of my clients also have most of those libraries because they have my software installed. At times I put out small helping applications that don't go throw extensive testing and they fail to work on SOME machines but work fine on other machines. Why? I used TClientDataset and forgot to include MIDAS.DLL with the application; Or the application is trying to access a Firebird SQL server but the user doesn't have Firebird client library installed.
Printer driver issues
Boy I hate Delphi's printer handling. Also hate buggy printer drivers, haven't made up my mind about what's worst. If you have something on your main form that might be requesting information about the default Windows printer (example: an REPORT) give this a try: Install an sane/simple printer and set it as the default printer. If the user has Office 2007+ installed, set the "Microsoft XPS Document Writer" the default printer.
I have seen bad printer driver + delphi issues manifest themselves with the "exe needs to close" symptom.
Prepare an special build of your application
If you got this far without fixing your issue it's time to create an special build of your application that's capable of providing more information. First of all I'd try adding this to your DPR file; Don't know if this is still useful for Delphi 2010 but it did help me see some early exceptions with a Delphi 7 application:
function HandleUnhandledException:integer;stdcall;
begin
Result := 1; // 1 = EXCEPTION_EXECUTE_HANDLER
end;
// and then immediately after "begin" in your DPR file:
begin
SetUnhandledExceptionFilter(#HandleUnhandledException);
// ... the usual stuff goes here
end;
Add some ShowMessage-s to your Main Form's code, in your OnCreate handler (if you have one), in your Create constructor (again, if you have one). If you're adding an ShowMessage to your Create destructor, make sure it's after the "inherited" call. This will help pin-point how far the loading of the form goes before it fails.
If all else fails...
Create a new, blank form; Make it the new Main Form (so it's initialized before your former Main Form). Test it on the client's machine - does it show up? It most likely will, if it doesn't you've got some serious problems.
Start copying the components from the former main form to the new main form; Only the components need to be copied, not the code: Your error is probably caused by some component failing to initialize properly. Make sure no component has "Active=True"! Copy the components in small batches, test often. If you spot the component that causes your form not to load on the client's computer, tell us about it and we'll try to help.
If you manage to get all your components on the new form, write an OnCreate handler that sets Active := True for all the components that need that. Did that fix the issue?
If you got this far then all the components you used on your main form can load properly. The problem's related to YOUR CODE. Start copying all the code from your old main form to your new main form, in small bits, and test. You're bound to find the peace of code that causes your application to stop loading.
Use dependency walker to see if you're missing a required DLL.
You can use information from system reporting (your error and suggestion to send it ) with Error Report Grabber ( http://www.maxerist.net/main/soft-for-win/err-rep-grabber ). I developed this tool when I desperately needed to track a error that appeared very rarely so almost non-reproducible. It helped me to track the information from stack to find actual place in the code.
The tool works only on XP (MS removed this dialog in Win7 and probably Vista), but I see that your cases are XP so this can help.
UPDATE: if you're not familiar with assembler and everything, this can work like this.
You should compile you program and don't change anything. Save the report on a bad machine, copy the file to your developer machine and open to view the contents. Look at the stack of your main thread in the report and find numbers more than $00400000, they're usually the addresses inside the procedures that called some other procedure and wait for return. In your developer machine, start the program and stop at any line, open CPU Window and on the main list with assembler instruction right-click and choose go to address, enter this address. You will see other assembler lines, but wrapped with pascal constructions you can probably recognize as yours
Thanks a lot for the help.
In the end I reverted to a recent backup and traced it down to a particular form.
I did not actually find the error, which is a bit worrying, but in any case I am back up and running (phew!!)
I made the error to occur on my development machine also, when, and only when, I use my install program (Inno Setup) to compile a setup.exe and which installs the exe as well as installing postgreSQL. Seems really strange, as though there is a problem with the setup compiler. In any case I have not seen the error again. I guess it will remains a mystery, like women.
In Delphi withing debugging options select debug dcu's, this will allow you to debug into the Delphi source code for TForm and its descendants and you may be able to track down a more likely culprit.
Set a breakpoint on
Application.CreateForm(TfmMain, fmMain); //FAILS HERE
and then step into the code to see where the issue is.