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.
Related
With XE8 update 1, Win 7 64 bit and a single component added to an otherwise empty folder I get:
error: [dcc32 Fatal Error] F2039 could not create output file .\Win32\Debug\MountTest.
The test will compile and run fine the first time but XE8 has to be shut down and restarted to compile again. The component is a gauge from Mitov Software.
The component vendor say's that this is a known bug with no fix. If so its a showstopper and project end'r for me. Is it really the end of the line for Delphi?
I hope some one can pull this rabbit out of a hat somehow.
This is what I have done to isolate the problem.
Started with a failing application (will not compile a 2ed time)
Remove all external units used
Remove al references to those units
Remove all references in the 'Uses' clause
Comment code until it compiles
It should compile every time you hit run (no problem).Now add a blank form to the project. Don't do anything to the form just add it. Add it to your uses clause.
Its should compile every time you hit Run.
Now open the blank form and simply touch it so that it needs to be recompiled.
When you run the application its back to failing when you run it a second time.
Notice that happens when you simply add a form and 'touch' it. No code needed.
This problem is not something wrong with my code - it can't be. Its a bug in the UI - must be.
Coincidentally, I just fought with this issue yesterday testing some components I ported to XE8. The output file in my case is the project executable.
After spending several hours trying to figure out what was going on (including efforts to reconfigure my AV software, disabling it entirely, moving the project to a different location, etc.), I was able to solve the problem by disabling Castalia. If I run the IDE without Castalia, the problem does not occur. If I enable Castalia again, it starts happening again.
You can find instructions for disabling/enabling Castalia in How can I disable Castalia in XE8?
I'm removing the above content because the issue has reappeared (with Castalia disabled). Further investigation shows a couple of things:
The problem seems to be related to any sort of exception being raised in the debugger (even those that are handled in the code). Clicking either Break or Continue in the debugger exception dialog works as always. However, the next attempt to compile or build the application fails with the F2039 error. Deleting the executable in Windows Explorer allows compilation and running once, and then the error recurs.
Restarting the IDE fixes the issue, until the next debugger exception occurs.
Neither taskkill or a batch file with del worked in either a pre- or post-build event.
There is an open QC entry for it at Embarcadero which indicates that it was reported in XE7, XE7.1, and XE8, and is currently an open internal ticket. I can't find a way to add the information in the two points above to that open ticket in the new JIRA-based Quality Portal. Perhaps someone who has access and can do so will on my behalf (or at least add a link to this post).
It's not linked to a specific project. The original answer (as mentioned above) was related to a test app while porting some components to XE8 from an earlier version. When the problem reappeared for me, it was in a brand new project, totally unrelated, that does not use any non-standard components.
(I previously had access to EMBT QC, and had a few open tickets. The accounts appear to have not migrated to the new QP, and I can't locate any tickets there under my account.)
Found It.
I decided to start from scratch on my development system and uncovered the problem.
I installed Windows 10 on a virgin disk
Installed XE8 update 1
Installed MITIOV Instruments for XE 8 and tested them. All working find
Installed AsyncPro - Still working
Installed the JEDI Jcl - Fails
Remove JEDI Jcl - now works
Trash JEDI completly - Everything works fine
Something in the JEDI Jcl version 3.48 is causing the problem. I can code around the JEDI components I was using without to much trouble but its a shame.
How about automatically kill your "hang-up" application before build?
I also had this problem on Win 7 Pro 64 bit with XE8.
Removing JCL fixed the problem. If I was a betting man, I would look closer at the JCL Debug IDE extension.
Guy's..
There is no reason to upgrade to Delphi 10.1, because all previous versions are equipped with an older version of the Android SDK.
Now, how to solve this annoying issue:
Just find the map where the Android SDK is located.
See: Tools/Options/Delphi Options/SDK Manager/Android Location
Now run the ..\sdk\tools\android.bat as Admin
This will show the Andoid SDK Manager.
Next is to update to the newest Android SDK and SDK Tools.
If all completed, you don't have to upgrade to Delphi 10.1 or whatever "advised".
Restart Delphi and problem:= solved!
btw:
It took some effort to find out what's happening here, because the Eclipse compiler suffered the same issue as Delphi. Finally all was related to bugs in earlier versions of the Android SDK causing adb.exe to keep a filehandle held hostage.
I've just downloaded from SVN the DUnit2 code base.
Does someone has compiled it successfully?
What steps/prerequisites I've to follow in order to compile it?
Do someone knows if an already compiled version exists?
thank you
fabio vitale
In the projects directory, find the subdirectory corresponding to your version of Delphi. In it, you should find a project-group file, either DUnit2ProjectGroup.bpg , DUnit2ProjectGroup.bdsgroup or DUnit2Delphi<version>.groupproj. Open it and compile all the projects in order.
Using DUnit2 is pretty much the same as using DUnit.
In case someone else stumbles over this question while trying to make DUnit2 run on Delphi XE (or XE5):
TL;DR:
Dunit2 (official SourceForge source, revision 101) doesn't currently (being as of this writing on 2015-06-01) build successfully on either Delphi XE or XE5.
To make it build on XE or XE5, go get the patch I posted here
Apply it to the source tree. It should now compile and you should be able to open the .groupproj and build all the contained projects successfully.
The patch may be applied with and was created with TortoiseSVN (in case it matters).
Longer version:
Amazingly tonight (2015-06-01) I followed the same steps as Fabio (in 2012 no less) and ran into exactly the same issue (E2010 Incompatible types: 'Pointer' and 'Integer') trying to compile DUnit2 (revision 101 trunk checked out directly from SourceForge) on XE and XE5.
I've come to the following conclusions:
1) There's multiple issues with the head revision with respect to both XE and XE5.
2) The key issue above that Fabio mentions can be fixed by replacing IntPtr with Pointer.
This doesn't actually seem to make any difference in the code as far as I can tell, and the test suites also pass fine on both XE and XE5 after this change, though caveat emptor - I've not looked too carefully either (and also subject to caveats below.)
3) Project search paths being out of date [XE]. Just needed updating/fixing.
4) Missing $DEFINES for XE5 and others, despite some other code being quite aware of XE5
5) Some enhanced TRect stuff that's not available on XE. (The amount is relatively small and relatively trivial to inline to more basic expressions that will compile and is available on XE so was by no means show stopping.)
(Re 3,4 & 5 -- Sadly I get the impression the codebase isn't very well tested against multiple compiler/BDS targets.)
6) Some kind of Application.OnIdle/GUI testing bug (run T_TGUITestCase tests to see it) whereby the GUI automation tests would block unless you keep "feeding" the Windows Message queue by say moving your mouse or pressing the shift key to trigger Application.OnIdle events (repeatable on my Windows 8 XE5 and XE binaries).
Now speaking off the top of my head, and from vague memory from many years ago, I seem to remember having run into this before, and that it is down to a subtle change in behaviour either in Delphi or in Windows some time ago. -- IIRC in past, it used to be the case that one would would actually still get the occasional Application.OnIdle() call in your Delphi app even when nothing else much was going on on the system, even when you set Done to True. And as I recall, this changed at some point due to either a change in Windows or Delphi (can't remember which) several years ago and one had to be a bit more circumspect about setting Done to False if you didn't want your App to go to sleep entirely. In any case, it clearly was/is an issue on my PC tonight with the current (as of this writing) DUnit code, so I had to patch around it.
I did this in arguably a rather kludgy way, e.g. by manhandling things via providing an OnIdle handler while running GUI automation tests to signal that that the app is not in fact done (e.g. "don't block, don't go to sleep") and then reinstating any prior handler immediately after. There is no doubt a more elegant solution to this, perhaps by posting a message to ourselves to keep the app "alive", but my first attempt or 2 at something better didn't work out and I'm not interested enough to pursue this further. I'd be interested to hear of a better fix though.
I've supplied patches, but got no feedback from the DUnit2 team on SourceForge. So I forked DUnit2 with the full commit history into my Github account. I've applied many fixes there, including the compilation issues with XE & XE3+ and the scriptable self-tests that pause if no mouse action occurs. I'll continue my development of DUnit2 on my Github account [https://github.com/graemeg/dunit2].
I've been banging my head against this for the past two days and can't seem to make any progress...
Pretty much from one moment to the next, Delphi XE2 won't properly compile one of my projects any more. That is, it actually compiles without errors but at runtime I get resource not found errors for what is essentially the main "form" (it's actually a data module in this case). I have already reverted to older versions of the project from source control that I know were definitely working alright but to no avail. Judging by that it seems it must be something inside Delphi/the IDE itself rather than in the project source. However, I have also not been able to reproduce the issue with a simple test project nor with any other real-life projects... It only happens with this one.
Another strange thing is that when I look at the produced binary with XN Resource Explorer everything looks as it should: The form resource mentioned in the error message is actually there and intact...
At some point I was suspecting this might be caused by a bug in one of the experts I have installed in my IDE (e.g. Uwe's platform and OI experts and VersionInsightPlus, Andreas' IDEFixPack and DDevExtensions, GExperts) but even after disabling all these the problem persisted.
Unfortunately, I am unable to track down exactly when this started to happen as I had been working for some time without actually running the binary, fixing compiler warnings and errors for the x64-target, adjusting build events for updated third-party tools (localization and license protection) and such things...
Has anyone else ever seen anything like this happen? Any more ideas on how to pin this down?
Some more details about the project:
It is an addin for Outlook built using the Add-In-Express framework (i.e. a COM-DLL).
The "main form" is a TDataModule-descendant - we also inserted our own ancestor-class into the hierarchy, i.e. the "addin module" is not directly inheriting from TadxCOMAddInModule - the resources of the custom ancestor forms also appear to be present and intact in the output binary when checking with a resource viewer.
Built without runtime packages for the Win32 and Win64 platforms.
Let me know if you think I missed to mention any other potentially relevant details.
Update:
I have now transferred the sources in question onto a different machine. Interestingly, the DLL I compiled there did not exhibit the problem - on that machine that is... when I transfered it back to the original machine and I tried to call it, the error was back (to stress this: this was the exact same DLL producing a EResNotFound on one machine but not on the other. Of course, once I had discovered this, I also performed the reverse test and lo and behold, the DLL compiled on the original machine works without errors on the other machine...
Seems this might not be a Delphi problem after all... but what is it then?
Differences between the two machines:
Machine 1 (the one were the problem occurs): Windows 7 Ultimate English 64bit with Delphi XE2 Update 4
Machine 2: Windows 7 Professional German 32bit with Delphi XE2 Update 3
On a third machine that is almost identical to the first except that it doesn't have Delphi on it, DLLs produced by both machines work flawlessly.
I am a bit surprised to see your question here. :)
We faced a number of serious issues with recent Update 4 for Delphi XE2. Though we have never run into or been reported of the "resource not found" error, I think this update might be one of the causes. Have you installed it?
One more thing that comes to my mind is images that you use for your Office controls (command bar and ribbon). Probably they got broken somehow, the run-time code cannot load them and reports this error.
Anyway, as you understand, these are just my guesses, if you need our assistance with your office add-in please contact Add-in Express support service, we will try to help.
Update: Seems I was a bit too quick, drawing conclusions. Apparently the Sisulizer solution is also supposed to perform a fallback to the main resource block. I have now taken this issue to the product forum and will report back here, once this is resolved.
Alright, mystery solved at last:
I had turned off the option to "Copy all resources" in Sisulizer in an attempt to reduce the size of the produced resource DLLs and then had forgotten about it...
I hadn't fully realized the implications of the standard Delphi resource DLL approach to localization on which Sisulizer "piggybacks" - especially that it was an all-or-nothing deal: Our previous translation solution implemented a fallback-mechanism that would read any resources not found in the external resource DLL from the host binary instead. This does not appear to be the case with Sisulizer - at least not out of the box... thus, any resource that's not contained in the localized resource DLL does not exist as far as the application is concerned.
I also didn't realize that the mere existence of a file with the same base name as the main binary and an extension matching the current system's default locale (such as .EN or .DE) would automatically cause the VCL to load it...
The machines that did not exhibit the error either still had the older, larger (=complete) resource DLLs on them, or no resource DLLs at all.
On my D2007 installation, I installed the DDevExtension, and also the IDEFixPack from the same site.
Unfortunately, now I have a component, TmxSideBarPro, that won't load into the IDE anymore. Any time I try, I get the following error in the IDE:
EPackageRegistrationException
Registration procedure, Mxtaskpanereg.Register in package c:!_cg2007\Packages\mxTaskPane_D11D.bpl raised exception class EAccessViolation: Access violation at address 20006A04 in module 'rtl100.bpl'. Read of address 9B8825DB.
I have tried uninstalling the extension above, and they report a successful uninstall, but I still get the error above when trying to install the component. The component vendor hasn't helped much, and I'm not sure they're in business anymore at this point. They did ask if I'd installed any special IDE tools, I explained my situation to them, but I never heard back from them anymore.
What can I do here to get this component working again? I'm willing to reinstall D2007, but I've also got D2009 installed, and I've read that you shouldn't install an older version after a new version.
Also, if there's a different forum category this should be in, please let me know.
Is there something loading that mxTaskPane_D11D? TO find out rename mxTaskPane_D11D to mxTaskPane_D11D!.!bpl (extra characters). Now something ELSE will fail to load. Now unregister that.
Are you sure you have uninstalled both DDevExtensions and IDEFixPack, for the right version?
If so your Delphi should be as it was before.
They don't do any permanent modification IIRC.
Are you sure nothing else changed? Did you recompile the mx package by any chance?
I've found Andreas' tools of very good quality and I would probably look elsewhere 1st...
I am not familiar with that component, but if you have the source code for it, try recompiling the package. I had to recompile several component packages when migrating from Delphi 7 to Delphi 2007. Many of the packages were Delphi 5 packages.
In the next few months I will be resurrecting a project which made extensive use of Orpheus and SysTools. The development system I used is long gone, so would like to update the libraries to my current development environment.
My question(s): is anyone porting, or has anyone ported the TurboPower libraries to Tiburon, if so did you encounter any problems; and if the answer is nobody, is it worth collaborating to produce a Delphi 2009 version, sharing the load.
Some components in the process of being ported to Delphi 2009, including 5 TurboPower libraries. No Orpheus or SysTools, though.
http://www.songbeamer.com/delphi/
Update:
As M Plaut pointed out, Orpheus has been added to the site and has been updated as recently as Nov 13.
Orpheus407AU_3 was posted at http://sourceforge.net/projects/tporpheus/ on Sept 5, 2009.
There is Orpheus project at SourceForge but last release was made in 2005 :(
Systools is also to be found there.
When turbo power closed their doors, I analysed my code that was using Orpheus and SysTools. I found that there were only a handful of SysToosl functions I was using and so we wrote our own functions. (Can't remember what they were)
It was fairly straight forward, some of them were in the newer versions of Delphi and the rest were easy to code.
Orpheus was a little more difficult. I would be willing to throw some time into bringing back Orpheus. We replaced it with standard Delphi components and some code, but our applications lacks some of the coolness it once had.
We would definitely be looking to port this as well. We use alot of Orpheus components in our current applications and this would be a definite roadblock to Delphi 2009.
As of 10-11-2008, there is a version at http://www.songbeamer.com/delphi/
of Orpheus as well. The following comments are attached:
This is based on the version from CVS. The first two packages compile and are partly tested. Some asm code still needs updating. Some bugfixing also need to be found and fixed. Contributions are welcome (use the contact form on the top). Search for "FIXME" in the source.
Files that may need special attention and bugfixes: OVCDRPVW.PAS, OVCPF.PAS, OVCEDITU.PAS, OVCVIEWR.PAS, OVCSTR.PAS
I have to bring a very old project to delphi 2009 : a CNC editor. The project didn't use Orheus at that time, but I was looking into it (did some tests), and the orpheus text editor is still the fastest on the market. So yes, I am very interested. I tried to compile the old source in delphi 9, but it crashes.
I am not a good programmer, but I can do tests for you.