as the title says, I'm trying to compile a Win32 program without the aid of an IDE, just so I can learn. I'm using Borland Studio 2006, and my first thought was to take some files generated from a Forms application from the IDE and compile the project file... that gave me errors about expecting unit and finding object instead. I know that's from the dfm file which holds all the settings for a form, but I don't get how the IDE deals with that file, can anyone help me understand the system better? :)
If I have understood correctly, you need to grasp the structure of a Delphi project and how Forms and units work together. You cannot just cherry-pick some files and expect to be able to feed them to the compiler.
You also have to set the path to the library/components/used files so that the compiler can find everything it needs, starting with the project dpr.
I would recommend that you try first to run your project from the IDE, then once it runs, you can try it from the command line.
I found out all I needed to do is compile the top level unit into a dcu, and then the project will compile :) If anyone else is trying to do the same thing, there's some great info at the bottom of this page
http://www.codexterity.com/raw-delphi/index.htm
WANT automates the process of building, testing, and packaging applications and libraries much like Jakarta Ant does
You wrote in question that you are using BDS 2006. If you want to learn more recent build process in Delphi I suggest you to upgrade at least to Delphi 2007 which introduced MS Build usage.
Of course MS Build acts like "wrapper" so this is not must have but nice have :-)
Related
It seems that C++ builder 10.3. comes with a new testframework.hpp. The class Assert does not exist any longer.
Can anyone tell me how to use this new framework?
I am desperate because I wrote a lot of code and obviously Rio is not really compatible.
for example the following code line, written in Builder 10.2.3, doesn't work any longer:
Dunitx.Testframework::Assert::IsTrue (result == true);
I found the solution in the testframework.hpp - file. The usage is now a lot easier but you will have to know how to handle it. The description in the embaracdero help system is wrong and should be corrected.
You seem to have found the TestFramework.hpp for DUnit. But it is obvious your code was using DUnitX before. These are similar but incompatible test frameworks.
To get the Dunitx.Testframework.hpp you need, simply add DUnitX.TestFramework.pas to your C++Builder test project (add it in the project manager) and completely re-build your project. The Pascal compiler will generate the necessary .hpp file for you.
But before you do all that, you may want to copy your project to a new folder, and load it from there, just to be sure. That way, the older project will not be modified. Be sure to update all your paths in the project manager and C++ library settings too, if necessary.
If you think DUnit is easier to use (I certainly do), then keep on using that. But you will have to rewrite some parts of your tests. More info can be found in the Delphi help files (and on the web counterpart) and on the DUnit website.
DUnit was the former test framework for Delphi (hence the D), but at some time in the past, it was replaced by the more modern DUnitX. But that uses some Delphi features (like Delphi attributes) that make it harder to use in C++Builder. DUnit is still part of the RAD Studio installation.
I decided to have a concerted effort to get the excellent DWScript (Delph Web Script DWS) integrated into a simple IDE using SynEdit. DWScript is currently being agressively developed and has a number of advantages over other Pascal Script libraries, however it does not contain an editor or any IDE example beyond a simple memo control to prove execution capability. It does contain a number of hooks for editor / debugger integration and in fact when DWS was reawakened a while ago, releases did contain an example of a SynEdit / DWS2 (as it was then) integration. An example can be found in the file dws2src20-20030907.zip in the \dws2rel\dwstools\idedialog\source where there is a 'mini-IDE' with editor window, call stack, breakpoint window etc. Really nice. I did get this working some months ago using an old SynEdit and the DWS2 that was included in this file.
So, I have now tried achieve this (or a similar) ide using the latest SynEdit (downloaded from SVN) and the latest DWScript (also from the SVN). Both libraries are installed fine into XE and their demos run fine. I then tried taking the ide example from the old "\dws2rel\dwstools\idedialog\source" and updating the code but much has changed. Frustratingly, not so much has changed that I gave up quickly - I tried searching for the various 'old' type definitions in old source and matching them up with 'new' definitions. Finally though, after several hours mired in code I decided that someone, somewhere must surely have been down this route?
Has anyone got an example of a DWScript - SynEdit integration using recent DWScript code please? I'm very happy with something simple that I can learn / build upon.
Thanks
SynEdit component has received little maintenance, and even some projects as Inno Setup have changed to Scintilla, Inno Setup is not using DWS but the code can serve you as a basis for new IDE
Dws have a editor on the demos with debuger and remote debuger just download all versions of dws one
I'm porting a app to FreePasal/Lazarus & found that their form converter is not good. I have a small utility app, and each time I do a change I need to reconvert, relayout and reimport graphics. Plus, some things are messed up.
I wonder if exist a automatic tool for convert the DFM files to delphi sourcecode, so I can do this more easily. Is not problem if the sourcecode is not FPC compatible.
The free GExperts plug-in has a "components to code" feature. Install it in your Delphi IDE and open the form you wish to convert. Select the components and invoke the command, and it will place equivalent creation and initialization code on the clipboard for you to paste wherever you need it.
Updating to trunk versions of both Lazarus (0.9.29) and FPC (2.5.1) might also be a solution.
Several things have changed:
last month sb started working on the converters (Juha)
FPC 2.4+ bring the resource handling closer to Delphi (no more .lrs)
We recently converted our long-running Delphi project to Open Source. Multiple people have contributed patches already, which is great, but unfortunately forms and frames when saved with Delphi 2006 (and later) contain new properties in the .dfm that are not handled by older versions. Forms are handled quite gracefully by the IDE ("ignore propery?"), but frames are loaded at runtime and result in errors. Not an option, as far as I'm concerned.
I now removed those properties from the .dmf files by hand, but I am really wondering if there is a more elegant solution. There is no way to save in a backwards compatible format from the new IDE's, is there? Are there existing tools to strip the nonsupported properties from the .dfm's ? Any other elegant solution I am missing?
Normally, with a commercial project, I'd just upgrade the project to the most recent version applicable... but as this is open source I really don't want to loose out on those developers still working on Delphi 7. That includes myself, actually.
The JEDI JVCL project uses a little utility dc.exe (delphi cleaner) and a list of properties in DFMs that are not present in older versions of delphi, mine contains the following text:
*.PopupMode
*.PopupParent
*.ExplicitLeft
*.ExplicitTop
*.ExplicitWidth
*.ExplicitHeight
*.BevelKind
*.BufferDocument
*.DoubleBuffered
*.ParentDoubleBuffered
*.DisableHyperlinks
*.AlwaysEnquoteFloats
*.PixelsPerInch
I run this dc.exe utility from a batch file which cleans my dfms before I commit
changes to subversion. The syntax in my batch file for this is:
dc.exe -s -fd10.txt *.dfm -i
You can grab my stuff at:
http://sites.google.com/site/warrenpostma/files
You can try Andy's DFMCheck. It can automatically open and close all forms and frames in a project, which makes the IDE remove unknown properties (as Marco wrote).
Well, for sake of completeness:
Open the dfms in the oldest Delphi supported, let it remove all unknown properties, change a property and save.
For your purposes, Warren's solution is better, but it can be a workaround. I did it for a while when we were dual D7-D2006ing.
How can I increment version in project files for delphi projects.I am using Delphi 10 for win32 application development. I consists of bdsproj, dpr & res files for a project.
If you are using delphi to build your application, you can turn on auto-incrementation of buildnumber under projectsettings.
We use a self made utility to generate a version resource (rc-file) based on values in a ini-file. Then we compile the rc-file into a res-file, that we include in the project.
We use finalbuilder-scripts to automate the process. I know finalbuilder has its own support for versionnumbers, but we don't use it. I don't know why, though...
I previously used a program called StampVer, You will need to already have version information in the file to use StampVer. StampVer is Freeware but not Open Source.
The nice thing about stampver, is that it can auto-increment for you.
I use a proper build script tool FinalBuilder which has a set of property management commands which can set all items in a build to the same version. This gives me consistency of numbering across a build, and a whole load more too. If you don't have a proper build tool, and are still using batch files or equivalent, now is a good time to go look at the options. Well worth doing.
I use a program that manages the version number in a .ini file and generates a .res file in the pre-build event of the project. This .res file contains only the version, not the icon. The icon is contained in a separate .res file. Both are being included in the project's dpr file:
{$R *_version.res}
{$R *_icon.res}
Only the *__i_con.res file gets checked into source conntrol, the version, as said above is maintained in an .ini file, so the *_version.res file can be generated whenever necessary. This gets rid of the annoyance of the .res and .dproj file constantly changing due to incrementing the build number.
Oh, I just realized that you said "Delphi 10", which I think is Delphi 2006. That Delphi version did not have pre- and post-build events, so you would have to call the program for maintaining the version yourself.
Read this article http://www.thedelphigeek.com/2008/01/tdm-rerun-2-better-build-process.html
by Primoz Gabrijelcic, originally published in The Delphi Magazine. It contains a complete description on what you need to do.
If you are looking for a non-gui way of doing this then I think if you look in the bdsproj file you will find a section in the xml where the version is written you can change it here. The next time it builds it will use this version.
DDevExtensions has a build incrementer in it, I'm not sure how to get the delphi 2006 version, but I think it exists and it's pretty handy stuff.
Do you need to increment the build number when you compile from the IDE, or outside? The IDE can increment it automatically, just check the flag in the project settings.
Incrementing that number outside the IDE is not simple because it is stored in the default .res file which is managed and regenerated by the IDE.
The command line compiler will not modify it. There are several ways to modify it (as other answer explain), and usually it works best with a build system that can generate the build numbers, especially if more than one developers work on the project.
I posted QC #70564 issue to ask that version info can be set by the command line compiler.