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].
Related
I'm having a very similar problem to the one posed in this problem (having to connect twice on first load because of a "problem" loading the SSL dlls), except I'm pretty sure I'm using the latest version of Indy so the solutions proposed there do not solve my problem.
I am using Delphi7, and I selected not to install Indy from the Delphi7 installer since that version is incredibly obsolute. I did install Indy9 from latest SVN source before downloading and installing Indy10 (from SVN source), but I reconfigured the IDE and project settings to use the new Indy10 components/paths instead of Indy9. Clearly the project is using Indy10 to build as there are quite a number of methods I had to change to match all the Indy10 signatures to even compile.
My SVN repository for Indy10 is checked out from: https://svn.atozed.com:444/svn/Indy10/trunk/Lib and shows last commit revision of 4972, about 2 weeks ago--this does not look like "some really old version of Indy10".
I have downloaded OpenSSL 1.0.1e for Win32 from the binary build at http://opendec.wordpress.com/ (the location recommended from that other stackoverflow question I mentioned earlier) and put it in the same folder as my built .exe
Here's the code I'm using right now to open an SSL connection:
try
POP.Connect(Server,Port,Protocol,UserName,Password,TimeOut);
Except
on e : EIdOSSLCouldNotLoadSSLLibrary do
begin
ShowMessage('Failed to load: ' + WhichFailedToLoad());
POP.Connect(Server,Port,Protocol,UserName,Password,TimeOut);
end;
end;
BUT... this is causing an EIdOSSLCouldNotLoadSSLLibrary exception, and adding WhichFailedToLoad shows the exact same list of components, that would suggest it's expecting the "indy specific" version of OpenSSL:
But Wait a minute... Remy answered in the linked question that "Indy 10 was updated to no longer require the custom-built DLLs anymore. It now uses the standardized OpenSSL DLLs as-is." So why would it be complaining that it needs Indy specific functions?
How could I troubleshoot why it's failing to connect the first time/saying it needs functions I understand not to be needed anymore? Is my expectation that it should not be looking for indy specific functions incorrect?
My guess, confirmed in the comments to the question, is that your compiler is finding Indy 9 and not Indy 10 to build your project.
The things can go ever worst, because your IDE may be using one version in design time and the compiler may be using a different version. In fact the IDE and the compiler are different parts of the chain and you can broke the original synchronization between both. Because that, I'll explain both cases and, as I explain later, you have to change both.
The IDE and design time
Design time packages are loaded by the IDE to create objects while you're working, show you the properties of that objects in the object inspector, create the form DFM files and get the method firm to be used when you resort to the IDE to generate pascal code to respond to events.
For the IDE you can check what version you're using in design time by right clicking on any Indy component, as shown in the image.
To change the version you're using in design time, go to Component\Install packages and check the correct version in the list. You cannot load Indy 9 and Indy 10 at the same time.
The compiler and run time
The compiler uses the Library path to look for the units you use in your project that are not part of the project itself, and compile that code along with yours to produce the executable.
To check what Indy version was linked into your executable, you can resort to the Version property present on all INdy components, for example:
ShowMessage('Indy version: ' + MyIndyComponent.Version);
To change what the compiler finds first, you have to change the paths. You can do it from inside the IDE. In modern Delphi you could check in Tools\Options\Delphi options\Library\Library path\ and Project\Options\Delphi compiler\Search path\ (I just don't remember where the options were in D7).
The Indy 9/10 case
Indy introduced interface breaking changes that makes impossible to compile a project written for Indy 9 using Indy 10. In fact, the administrators of the project doesn't wait for a major release to break the code compatibility and you expect to be forced to adjust your code when you upgrade to any minor version if it happens to have a different interface.
Because of that, you're definitely using Indy 9 in both, at compile/run time and IDE/design time, so you have to adjust both in your environment. After that, be prepared to re-write part of your code to adjust. Once you understand what changed and learn how to adapt, the change is fairly simple. The details are out of the scope of this answer, but there's enough information in the Internet for you to figure out how to do it.
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.
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.
I've created an auto-updating application which is distributed to 100s of users.
The auto-update utility is being flagged by 55% of antiviruses on virustotal ( link ).
My application was created in Delphi 7. Most of the flags are saying that this is Generic trojan/malware, obviously the software isn't actually malware (I'm the only one with source code access and access to the server which hosts it) but it's causing a lot of users to be
Does anyone have any idea how I can stop this being wrongly flagged?
If, as you stated, empty form applications get rated as virus, you might very well be infected by the Delphi virus. More info about this... thing:
http://www.delphipraxis.net/topic163041_virus+infects+delphi.html
http://www.viruslist.com/en/weblog?weblogid=208187826
Virus in Delphi 7
http://www.itwriting.com/blog/1717-delphi-developer-virus-exposes-weakness-in-anti-virus-defences.html
In addition, you use Delphi 7, which is a target for this virus (as far as I know not all Delphi versions are).
Delphi 2007: New VCL Application
Compile without changing anything and some antivirus packages will report the resulting EXE as a potential virus/trojan. Change the name of the main form or add a second form to the project etc and antivirus warnings disappear. Undo the changes and they come back (so it's not a D2007 port of the "Delphi Upgrade Incentive Virus").
My guess is that someone, somewhere once upon a time wrote a virus/trojan/malware with Delphi and the signature/heuristics associated with that now sometimes unfortunately collides with other Delphi apps.
I think you have two choices:
a) Submit your auto-update program as a false positive to all those companies, (and do so for any new versions that are detected). Make it easier for them by ensuring your meta-data is correct and signing perhaps.
b) Split up the functionality so you don't have a single Delphi program that downloads files from the internet, overwrites files and patches files.
It depends - if the 100s of users are on a corporate network, using the same enterprise antivirus software administered by group policy, one solution could be to specify your software as an exception in your antivirus package.
I would try to refactor the program, changing names, changing the order of the procedures and methods, some program structures, removing, replacing, and adding code.
Submit each change to VirusTotal.
You might eventually detect what is causing the problem.
If your program "modifies" an executable, it will be picked up by a lot of AV programs.
I've even seen Borland's patch program that was distributed with Delphi 7 flagged as a generic virus when installed fresh off the CD.
I'm not sure there is much you can do about it, unless you can turn that "feature" off in the AV program or have the rights to add an exception for it. Personally, I think it's just a lazy "catch-all" created by the AV software writers.
AV software also check the Import Table for common API used in viruses, though I don't see any API that will trigger the AV software in the scan report.
See my post at anyone having problems with delphi 2010 and norton internet security. Lately I have been getting SONAR errors too with Delphi 7 compiled programs (and by programs compiled with other compilers).
I reported this to Norton, look also at hot issues at Norton board.
Of course this is only Norton, you don't specify which virus checkers you encountered.
We got the same problem here...
Ant-virus detect some behaviors of our software too.
The ant-virus company doesn't say exactly what they watch (sure, security issue).
Here for example I got this problem when I started using pipelines.
What we did ? We call the security companies, they analysed our .exe, and now we have "white flag" on them.
...No, it isn't so fast process.
Ok, I'm going nuts here. For the last (almost) four years, I've been putting up with some extremely bad behavior from my Delphi 5 IDE. Problems include:
Seemingly random errors in coride50.bpl
floating point errors on compiling
occasional deletions of my source code files
form and object sizes shifting between instances of working on them
Loss of links between files on compile: messages that it can't find a function even though it is explicitly referenced
The linker frequently fails to include valid .DFM files unless a full build is performed instead of a smaller compile
The biggest problem is that my boss isn't believing that this is happening without any user changes making these issues appear. I've already wiped and reloaded Delphi fresh a couple of times, but that is not something I can do again right now. Most of the issues listed can be easily recovered from (either reload the IDE or re-copy the files out of source control), but this is completely nuts. I've eliminated all the warnings and hints from compile time, haven't covered them up. I've done my best to follow Marco and Microsoft's best practices. Is this just me? Am I the crazy one? How can I stop Delphi from causing these headaches anymore?
Pretty sure it is a bad package. If you can come up with steps that fail repeatedly (which I know is tough) then try removing 3rd party (or home grown) packages 1 at a time until it is fixed. Then you at least know which package us causing the trouble.
Once you know what the troublesome package is, you can actually debug the design time code & behavior of the component in Delphi. Just set the Delphi exe as the debug application, and then Delphi will launch another instance of Delphi in debug mode. Reproduce the steps that cause the failure, and hopefully you will get a good idea of what code in the package is causing the problem.
Good luck!
I have never seen any version of Delphi delete files under any circumstances.
Do you have any IDE plug-ins installed? This would be my first guess.
I've never heard of behavior like this from Delphi before. A couple of things to look at:
Are you sure the memory on your machine is good? Have you run Memtest on it?? The last couple of times I've encountered crazy behavior from a machine the culprit turned out to be the memory.
Beyond that, remember that anything you install into Delphi runs in the context of the IDE and if it's buggy it can mess up the IDE. Even a component that writes to a wild pointer could do this to you.
i used d5 for a long time & never saw that. i had some other strange things like you mention about needing to build rather than just compile. i have that in d2009 as well.
Just a thought; pikcing up one of your comments about you having D5 and D7 installed, I'd suggest;
uninstall D7
uninstall D5
reinstall D5
install D5 3rd party components
service pack D5
reinstall D7
install D7 3rd party components
service pack D7
then try again, having done the trick of deleting all the .DCUs in your own project directories.
In my experience I've always been careful to stick to installing them 'in numerical order' and if one needs to be removed, I usually end up removing them all before I start reinstalling.
GExperts ToDo list window... close it or any other GExperts Windows.. Watch the Task Manager for memory increasing and then stopping after you close any windows.
Pretty much out of Delphi 5.0 these days. But I do recall it was important to have the latest Build for various reasons. Do you have it?? Go Help->About. I believe this is the latest version:
Version 5.0 (Build 6.18) Update Pack 1
Which OS are you using? If it's Windows 7, perhaps there are incompatibilities with Delphi 5, since it's a bit long in the tooth now. Perhaps you could try running Delphi 5 in a XP VM.
Since you had no problems with Delphi 7, is there any reason for not migrating this application to Delphi 7? It shouldn't be difficult to do, unless you have some third party components with no source.