For the basics, please refer to this document.
We'll start by compiling and installing the components that HeidiSQL depends on and then HeidiSQL itself.
HeidiSQL has one directory named "packages" for each component and for HeidiSQL itself, this is where you'll find the project files.
Delphi has a distinction between "design-time components" and "run-time components". To compile HeidiSQL correctly, the designtime components that it depends on needs to be "Installed" into the Borland environment, otherwise Delphi will fail to compile HeidiSQL. You can Install a project by right-clicking the project in the "Project Manager" in Delphi and choosing "Install".
Open these projects in Delphi 2007 and perform the action listed.
Note: Before you can install components into the IDE, you will also need to either (a) copy the generated BPL files from the build folders to somewhere in your path, or (b) add the build folders to your Delphi PATH environment variable override. The override can be found under Tools --> Options --> Environment Options --> Environment Variables.
| Relative path | Action |
|---|---|
| components/edbimage/packages/delphi11/EDBImage.groupproj | Build All + Install "DCLSer" |
| components/tntunictrls/packages/delphi11/TntUnicodeVcl.groupproj | Build All + Install "TntUnicodeVcl_Design" |
| components/synedit/packages/delphi11/SynEdit.groupproj | Build All + Install "SynEditD" |
| components/zeosdbo/packages/delphi11/ZeosDbo.groupproj | Build All + Install "ZComponentDesign" |
| components/heidisql/packages/delphi11/HeidiComponents.groupproj | Build All + Install "HeidiComponents" |
| components/virtualtreeview/packages/delphi11/VirtualTrees.groupproj | Build All + Install "VirtualTreesD" |
Once you're done, you are ready to compile HeidiSQL itself:
| Relative path | Action |
|---|---|
| packages/delphi11/heidisql.dproj | Build All |
You should end up with a "heidisql.exe" binary in the "out" folder.
Ta-ta! We're done ;-).
Once the initial build and installation process is complete, please refer to this document for more information regarding consequent building of the project.
You might have forgotten to Install some of the components.
First, make sure that you choose "Cancel" in this dialog! If you do not, BDS will make devastating changes to the source, and you'll need to revert those actions (fx. with SVN) before things are going to work again.
Go back to Getting started, and remember to Install the components where it says so ;-).
If you still have problems, you can also opt to start over.
Remove the (already installed) component by going to Project --> Options --> Packages, selecting the relevant component and clicking "Remove".
Then try installing the component again.
Once you've successfully installed a design-time component, Delphi should reinstall it the next time you compile the package containing the component.
Nuke all files in your package output directory, eg. "%ALLUSERSPROFILE%\Documents\RAD Studio\5.0\Bpl"
Then repeat the above step.
If the HeidiSQL build process has changed, or you think you might have done something wrong during building, you might want to clean your build environment. You can do like this:
HKEY_CURRENT_USER\Software\Borland, or perform the next three steps:
Now you can restart your build process.
If you get this error while building any component, nuke all files in the "build"-folder of the package which causes the problem, then try to recompile.
At least for me that worked as I couldn't build the ZComponentDesign-package
and got this message:
ZPropertyEditor.pas: E2225 Never-build package ZComponent must be recompiled
It seems that especially the file ZPlainMysql.inc in the package ZPlain is affected by this phenomen. This is a bug in BDS which has been reported in 2004, closed for version 10.0.2097.6343. See also http://qc.borland.com/wc/qcmain.aspx?d=9783: Charles Pope: (...) It looks like Error Insight is performing some kind of file locking preventing the compiler from being able to access the file. (...)
Workaround:
(Note: "a component" in this context equals "a project".)
Designtime components are meant to provide functionality to the Borland environment. For example, a designtime component often has a procedure named "Register", which will install the component into the Borland environment.
The idea of separating designtime and runtime is that designtime code does not need to be linked
into the final executable, thus saving space. See this article for details:
http://community.borland.com/article/0,1410,27717,00.html
If in doubt, you can always choose "designtime and runtime". If you do designate a project as being "designtime only", but some code is really required at runtime, the linker seems to be clever enough to include the component in the final executable anyway.
Runtime components are meant to be included in the final executable. Runtime components can probably not be "Installed" into the Borland environment. Runtime components can be compiled into BPL files, which is a sort of fancy DLL.
You can Google for more information about components here:
borland.public.delphi.vcl usenet groups
borland.public.cppbuilder.vcl usenet groups
I have no clue. If you find out, please update this readme.
Supposedly, one can use textual RC files instead of binary RES files, and by adding the RC files to
a project, Delphi should compile them into RES files on demand. That's probably what we should do.
(Hint: Delphi comes with two resource compilers, brc32.exe and brcc32.exe. The Delphi compiler can be called with --drc to generate text resource files at compile time (?).)
While this file is a simple windows-bitmap (.bmp) with 256 colors, one way is to use "Paint" from within the Windows accessories - it has everything you need for this task. But obviously design-people would prefer a more powerful software like Photoshop or something similar. However, a good and free alternative for beginners and intermediate designers is Paint.NET.
You need to put yourself in the shoes of a newbie, and make sure that the method you're proposing actually works.
Finding a source line from a memory address is useful when a runtime exception occurs while the development environment is not running, for example on a user system. There are two methods to translate to a source address given a memory address, they are listed below.
For either method to work, Delphi must be able to find a map of memory addresses and function names. With the correct project settings, these are automatically generated when the project is compiled.
When debugging a problem, first svn update to the revision in which the problem occurred. Also run the build_everything script so that the binaries and map files are generated.
Activate the "Modules" window by selecting View -> Debug Windows -> Modules from the main menu.
The Modules window seems functional, but is completely empty (and thus useless) until you actually start the program. Only then will the relevant procedure names and addresses be filled into the otherwise void window. No error message is shown, so you need to know that the program must be started for this feature to work correctly. If modules are loaded on demand, it may also be necessary to progress to a certain point in the application, for example by opening a connection profile.
In here, you can find the method responsible for an exception from a long list of methods. First click the "Base Address" header to sort by base address. Then select the module with the base address that is closest to, but not higher than, the memory address you're seeking. A list of entry points on the right-hand side gets filled. Select the "Address" header in this list to sort by address. Now, from the list of entry points, find the function by looking for the closest match that doesn't exceed the memory address sought.
Activate the "Disassembly" window by selecting View -> Debug Windows -> CPU Windows -> Disassembly from the main menu. In the default configuration, the CPU window also pops up when the program is paused. In that case it may be enough to simply pause the running program to show this window.
Before the Disassembly window can be shown, the program must be running, suspended and attached to the IDE debugger. This can be accomplished by running the program from within the IDE and pressing the "Pause" button.
Make sure that names of procedures are printed in the Disassembly view. This is enabled by ticking the "mixed source" menu item in the context menu that pops up when you right-click inside the Disassembly window. Note that it is easy to disable this by accident by pressing CTRL-X.
The Disassembly window contains a "go to address" function, which is activated by right-clicking inside the window and choosing "Goto Address" from the context menu that pops up. Enter an address in Pascal hexadecimal notation, for example $65C6DB, to scroll to the relevant memory address. Make sure that "mixed source" is enabled (see above). Browse upwards in the disassembly view until a function name along with a line number is visible in the Disassembly view. Double-click the line number to go directly to the source code file.
There are two methods to do this. One uses "svn update" purely, the other uses the automatic merging feature in Subversion.
This is the old method, which was required before Subversion supported automatic merging.
Historically, we've used the method above to update vendor code. Since version 1.5, Subversion now supports automatic merging. We can use this if the project is updated to have a vendor branch. In this example, the vendor branch will live in a folder named /3rdparty/ in the repository.
In order to keep version numbers in the repository and the released executables in sync, it is important to perform releases using an established method.
Note: All steps are important!
Note: Order is important!
Todo: Extract the sed code that alters %WCVER% from build_everything.cmd and put it in a separate file. Run this file in a post-compile step whenever the HeidiSQL project is compiled.
Revision of this file: $Rev$
Last changed: $Date$
Last author: $Author$