TurboPower LockBox: how to install - delphi

I have download this component and trying to install but,
It is asking too many questions for the installation to continue :(
How do you answer to these,
BPL/DLL output directory?
Include (.inc) directories?
Delphi XE DCU output directory?
Delphi XE DCP output directory?
Delphi XE EXE output directory?
Is there any quides available for installing the component?
thanks in advance

Apparently the LockBox installation cannot read this information from Delphi. You can find the settings in Tools->Options.
The path settings are under Environment Options->Delphi Options->Library.
There you find
- Package output directory (= BPL/DLL output path)
BPLs are special DLLs (packages) that are installed in the IDE. They contain the components.
- DCP output directory (DCPs are used with BPLs when they are installed in the IDE).
You can also choose your own directories, as long as the directory is specified in the system PATH environment variable.
The .inc-directory can be left empty in the installation.
The DCU output directory is for saving the DCUs (compiled units) of the package. You can choose this directory yourself. DCP path, I explained above.
I'm not sure about EXE output directory, but maybe it is used to compile the demo applications too.
It is indeed a little vague to say the least. At the end of the installation, you'll find a link to a feedback forum. Maybe you can share your findings there, so they may improve it in the next version.

It's really simple.
You can just leave all these fields empty, and the defaults will be picked up.
Alternatively you can just deselect the automatic compile option. The installer will then just install the source code, and then you can compile and install by hand. There is a read-me file providing guidance for just that.

I advice you to kindly ask someone proficient in InnoSetup to pack it for you. Unfortunately, I do not have a good command of if but I know it works.
Last edit :
As of version 3.4.1 released on 12-Nov-2011, TurboPower Lockbox was distributed as a good binary but still requires some fair knowledge of package installing.
Please see TOndej's answer to How are Delphi 'environment variables' such as $(BDS) evaluated? for indepth details.
Packing into an alternative binary distribution adressing the expansion of Delphi IDE environnement variables ($(BDS) and the like) may save users from troubles by hiding some complexities.

Related

Delphi component install issue

After installing a SVN version of graphics32, I cannot see the components in the ToolPallette. (Windows 8.1, Delphi XE)
I mean, I see the group Graphics32, but it's empty.
When I navigate to see Installed Packages, I see the package there, it's checked... and when I click on it, and then click on the "Components" button I can SEE the components, but again, on the component pallette they are not visible.
So I am having problems adding those components to my form.
I just upgraded from version 1.9.1 to version 2.0 (beta) from the SVN trunk because I need functionalities from the latest version, but I have problems installing it correctly.
Please help
Thank you
EDIT
After compiling and installing the library, I copied the dcu`s and the pas files to Delphi's folder in program files (Release and Debug), because that is what I do with all my components so I don't depend on later folder changes.
Graphics32 does not come with .dproj files, so you might have to do some adaptations regarding component installation / setup yourself. The reason why these file types are not included can be found here.
If you open the .dpk files in the IDE (for recent Delphi versions there are runtime and designtime packages) you can of course build and install the packages right away. The designtime package need to be installed otherwise they won't be shown in the IDE. It should show something like "Package [..]\GR32_DSGN_RSXE1.dpk has been installed". If you have not removed previously installed GR32 packages before you should also get a text for all the new components now installed.
To actually use the components in a project you need to have either the source files or the dcu files be found from Delphi. As mentioned in the comments before this can either be the library or the search paths depending on what you want. For a better explanation see this question here on stackoverflow.
In short and as mentioned by Stefan Glienke in a Google+ post you shoud not put source files in your library path as it will cause the files to recompile each time you compile your project.
Instead, you should take some time configuring the packages options in advance (before building / installation) to put the DCU / DCP directly into a place where it can be used. For example you can put something like
....\Lib\XE2\$(PLATFORM)\$(CONFIG)
into both packages 'Output path for units' AND 'DCP output path'.
Now after build/installation, just add the path specified there into the library path. In addition you can put the source path into the search path, so that a [CTRL] + Click will find the code as well.
The advantage of this is that the library will be used with the package options, which might differ from your project's options.
As said, other ways are possible here including installing the components directly into a global library path.
This might not explain why the components are not visible in your project, but maybe you should just remove the existing packages (delete them from the list, not only uncheck), restart the IDE and reinstall the packages as mentioned above.

How to explore the symbols of a dcu files in Delphi IDE?

We know that the specification of Dcu files is a secret and it will be changed every version. Is there ANY POSSIBLE way to explore the symbols in a dcu file in Delphi IDE? (Instead of using a decompile library such as DCU32INT project.)
Here is an attempt using Delphi7, and there exists a DCU32INT utility by Alexei Hmelnov.
Reverse engineering only the DCU might be difficult, but inspecting the executable might help.
Someone tried IDA, and an 'IDA Loader for Delphi/Builder 32-bit units (.DCU) by RedPlait with source' is mentioned here, Googling it I found this.

Delphi package install error - DCU not found

I am trying to install a Delphi package from the VST SDk, my problem is that it says a .dcu is missing.
The .dcu is not missing, and before installing the package, it doesn't exist, but is created by the
IDE during the installation, so it's not precompiled from a former version of Delphi. The .pas file doesn't appear to be incomplete. All the other files appear to be installing just fine, this however is giving me a great load of trouble. I hope someone might help me :)
Im using Delphi 2010 btw.
Thanks in advance :D
Image showing my files and errors
Here's the SDK - im using 1.3
The problem is that the compiler cannot find the source files, or the dcu files.
There are several ways to solve this.
You can add the paths that contain the .pas files to your library, via /tools/options/EnvironmentOptions/DelphiOptions/Library/LibraryPath
You can add the paths to the search path of the project.
In the project options (ctrl+shift+f11)
You can add each file that you need to the project. shift+f11
Note that you can also point to the folder that contains the .dcu files, but that means you wouldn't be able to step through code when you're debugging.
I usually use method 1, because that settles it for all future projects that you use in this IDE. It's convenient if you create many projects that use the same library.
Some other people like to specify this per project, so that they have full control over the dependencies of the project.

Solving Delphi BPL Package problems where BPLs won't load but you've already recompiled (Windows VirtualStore filesystem issue)

My general question is how do you troubleshoot "My BPL won't load due to a dependency that just won't go away, no matter how much I clean up and recompile". Update You may think you have a clean recompiled system, but thanks to the inverse-miracle that is Windows and its file system virtualization mis-features, you haven't.
When I try to load my designtime package (in this case named dclFsTee.bpl) into my Delphi IDE (it's the fast report 4 teechart wrapper component package), it complains:
The program can't start because tee7100.bpl is missing from your computer. Try reinstalling ...
That tee7100.bpl is not referenced on any DCP or DCU file on my system THAT I KNOW OF. But clearly, something is wrong, and I can't find the problem.
All Delphi users face a hundred "won't compile or won't load" problems with BPLs. The universal refrain when asked what to do is to clean up your computer.
However, I've now spent hours cleaning up my computer, and while everything compiles file, clearly there must be something out of date hiding somewhere, because the resulting BPL file that I'm trying to load still wants to load a version of a TeeChart BPL that I removed from this system days ago, along with every trace I could find.
The traces of TeeChart stuff in Delphi 2007 that I removed include everything in the $(BDS)\Lib and $(BDS)\Lib\debug folder, and all DCP and BPL folders on the system. Also every TeeChart-unit-named dcu file is gone.
Once you've gotten to the end of the road, what do you try next? (Format the hard drive, buy new computer.) Seriously. I think I'm a smart guy, but I have a 1 tb hard drive, a library path that runs to 80+ folders, and a source code repository that seems to be well organized, but clearly something is hiding where I can't find it.
I have TeeChart Standard 2012, with full source code, and as far as I know, my development machine no longer contains any old TeeChart BPLs or DCP files from the "tee chart tee7100.bpl" version that ships with delphi.
I have run the "recompile.exe" wizard that comes with teechart, which appears to just run MSBuild and build the packages, after writing a {$DEFINE x} declaration to the tee.inc files (there are two of them in the source distribution).
However, somehow, silently it seems like one of the implicit imports into one of the packages is drawing in some stale file which has not been rebuilt, and which therefore tries to load the tee7100.bpl. The new bpl name is tee911.bpl.
Rather than ask the pretty-specific-to-fastreport question, I'm only mentioning it as a specific instance of a general world of hurt that I have faced dozens of times while developing in Delphi.
I'm only giving the fast-report details so you can see that this is in fact a specific instance of a general problem that one faces sometimes inside Delphi IDE when dealing with a component source code or package, or set of packages, with dependencies. Cleaning up your computer so that your code even builds can be tricky.
So here is my Delphi package-to-package-dependency-resolution question:
What is the most effective way to find or trace implicit-load-of-some-no-longer-wanted BPL-problems so that my code (which builds and compiles just fine!) will actually load into the Delphi IDE. The BPL file that results from running Recompile seems to be linking properly to the right DCP files, and no old/stale DCP or DCU files are present. The new DCP file name is tee911.dcp, for instance.
Can you get somehow, any idea of what package is actually stale, and what is being read and linked and imported statically when the .bpl links? (I'm thinking maybe like a special MAP-like file for BPL files?)
Update After many hours of fighting with this, and using every trick I know, I realized I hadn't checked for some VirtualStore related issues caused by file virtualization in Windows 7. That means that Windows 7 lies to the programs that run on top of it. It gives you another version of the file, that isn't the one you want. This can be deadly in several ways; One; You recompile a BPL but that's not the one that loads. The BPL that was killing me was in the SysWow64 folder that was part of the VirtualStore. Note that the virtualstore basically makes phantom files appear that are only there if you're a certain "low privelege" program, which Delphi 2007 on Win7/64 bit, apparently is. To remove BPL files in your SysWow64 VIRTUALSTORE folder for your current user account:
del %HOMEPATH%\AppData\Local\VirtualStore\Windows\SysWow64\*.bpl
... Some days I just hate Windows architecture. Anyways, I'm not going to put the above as the answer, because I'd like to know if anyone has a better way or any tip or suggestion that might help next time.
Okay nobody else answered so I'll put this here to be helpful for future people:
-- Remember Windows VirtualStore when cleaning up broken systems which have old versions of DLLs on them including TeeChart, FastReport, Indy and so on which tend to be involved in messes because they can exist both as "out of box packages that ship with delphi" as well as frequently installed as upgraded versions if you purchased and installed them from the vendors directly, or third, you may have your own compiled copy in your company's mega-component-pack-directory.
-- When searching for duplicate or out of date BPLs, doing a file search in windows doesn't look in the virtualstores, you'll have to locate and zap the whole virtualstore area for your process or user, or program, manually.
The second level of this issue is this:
The dependency graph for FastReports is complex:
It depends on Indy and you might have your own version of Indy, and Delphi itself has one, and other things on your hard drive might have their own copy of Indy.
It supports various editions of TeeChart, including the binaries that come with Delphi, and perhaps the Standard version or other purchased version of TeeChart that you might have bought from Steema.
It uses a precompiled header include file to do the compilation and not just ONE but TWO different copies of an identically named include (.inc) file.
When you use their own compiler tool (recompile FastReport) it works pretty reliably but isn't the best for when you want to build everything in your project from a single build script, thus the source of my problem.
The key is to learn everything there is to know about the dependencies of all the components in your giant pile of packages, and to organize your system cleanly so that you don't have old stuff (like Indy and TeeChart bpls, dcp, or dcu files) lying around. Cleaning that up is quite a complex job if you don't know what you're doing.
A utility to really remove all traces of the version of Indy and TeeChart that ship with your system, and the "Embarcadero edition" of FastReports is key to getting this situation resolved. A general tip is that "if a version of X ships with Delphi and you are going to install a new version, prepare to suffer until your system is really cleaned up".
A really amazing technique to avoid all this crap is to just not install Indy, FastReport or TeeChart (uncheck them or skip them) during your initial Delphi IDE install, then install them yourself, one by one, from sources. Just because a version comes pre-installed in Delphi doesn't make that a good thing. (Update: You can no longer unselect Indy during install, it's part of the base Delphi product since at least Delphi XE8. A clean-up utility to remove the built-in Indy from Delphi's own lib dirs is necessary for anyone who builds their own.)
Another really amazing technique is to run the Installers for commercial components on a virtual machine, then just collect up the pascal source code and transfer that onto your clean development machine, and build it yourself. That way you can avoid the terrible things that happen when you've got BPLs and stuff scattered around your system, and even installed into C:\Windows\System32 (on 32 bit systems) and C:\Windows\SysWow64 (the equivalent path on 64 bit systems).
put that BPL (tee7100.bpl) under $(BDSCOMMONDIR)\Bpl
for XE: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\8.0"
for XE5: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\12.0"
The other issue that can cause this, is not having the folder where you've stored your .bpl files in your system path.
This happens because Delphi attempts to call the WinAPI function LoadLibrary with a file name, instead of an absolute path. So if Windows can't find the file, Delphi can't load it.
See this forum post for more information.
This seems to be an issue in Windows 7, though not in Windows 10.

Install the latest build of Indy 10 on Delphi 2009 [duplicate]

This question already has an answer here:
Step by step upgrade of Indy 10 in Delphi 2009
(1 answer)
Closed 3 years ago.
Is there a step-by-step guide for updating the Indy 10 components in Delphi 2009?
I've read the uninstalling thread and have the latest build (IndyTiburon.zip). However there appears to be no installation instructions.
If you have accomplished this, please share the details.
Edit: I have managed to get the packages installed by messing with the "requires" section in dclIndyProtocols120 and dclIndyCore120.
Essentially removed all Indy package dependencies from "requires" section and just used the Library path resolve things. Added ..\Lib\Core, ..\Lib\System and ..\Lib\Protocols to the Lib path. Had to leave dclIndyProtocols120 in requires for dclIndyCore120 as it wont install without this.
All 3 packages compiled (including IndySystem120) and seems to be working okay now.
This should be easier for D2009 users. I had to update to resolve an SMTP bug in Indy (see link).
On this question there is a more satisfying answer.
For all versions before D2009 you can use a Fulldx.bat script to recompile the packages and then just open the BPL files in (for example Indy-10.5.5\D6\dclIndyCore60.bpl and Indy-10.5.5\D6\dclIndyProtocols60.bpl) in the Delphi 2009 IDE packages dialog. Now with Delphi 2009, the FullD12.bat is there but it is not doing anything.
My simple solution is to create Indy components at run time only. I add the Indy Tiburon Core, System and Protocols to the projects search path, and also use Apache Ant with a build script to run the compiler for the final build.
One IIRC needs to compile system core and protocols in that order.
Moreover a package is a .BPL and a .DCP. So you probably would have to copy the .bpl and the .dcp to that directory in a normal case. The .BPL is what programs need to run, but to compile something that uses the .BPL (statically) you also needs the .dcp.
But that doesn't work for the Indy caseafaik because it also needs includefiles, so you need to add all their paths to the library path.
IIRC is that Delphi (at least the versions that I know) don't add directories to paths when installed, and one must always add paths to directories with .dcp or .dcu's manually.
(contrary to Lazarus that builds a list of dirs from the installed packages. But partially that is maybe also a fix for not having something akin .dcp yet, and in generally be more source oriented)
Note that I don't have D2009, it is just experience from general manual Indy compilation.
Maybe a simple method for anyone looking 10 years later... (tested under Delphi XE5):
Download the latest Version from https://indy.fulgan.com/ZIP/.
Extract the ZIP-archive into a folder of your choosing (I made a folder "Delphi Lib" under my Documents).
Throw out all Indy .dcu Files (Indy[...].dcu and Id[...].dcu) from your Delphi installation (for Example: C:\Program Files (x86)\Embarcadero\RAD Studio\12.0 (The last folders name may vary on your installation))
Open Delphi and go to Tools -> Options. Get to the "Library"-Listing and add the following folders of your newly downloaded Indy: /lib/Core/, /lib/System, /lib/Protocols.
As always: Help yourself and make backups before deleting anything. You do not want to reinstall your comlete Delphi because you threw away a file you should've kept...

Resources