does reportmanager (http://sourceforge.net/projects/reportman/) support delphi 2010?
Thanks
Alejandro Jourdan
It looks like the most recent download on SourceForge only has premade projects to compile native components up through Delphi 2009. I expect it should be easy enough to revise the D2009 project to compile under D2010.
Also, as you may know, you could use ReportManager with D2010 without having the native components at all.
You might get more complete and accurate answers in the Report Manager user group on Yahoo:
http://tech.groups.yahoo.com/group/reportman/
I managed to compile the latest 3.0 version with Delphi 2010 Professional. Not a really easy task.
In order to do so, you have to follow these steps:
Edit the .inc file and see if you can exclude unused libraries.
In my case I undefined IBX and used ZEOS for database.
Then you will get an error about IntPr being not defined. Replace it with Pointer.
You will get hundreds of FormatSettings not defined errors. You have to remove such identifier. I.e. go in search and replace and type: "FormatSettings." including the dot and in replace leave it blank. Repeat for the many files that will show the same error, or do a multi-file search and replace at once.
You will possibly get references to IBX units or packages even in case you removed it from the .inc file. You may just delete the offending lines.
You will get a nasty missing unit WinApi.Common... Remove it from the uses clauses, you don't have it.
At a certain point the above point will cause an undefined FOLDERID_Public.
Go to the const section of the offending file and add this:
FOLDERID_Public: TGUID = '{DFDF76A2-C82A-4D63-906A-5644AC457385}';
That should do it, now you are the proud owner of Report Manager 3.0!
Installed today in D2010 on XP without particolar problems.
First downloaded and installed ver. 2.9b executable file.
Second downloaded Delphi package, added source path to the library, opened and compiled group project file.
Received 3 errors (even the same error type): vcljpg Not Found.
Simply rename vcljpg with vclimg.
after that, compiled done, installed.
Related
I've created some components in Delphi and I would like to give them to somebody else for use, but without source code.
I use the latest version of Delphi (10.2 Tokyo).
What are the steps I need to follow? Thank you!
If you want to share components in Delphi without source code, you must ensure that the other user has the exact same version of Delphi as you have[1]. This won't work with a different version. Note that it does not have to be the same SKU, i.e. you can have Professional or Community and the other can have, say, Enterprise. Only the version (e.g. Berlin 10.1, Tokyo 10.2, etc.) is important.
Then you can either
put them in a package and distribute the bpl and dcp files.
distribute the dcu files.
or both (preferrable)
Note that the user will have to install these. There are instructions in the help files on how to do that (no link, sorry, as the DocWiki seems to be down right now). Note that the package must be in one of the paths in the Windows DLL search order.
You could of course also write an installer, using one of the installer creating applications like InnoSetup (no association), but that is a topic of its own.
[1] That is the reason that many Delphi developers prefer components or classes with source and would not accept or buy one of these without source. Having the source also allows you to fix little bugs.
I have my Delphi application up and running in XE2.
I am using fastreport provided with IDE.
When i tried to migrate from Delphi XE2 to delphi 10.1, I get issues for fastreport.
[dcc32 Fatal Error] fs_isysrtti.pas(615): F2051 Unit fs_iinterpreter was compiled with a different version of fs_isysrtti.TfsSysFunctions
I have added lib path in tools->options.
What can be issue over here?
The error message means what it says: there is a mismatch between the current version of fs_isysrtti and the one which was current when fs_iinterpreter was compiled. This is probably because the compiler is finding an out of date copy of fs_iinterpreter.dcu before the one it ought to find. Try searching your machine for versions of this .dcu file and renaming/hiding all except the newest (or the one in the same output folder as the compiler is trying to compile fs_isysrtti to, which is hopefully the same thing).
If your system is anything like mine (I have XE4 to D10 Seattle installed) you will find a number of versions of these dcus (fs_iinterpreter.dcu, that is).
Assuming this procedure removes the compiler's complaint, one-by-one reinstate the dcus you renamed or hid until the problem re-occurs and then you know which copy is causing the problem. Then work out how the D10.1 compiler is managing to find it and prevent it. Possibly, the compiler search path is causing it to look in the wrong place before the correct one.
Unfortunately, even if you manage to find the .dcu that's causing the problem, you may then find that the compiler raises a similar complaint about another Fast Report .dcu. If is does, then your easiest option may simply be to hide/rename all the FR files and reinstall it.
Uninstall FR, install it again and remove pas files from LibD24 folder
or
install all updates for Delphi 10.1 Berlin and use latest FR 5.5.11
I 've just got the same issue when I tried to convert old quickreport files to Fastreport 6.2.1 (Delphi 10.3.3 64 bit Target)
I found an easy solution here:
https://wiert.me/2016/06/30/built-in-delphi-xe6-xe7-and-xe8-fast-reports-have-issue-f2051-unit-fs_iinterpreter-was-compiled-with-a-different-version-of-fs_isysrtti-tfssysfunctions/
if the link wont work:
you have to move the *.pas files from the path
"c:\Program Files (x86)\FastReports\LibD26x64"
(it was my path, check yours. /where the fs_isysrtti.pas/)
and it works.
I write a lot of components and libraries for Delphi, most of which require the use of BPL Packaging so that they may be installed into the IDE.
This is simple enough and works well, right up until you want to maintain a single set of Package Project Files (in a single Project Group), but also want to compile and distribute those same packages for different Delphi versions.
Up to now I've been creating a different Package Project for each version of Delphi, and explicitly defining a Delphi Version Identifier as a suffix (e.g. Kinect_XE.bpl and Kinect_XE2.bpl).
I am aware that, in the Project Options for a Package Project, under Description, there are the fields LIB prefix and (more importantly for my needs) LIB suffix.
I am further aware that if I place a value in LIB suffix, it'll be appended to the end of the compiled BPL's filename.
My question, however, is first whether it is possible to have the IDE automatically populate the LIB suffix field with the IDE/RTL Version number, and if so... how?
I'm fairly certain this is possible, as it would appear that vcl120.bpl (and its counterparts for each respective version of Delphi) can be Referenced (as requirements) of your own packages using just vcl rather than having to type the full vcl120. It is, in fact, this same behaviour I'm hoping to achieve... where my packages can intra-reference eachother (as neccessary) without having to provide version-specific references to accommodate the suffixes.
Equally important is that resolving this will enable me to maintain a single set of Project Files in a single Project Group (with the obvious exception of XE2 where its Project Files don't necessarily behave very well with previous versions of Delphi due to the Platforms addition).
I suspect that I may need to put a value like $(VER) (or something similar) in the LIB suffix field, but this appears not to work and I've scoured Google looking for the correct solution.
Hope you can help!
UPDATE 1
I am now writing an IDE plugin to be used with (in the very least) Delphi 2007 to XE2, which gives DLL and BPL projects a new option called AutoSuffix. When toggled On, any IDE with the AutoSuffix plugin installed will immediately apply the correct IDE version suffix to the project.
The AutoSuffix plugin will be made available (freely) for everyone within the next 24 hours, and this question updated accordingly.
UPDATE 2
Okay... Delphi 2007 is being a pain! I've made AutoSuffix work with 2009 to XE2, so far, but 2007 requires a little more time (patience appreciated).
UPDATE 3
It would appear as though Embarcadero have heard our collective cry for simplier package unification between versions.
Mark is going to push this through to see if future versions of Delphi can accommodate a {$LIBSUFFIX AUTO} feature. I hope to hear back very soon whether this will be the case. If so, it certainly affects the way AutoSuffix will need to work on XE2 and older versions (as presently it doesn't provide the simple AUTO switch.. it has its own method).
My hope now is that EMB will take this request seriously, provide it as an integral feature going forward, so that it becomes a simple case of using AutoSuffix on existing versions to unify the process accross all versions!
AFAIK for Delphi up to XE2 there is no automatism for doing this.
Concerning the requires clause: when you require another package you are actually using the dcp, which doesn't inherit the LIBSUFFIX. Thus it is sufficient to require VCL.dcp during compile time, while VCL160.bpl is actually used during runtime. The DCP includes the complete BPL name to resolve that.
This makes the LIBSUFFIX approach superior to the simple "rename the package for each version of Delphi" one.
A solution like that suggested in QC83229 would make it easier to port a package to a newer Delphi version, but then you are still stuck with dproj files that are not backwards compatible.
I normally use different folders for each Delphi version, where only the project files are stored. For a new Delphi version I only have to copy a folder and change the LIBSUFFIX.
LIBSUFFIX directive is in *.dpk file, and you can edit *.dpk file manually.
You can write, for example
{$IFDEF CONDITIONALEXPRESSIONS}
{$IF CompilerVersion = 20.0}
{$LIBSUFFIX '120'}
{$IFEND}
{$IF CompilerVersion = 21.0}
{$LIBSUFFIX '140'}
{$IFEND}
{$ENDIF}
The bad thing is that IDE does not respect your manual edits of *.dpk file and deletes them then you make changes in a package. That is why some component vendors that use conditional defines in *.dpk file say in installation instruction if asked to save changes say 'NO'.
My suggestion would be to add this as a configurable option to project option sets (see QC #86491.) Rather than updating all the packages it would be sufficient to update a single option set file.
In fact, it seems the DllSuffix tag is recognized by the option set files in Delphi XE/XE2. Adding <DllSuffix>160</DllSuffix> to the <PropertyGroup> section of an option set file will cause the suffix to be appended to the package in the project manager. However, you still have to open the project options and click OK in order for it to be saved to the .dpk file.
I agree that it would be extremely useful with this feature (I would think also for the packages in the RTL.)
{$LIBSUFFIX AUTO} feature was added in Delphi 10.4.1:
In previous versions (version 10.3 and earlier) of C++Builder and
Delphi developers building packages needed to manually set their
package’s library suffix setting. The DocWiki “What’s new in version
10.4.1” mentions a new IDE projects option for setting the library suffix:
“Package AUTO libsuffix: packages can now have an automatic version
suffix, instead of manually updating and specifying the right version
suffix with each new release. (The compiler quietly supported this in
10.4, but full support for the feature in the IDE and package project settings is introduced in 10.4.1.)”
First of all I would like to apologize for the question itself. I simply could not make anything better. Well, the question then follows with examples and detailed ...
I manually installed QuickReport Delphi 2006 from their sources. It is composed of two packages a "DesignTime" and a "RunTime".
My Delphi is configured to build the BPL files in "D:\BPL" and DCP files on "D:\DCP" for all packages compiled on my Delphi
The source code of QuickReport are in "D:\QuickReport" and their packages (design and runtime) are configured to save the compiled units (DCU) in the folder "D:\QuickReport\DCU." This was the only configuration done in the packages. Nothing is set up with different paths and, BPL and DCP files are placed correctly in the folders I've set up, as I mentioned earlier.
With these settings I was able to build and install QuickReport without problems (just a few compiler warnings, which I believe are normal). All QuickReport components appear in your palette in Delphi, which does not emit any error on start proving that the components are properly installed and all packages were found.
Now comes the test: I started a new win32 application, completely empty, just a blank form. Then it put a QuickReport component (TQuickRep). The first thing I noticed was that the unit "QuickRpt", which is automatically placed in the clause "uses" of the "interface" is underlined in red indicating that something is wrong.
When I perform a CTRL+ENTER in "QuickRpt" unit (uses clause), the Delphi finds the source file (.pas) correctly, which is in "D:\QuickReport" then I ran a BUILD ALL command and the following compilation error appeared:
[Pascal Fatal Error] Unit1.pas (7): F2051 Unit QuickRpt was compiled with a different version of QRExpr.TQREvElement
That's it!!!
This error is only happening with Quick Report. I have other third-party components installed using the same configuration as the paths and they all work properly.
Finally I was able to solve this problem. #RRUZ and another friend gave me the tip: An lost QuickRpt.dcu file on my system. There were a QuickRpt.res file also. I found them, but the place was very improbable to me: The delphi LIB folder!!!
Well, i have some clues about this bizarre thing.
Until Delphi 7, the QuickReport was shipped together with the IDE however, it was disabled by default. On that Delphi version, all we need to do is to register the bpl to gain full access to QuickReport!
On Delphi 2006, the QuickReport is not part of IDE and there are no BPL to register, however the guys at Borland forgotten to remove all files from the old QuickReport. The Delphi Lib Folder is one of the first folders to be checked on Delphi start, so, if there are old files there, new files on another place would be never compiled, generating the annoying error!
This problem may be present on Delphi 2005 too.
Since Indy is now built-into the install process of Delphi 2009... is there a proper way to 'remove' it so it can be upgraded to the latest from the SVN repo? There isn't an automated option to remove it as far as I'm aware.
The dcu files for Indy are stored separately from the other Delphi units. To stop using them, simply remove that directory from the search path, library path, etc., and remove the source files from the browse path.
You can remove the design-time packages the same as any other design-time packages. Remove them from the IDE configuration, and then delete the bpl and dcp files. (If you just delete the files, you may get errors when you next start the IDE since it won't find the expected files.)
Once the Indy components no longer appear on the Tool Palette, the packages no longer appear on the package list, and compiling a project that references Indy units fails with a "can't find used unit" error, you're ready to start installing the latest version.
As Rob already said: Just remove the direcories from Delphi's configuration. An additional step is required though: After each update, make sure they have not been added again! Some of the Delphi 2007 updates apparently did that and I missed it for quite a while until I stumbled upon a bug that I already thought fixed.
I didn't use Delphi 2009, but in older versions of Delphi the installation of Indy components was optional. So you could try launching the setup for Delphi 2009 and see if there is an option to "Add/Remove features" or something similar and use it to remove Indy.
Also, you can customize which packages should be loaded in a project, so you can simply deselect the Indy 10 one and add the one from SVN on a per-project basis (you can also configure the default configuration for projects).
PS. Indy rocks! :-)