Why can't I uses Generics.Collections or Generics.Default or even just Generics in Lazarus?
Uses
Generics.Collections;
Uses
System.Generics.Default;
Uses
System.Generics.Collections;
Uses
System.Generics.Default,
System.Generics.Collections;
Uses
SysUtils,
Generics;
Cannot find Generics.Collections used by uTest of the Project Inspector.
Cannot find Generics.Defaults used by uTest of the Project Inspector.
Cannot find Generics used by uTest of the Project Inspector.
Lazarus is the IDE for the open-source FreePascal compiler. Neither of them have ANYTHING to do with Delphi. FreePascal is a completely separate Pascal compiler than the one Delphi uses.
FreePascal has a Delphi compatibility mode, and does implement various Delphi units and classes, to help users port existing Delphi code to FreePascal.
But as far as Generics is concerned, FreePascal provides its own Generics syntax and implementation that is different from, and not compatible with, Delphi's Generics (actually, support for Delphi-style Generics was added in FreePascal 2.6, but "still may be not 100% compatible" with Delphi. Also see delphi language features which fpc does not have - Generics Syntax).
Read FreePascal's documentation for more details about its flavor of Generics:
http://wiki.freepascal.org/Generics
http://www.freepascal.org/docs-html/ref/refch8.html
The System.Generics.Default and System.Generics.Collections units are only available in Delphi, they do not exist in FreePascal. However, there is a 3rd party implementation of these units available for FreePascal.
Generics.Collections library (with Generics.Defaults module) has been added to FPC trunk as rtl-generics package in r34229. Latest version of precompiled FPC trunk (with Generics.Collections) for Win32 + Lazarus trunk available at http://newpascal.org . The repository of Generics.Collections ( https://github.com/dathox/generics.collections ) will be still used for maintenance (should be synced often with FPC trunk).
I recomend you to use the Generics.Collections package made by Maciej Izak.
Related
I would like to use .NET classes in Delphi. I included mscorlib unit (which is a TLB) and want to create an instance of e.g. Assembly class. So I have:
uses mscorlib;
var myAssembly: _Assembly;
begin
myAssembly:=CoAssembly.Create;
...
end.
The application is compiled successfully, but when starting it I get an error message saying that the class is not registered.
Any idea how this can be solved?
By using mscorlib for delphi to call c#.
You can take a look at JEDI or DDNRuntime.
TJclClrHost in JEDI.
DDNRuntime is wrapper for delphi to call c#.
Features
No need for COM support.
It is very simple to use, just declare the type and method of .NET in Delphi.
Dedicated translation tool, input one or more .NET assembly DLL, output one or two Delphi import units.
Support interface types.
Support dynamic array (one-dimensional array).
Support Delegate type.
Support Event.
Generic type (Limited support. Only XE8 and above are supported and nested generics are not supported yet, such as: DNICollection<DNKeyValuePair<TKey, TValue>> such multi-level nesting).
https://github.com/ying32/DDNRuntime-examples
In compiling a Delphi 2007 project, I receive the following error:
E203: Undeclared identifier: TChangeLink
This appears to belong to the Vcl > ImgList library.
My limited understanding is that Vcl is part of the native Delphi libraries. How do I verify that it is correctly referenced?
It's because ImgList isn't in your uses clause. Based on information you provided in a comment,
uses contains this line:
Clipbrd{$IFDEF DELPHI4}, ImgList {$ENDIF}, dxCommon{$IFDEF DELPHI6}, Variants{$ENDIF}
It's because the {$IFDEF DELPHI4} is excluding it, presumably because DELPHI4 isn't defined. This is typically caused by using code that is in open-source or commercial component sets that use those version defines to support multiple Delphi versions with the same source. (This is usually done in a .INC file of some sort; Jedi uses JEDI.INC, for instance, for all of the version defines for various compiler and IDE related differences.)
The best solution (to maintain cross-version compatibility) would be to update the definitions to include Delphi 2007, but I can't offer advice on how to do so because I don't know where the define is located. The other alternative is to just remove the {$IFDEF DELPHI4} from the uses clause, if you don't need to worry about earlier versions of the IDE/compiler.
I am running Delphi XE8 and have the GetIt AsyncPro for VCL 1.0 installed. It works fine when I compile my application for 32 bit but fails for 64 bit.
The failure is:
[dcc64 Error] OoMisc.pas(2771): E2065 Unsatisfied forward or external declaration: 'Trim'
When I open OoMisc.pas is see:
{$IFNDEF Win32}
function Trim(const S : string) : string;
{$ENDIF}
The Trim function does not seem to be defined. The unit does have SysUtils in its uses clause.
AsyncPro supports only Win32 platform. It cannot be used as-is for Win64 bit.
It contains plenty of 32bit inline ASM code that would have to be replaced either by Pascal code or ported to 64bit ASM code. Besides that part there might be other incompatibilities with Win64 bit platform.
Converting 32-bit Delphi Applications to 64-bit Windows - Inline Assembly Code
If your application contains inline assembly (ASM) code, you need to
examine the ASM code and make the following changes: Mixing of
assembly statements with Pascal code is not supported in 64-bit
applications. Replace assembly statements with either Pascal code or
functions written completely in assembly.
Porting assembly code from IA-32 to Intel 64 cannot be done by simply
copying the code. Consider the architecture specifics, such as the
size of pointers and aligning. You may also want to consult the
processor manual for new instructions. If you want to compile the same
code for different architectures, use conditional defines. See Using
Conditional Defines for Cross-Platform Code in "Using Inline Assembly
Code."
RAD Studio supports Intel x86 through SSE4.2 and AMD 3dNow, and for
x64, Intel/AMD through SSE4.2.
Using Inline Assembly Code
Update:
There is Win64 port of AsyncPro provided by Johan Bontes:
I have a version for Win64 on my Github:
https://github.com/JBontes/AsyncPro
It compiles, but I have not been
able to test it comprehensivly. Feel free to file an issue if you get
stuck anywhere.
I bet that is a relic from Delphi 1 when Win32 was used to distinguish from Win16. You may safely remove those lines.
I converted AsyncPro to XE8 but it only supports Win32.
OoMisc.pas had a Trim function, that was removed from the implementation part. However somebody forgot to remove it from the interface part. That didn't hurt for x32 because it was inside of the $IFNDEF.
Win32 is not defined for x64, so the compiler will complain. The solution for this particular issue is to delete the following 3 lines that were intended for Delphi 1.0.
{$IFNDEF Win32}
function Trim(const S : string) : string;
{$ENDIF}
Of course that does not make AsyncPro compatible with x64 as there will be other issues.
How and where can I write ARM Assembly codes in Embarcadero Delphi XE5 with Android?
That would be the best, if I can write it inline.
Delphi mobile compiler do not support the asm ... end blocks.
But the "old good way" is still available, since we are talking about a Native compiler.
What you can do is compile your own module with an external assembler (e.g. GNU AS), then link it to your Delphi XE* application.
For instance, System.RTTI uses low-level asm tricks via external statically linked files:
procedure RawInvoke(CodeAddress: Pointer; ParamBlock: PParamBlock);
external 'librtlhelper.a' name 'rtti_raw_invoke';
procedure RawIntercept;
external 'librtlhelper.a' name 'rtti_raw_intercept';
Take a look at this Japanese article - Google translate is your friend!
It is not possible.
Use Atomic Instrinsics Instead of Assembly Language.
Quote:
The Delphi mobile compilers do not support a built-in assembler.
The Delphi mobile compilers do not support inline assembler. The documentation makes this clear:
The inline assembler is available on:
DCC32.EXE, the Delphi Command Line Compiler
DCC64.EXE, the Delphi 64-bit Command Line Compiler
DCCOSX.EXE, the Delphi Cross Compiler for OS X
You'll need to find an assembler to create something that the Delphi mobile compiler can consume, for instance a shared library.
You can not.
LLVM - which is the engine behind Delphi Mobile - has its kind of an assembler language: http://llvm.org/docs/CommandGuide/llvm-as.html
But it would hardly be ARM kind or x86 kind, since LLVM tries to be CPU-agnostic.
Anyway Delphi officially has no support neither for CPU-native assembling language nor for LLVM kind of it.
http://docwiki.embarcadero.com/RADStudio/XE4/en/Migrating_Delphi_Code_to_iOS_from_Desktop#Use_Atomic_Instrinsics_Instead_of_Assembly_Language
http://docwiki.embarcadero.com/RADStudio/XE4/en/Using_Inline_Assembly_Code
In this question (link) it was said that the line below (in each unit) would remove as much RTTI as possible:
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
The posting didn't mention what Delphi version it works with, but I assume D2010. However, when I include the line above, I get this error:
DCC Fatal Error: E2158 System unit out of date or corrupted:
missing TVisibilityClasses.
I'm using a "stock" version of D2010 and have never done anything that I'm aware of that would change the default installation or the libraries.
Any suggestions? TIA
Related question: link.
Make sure you put the "{$RTTI" line below the "unit unit1;" line.
Note that as of XE5 and newer, this directive needs to be in each individual unit for which you want to disable RTTI. Before that (as in comments, which applies only to XE4 and below) it could be in the DPR file and would apply to all units in the project.
The new RTTI is for Delphi 2010 and up.
It can be removed, but then lots of things will have limited functionality (like JSON conversion, part of DataSnap and many of the newer 3rd party libraries that do ORM or other mappings).
Things depending on TValue are gone anyway.
"old style" RTTI (which was introduced in Delphi 1 and is still present in Delphi 2010) cannot be removed.
So: it is recommended to remove RTTI only from your own units, and not from the RTL and VCL.
--jeroen