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.
Related
I am supporting some legacy Delphi project. This project is divided into modules that stored in DLLs.
I need to compile one of the modules (last compiled in 2007). This module uses module DualListBox and has a variable of type TDualListBox:
uses DualListBox ....;
...
lbMasterOrders: TDualListBox;
lbChildOrders: TDualListBox;
The problem is, I don't know where to find module DualListBox. I can't find it on my machine, and I can't find it on the internet.
As far as I understand, the TDualListBox component must be something like ListBox that can Add rows at runtime.
At first, i thought that DualListBox is a part of RxLib, but RxLib's component is called DualListDialog and it's something completely else.
So maybe this is the self-written module by prev developer, that was deleted somehow.
But somehow the compiled DLL (that was comiled in 2007) is working perfectly fine. Maybe I can investigate where to find that module by decompiling that DLL?
If so, where should I look in the decompiled project? I'm using DeDe for decompiling.
The unit is called duallist and is automatically generated by Delphi 2007 (and also Delphi 10.1 and 10.2, don't know about other versions, but I would be surprised if they didn't have it) when you open a VCL project and click:
File
New
Other
Delphi Projects
Delphi Files
Dual list box
These units are usually taken from the object repository, which by default is located in the ObjRepos subdirectory of the Delphi installation.
I need (to make some quick and dirty tests) to modify the code of Variants and SysUtils.
What I need to do to "compile" the changes?
I can of course open those units in the IDE, but if I change them and I buoild a project again I don't see those units recompiled.
What is needed to be done?
The problem is you would need to compile ALL of the RTL/VCL against the 'new' units.
Instead modify a copy of the units in question and add them to your project when you want to use them. Delphi should use these over those in the RTL/VCL.
Unless you do not change the interface part of the unit (that is, you only modify the implementation side), you can make your own version of the RTL units (only exception is System.pas and SysInit.pas, but this is not in your scope - see our blog site for some enhancements of those units).
What you need is to put your own version of Variants.pas and SysUtils.pas in the search path of your project. They will be taken in account instead of the default RTL.
But be aware that you may easily break anything.
For testing purpose, this is OK, but if you want to use those modifications, you shall better use some automated regression tests, and know explicitly what you are doing.
Please note that you can use the "debug" version of the RTL units (from the project options), then step with the debugger within the official source code. It may help finding issues without touching the source.
If you change the interface part of the unit, you'll have to recompile all units which call the modified unit - for SysUtils and Variants, this is almost all RTL.
Delphi runtime DCUs are precompiled. It would be a waste of time to compile them at every build.
If the code you are trying to modify is a method of a built-in class, then a class helper may help:
http://docwiki.embarcadero.com/RADStudio/en/Class_and_Record_Helpers
So the question is which part of code do you want to modify in the runtime?
If you really wish to recompile the RTL you can do so (Make a backup first!). Versions of Delphi prior to Delphi 2010 had a makefile in the source folder that could be run from the command line to rebuild the rtl/vcl. I don't know for sure (I'm still using D2009) but from what I've heard this file is no longer present in newer versions. Hopefully there is an alternative. Otherwise you would wind up wasting a lot of time trying to guess that the compiler settings for each unit.
If you wish to "patch" a bug in the rtl for your project only you can copy the unit you want to modify into your project's folder and make your change. If the unit your modifying is used throughout the RTL/VCL you may find yourself copying quite a few dependent units into your project folder in order for it to compile.
If this significantly slows down the compile time for your project you can always do your initial compile then remove the "patched" units, leaving behind the compiled dcus.
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 :-)
I have been away from BCB for over five years, and now I am having a st00pid n00b moment.
I am using BCB, and using a VCL component package for which I have the Delphi source.
I want to comment out a few lines in the Delphi source of the component (to not add a few toolbars in a form's OnCreate()).
So, I comment it out, and the syntax highlighting shows it as a comment. I build my package, just to make sure it gets recompiled and my out-commenting didn't work.
I breakpoint on the line before, step and the code which is commented out in the edit is executed (as if it is picking up an old OBJ ?).
What's my checklist here?
The answer will be awarded to whoever leads me to that D'oh! moment. Thanks
Well you're obviously linking to old code. You'll need to figure out what you're linking against and fix it.
Does your application list the Delphi package in it's "Build with runtime packages" list? If so, you're linking to the code in the delphi package, re-build that. The file you're interested in is the "BPL" file (that's the file you need to rebuild). Sometimes packages automagically build themselves (if they're marked as "Always Build") - but you're talking about an Delphi package used by BCB, maybe the magic is not that strong.
If you are not linking to the BPL then you're linking to the compiled version of the unit, a DCU or an OBJ, I don't work with BCB so I can't tell. Is the PAS file part of your project? If it's not part of your project then you're using the compiled unit and, as far as the IDE is concerned, you happen to be looking at a text file that has the same name as your compiled file (DCU or OBJ). Add the file to the project!
Is BCB actually capable of compiling PAS files? If it's not then you'd need to compile the PAS file using it's native compiler (Delphi). Maybe you've got a C++ only BCB that can't compile PAS files? Not sure such a version exists, but then again I've only been exposed to Delphi-only or RAD Studio environments.
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.