put your resources in a text RC file that can be compiled through a resource compiler
add these to your Delphi project via the project manager, so it generated RcCompile elements which instructs the build process to run the resource compiler first:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
While upgrading a truckload of Delphi stuff for a client, I came across the IMPLICITBUILDING directive in a few .dpk files that Delphi XE2 sometimes inserts but XE8 doesn’t.
This appears to be a Delphi XE2 specific thing that in younger Delphi versions has been solved properly SolarWind‘s answer on Stack Overflow:
The compiler directives which appear between the $IFDEF IMPLICITBUILDING and $ENDIF are normally passed as parameters by the compiler when explicitly compiling a package. Because these options change based on the configuration (debug / release) and target platform (Win32, Win64, OSX32) it’s problematic to have them statically defined in the package project source. When defined in the project source they will always override the options passed by the compiler. The $IFDEF prevents these options from being used during explicit compilation.
That seems to be a workaround for the problem that compiling packages with the msbuild script ignored all dproj compiler options because they were read from the dpk file by the compiler.
Some more references (I’ve saved them in the WayBack machine as the forums auto-expire posts):
Check out $(BDS)\source\cpprtl\Source\misc\unmangle.c – it contains the source code for the unmangling mechanism used by TDUMP, the debugger and the linker. (C++Builder and Delphi use the same mangling scheme.)
…
This has been around as long as BCC itself. However the file was called um.c instead of unmangle.c in older versions
Nullable<T> = record
… property Value: T read FValue; default;
… end;
Using the default directive to “hoist” the operators of “T“. Currently the default directive only works for array properties by “hoisting” the ‘[]‘ operator. Marking a non-array property with default will make the containing type behave as that type.
This, coupled with some intrinsic compiler knowledge of the Nullable<T> type will make Nullable<T> work without any addition of keywords or other standard functions or procedures.
Using the “default” directive on a non-array property will work for any type, except for having the null-propagation semantics.
When considering language features, I try and not only make it work for the intended purpose, but also broaden reach of any supporting feature. In the above scenario, even user-defined operators on “T” will be properly hoisted and used.
class function TCardinalHelper.Parse(const S: string): Cardinal;
begin
Result := StrToInt(S);
end;
Which means you get this nice EConvertError with message ''4294967295' is not a valid integer value'. with this simple test (which doesn’t even reach the Assert):
uses
System.SysUtils;
procedure Cardinal_Parse_High_Cardinal_Succeeds();
var
Expected: Cardinal;
Value: string;
Actual: Cardinal;
begin
Expected := High(Cardinal);
Value := Expected.ToString();
Actual := Cardinal.Parse(Value);
Assert(Expected = Actual);
end;
So I write some unit tests (see below) of which helpers for these types fail in one way or the other:
program dcc32_F2084_C2359;
type
TNumber = Int64; // UInt64; // fails too; other numeric types do not fail. Fails in a unit as well.
TNumbers = TArray;
TNumberRange = record
strict private
function GetLowerBound: TNumber;
public
function Numbers: TNumbers;
property LowerBound: TNumber read GetLowerBound;
end;
{ TNumberRange }
function TNumberRange.GetLowerBound: TNumber;
begin
Result := Default(TNumber);
end;
function TNumberRange.Numbers: TNumbers;
var
lValue: TNumber;
begin
for lValue := LowerBound to LowerBound do
;
end;
begin
end.
The Wiert Corner - irregular stream of stuff 