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 fromTadxCOMAddInModule– 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.
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
.ENor.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.