4

I have a copy of Delphi 6 and a simple email program that uses the Indy TIdMessage component. I want to remove lines 464-465 of IdMessage.pas then recompile the application. I'm having a hard time finding clear documentation, so I tried these steps to modify the component:

  • opened \delphi6\source\indy\indy.dpk in the IDE
  • double-clicked IdMessage.pas in the Package window
  • edited IdMessage.pas and saved the file
  • clicked "Compile" in the Package window
  • clicked "Build Indy" in the Project menu
  • clicked "Install" in the Package window

But then I get an error that \bpl\indy60.bpl can't be loaded because \bin\indy60.bpl is already loaded. So I tried "Install packages..." in the Components menu, but only found \bpl\dclindy60.bpl there. So I removed that package, and:

  • opened \delphi6\source\indy\dclindy.dpk in the IDE
  • clicked "Compile" in the Package window
  • clicked "Build dclIndy" in the Project menu
  • clicked "Install" in the Package window

The IDE confirmed all the components (including TIdMessage) were installed, but the email program is still acting as though the original unmodified component is still being used.

What am I doing wrong?

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770

1 Answers1

5

if you were using runtime packages then you'd need to ensure that your program found the new package file, the .bpl.

But you probably are not using runtime packages. So the runtime program statically links the Indy code using .dcu files located in the Delphi installation folders. Specifically in this case to <ProgramFiles>\Borland\Delphi6\Lib\IdMessage.dcu. You need to make sure you link the new code. The easiest way is to add the modified file to your project. That will mean that the modified version gets compiled and linked into your program.

Since your modifications are in the implementation section of the unit this is all you need to do. If the modifications were in the interface section you'll encounter "Unit X was compiled with a different version of Unit Y" errors. You'd solve that by adding the rest of the Indy source to your project.

One point to stress is that you should never modify the files under the Delphi installation folder. If you want to build modifications to those components, take copies of the files and make modifications in those copies.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Correct, no runtime pkgs. Separately linking a modified copy may be easy, but then I'd have 2 versions of the source to be aware of: the original installed buggy one + my uninstalled fixed version. Isn't having library source intended to allow bug fixes + reinstalls of corrected components? Those compile/install buttons are expected to be used 4 new components only? Isn't some variation of my steps able to replace the libs? What did my steps actually change + why did they fail? I'll try your solution, but what do the library creators actually do to update files as they develop these packages? – Witness Protection ID 44583292 Dec 07 '12 at 08:53
  • "What do the library creators actually do to update files as they develop these packages?". They check out the source from the repo, build it, modify it, and then commit changes. Just in the same way that you do with your code. – David Heffernan Dec 07 '12 at 08:57
  • As for having two versions of the source, that's exactly what you want. If you modify the copy in the Delphi installation directory, what happens when you need to reinstall Delphi? You'll lose your modifications. You put your modified version under revision control. You are using revision control aren't you? – David Heffernan Dec 07 '12 at 08:58
  • 3
    @mike: I am one of the Indy library developers. While I'm developing Indy, I completely remove all pre-installed Indy files, and reconfigure the IDE to point at my development files. But that is just my choice, it is not a requirement. You can either replace the pre-installed files with your recompiled files, or you can leave them intact (in case you need them) and just redirect the IDE and/or individual project(s) to use your separate copy. – Remy Lebeau Dec 07 '12 at 10:29
  • @Remy Lebeau: Are you saying that for a lib developer to fix a minor err in one .pas after the assumed-correct lib is installed, you simply replace the .pas/.dcu files (with 1 .dcu for the non-debug bin folder & 1 for the debug folder), & the .bpl/.dpk/etc stuff that was originally created can be ignored & left as-is? A lib developer can't simply edit a .pas file in \source\ & use some combination of steps like I tried, to make the IDE rebuild the installed lib? If not, it's weird for the Package window to have compile/install buttons, project options, etc., but not for use after installing. – Witness Protection ID 44583292 Dec 07 '12 at 17:12
  • @Remy's advice is good if you don't use the new DataSnap, which is based in Indy. If you use it, you have to know that DataSnap packages depends on the interfaces of Indy's packages. As Indy tend to introduce breaking changes in interfaces at any time, you may end with a broken Delphi if you just remove the pre-installed Indy files without first keeping a backup copy, just in case. Take a look at: http://stackoverflow.com/questions/4567127/is-it-possible-to-use-indy-10-5-8-0-in-delphi-xe-and-datasnap – jachguate Dec 07 '12 at 17:13
  • The library developer won't be rebuilding IDE packages routinely. They'll just be building programs like any other developer. – David Heffernan Dec 07 '12 at 17:15
  • @mike: as long as you are only changing the `implementation` section and not the `interface` section, you can replace the .pas/.dcu files and they will be used only by projects that have Runtime Packages disabled, so the .bpl file will not be used. If Runtime Packages are enabled, the .bpl has to be recompiled, which then requires everything using that .bpl to also be recompiled. – Remy Lebeau Dec 07 '12 at 18:06
  • @jachguate: that only applies to Indy 10 in D2009+, and is documented on Indy's website. Mike is using Indy 8 in D6 instead, which doesn't have DataSnap. – Remy Lebeau Dec 07 '12 at 18:08
  • @Remy I'm just warning the casual reader of your comment, as they may read it without being aware of the specific versions. I tried to be clear in my comment, but thanks for the clarification. :) – jachguate Dec 07 '12 at 18:18