I'm currently updating some existing Delphi code to compile on MacOS using Delphi XE2.
The Delphi XE2 Update 3 is installed.
On Win32 and Win64 a particular bit of the code works as expected and it also compiles/runs as expected when compiling with Delphi 4 all the way up to Delphi XE.
However, when compiling for MacOS the same piece of code doesn't work the same way. We've also had some crashes on the Mac - but that might have been the XE2 debugger.
type
TFixedSizeAnsiStringArray = array[0..255] of AnsiString;
procedure TForm1.Button1Click(Sender: TObject);
var
FirstArray: TFixedSizeAnsiStringArray;
SecondArray: TFixedSizeAnsiStringArray;
begin
FirstArray[0] := 'Apple';
FirstArray[1] := 'Banana';
FirstArray[2] := 'Pineapple';
// ...
SecondArray := FirstArray;
Memo1.Lines.Add(SecondArray[0]);
Memo1.Lines.Add(SecondArray[1]);
// ....
end;
On Windows, all the elements of SecondArray are the same as the elements of FirstArray.
But on MacOS (when it does run) only the first element of SecondArray has the correct value.
It's easy to fix with a for loop - but understanding why it's different between Windows and MacOS would be good to know.
Maybe something to do with the use of AnsiString?
That would appear to be a bug in the Mac OS compiler. Please can you submit a report to Quality Central.
Related
I'm trying to use ssl with Indy and keep getting the following error:
Project MtApp.exe raised exception class EFOpenError with message 'Cannot open file "C:\Development\MyApp\Win64\Debug\㩃䑜癥汥灯敭瑮作浡牡屵汁呬楨杮即獹潬屧祓䱳杯楓屭祓䱳杯楓䍭湯潳敬坜湩㐶䑜扥杵浜剹潯䍴⹁数m". The system cannot find the file specified'.
It occurs in the IdSSLOpenSSL.pas file in the following function:
function by_Indy_unicode_file_ctrl(ctx: PX509_LOOKUP; cmd: TIdC_INT; const argc: PAnsiChar; argl: TIdC_LONG; out ret: PAnsiChar): TIdC_INT; cdecl;
The argc parameter appears to be passed in correctly. The IDE debugger shows it as "C:\Development\MyApp\Win64\Debug\myRootCA.pem". The problem seems to be when it is cast as a PWideChar and assigned to a String variable:
X509_FILETYPE_PEM:
begin
// Note that typecasting an AnsiChar as a WideChar is normally a crazy
// thing to do. The thing is that the OpenSSL API is based on ASCII or
// UTF8, not Unicode and we are writing this just for Unicode filenames.
LFileName := PWideChar(argc);
LOk := Ord(Indy_unicode_X509_load_cert_crl_file(ctx, LFileName, X509_FILETYPE_PEM) <> 0);
end;
The LFileName variable is 㩃䑜癥汥灯敭瑮作浡牡屵汁呬楨杮即獹潬屧祓䱳杯楓屭祓䱳杯楓䍭湯潳敬坜湩㐶䑜扥杵浜剹潯䍴⹁数m after the cast, causing a FileNotFound exception.
What am I doing wrong?
You did not say which version of Delphi or Indy you are using. But, the code you have shown is not the latest code that is currently in Indy.
What you have described was due to a regression bug that Embarcadero introduced in the Indy release that shipped in RAD Studio 10.3. They fixed that in a patch for RAD Studio 10.3.3:
https://blogs.embarcadero.com/rad-studio-10-3-3-indy-server-ssl-certificate-patch/
https://cc.embarcadero.com/item/30906
I suggest you update to the latest version of Indy from its GitHub repo:
https://github.com/IndySockets/Indy/
https://github.com/IndySockets/Indy/wiki/Updating-Indy
I get the CromisIPC cromis ipc site download and compile/rum successfully the demos and custom project on delphi XE5. Without any error.
But, when I get the same code and put on DELPHI 7 project, I have an error on unit Cromis. AnyValue, an compilation error.
TAnyValue = packed record
private
ValueData: TValueDataType;
{$IFDEF AnyValue_HookingOff}
IntfData : IInterface;
{$ELSE}
{$IFNDEF CPUX64}
Padding : array [0..3] of Byte;
{$ENDIF}
{$ENDIF}
ValueType: TValueType;
function GetAsInt64: Int64; inline;
Exactly on lyne:
ValueData: TValueDataType;
[Error] Cromis.AnyValue.pas(210): ',' or ':' expected but identifier 'ValueData' found
[Error] Cromis.AnyValue.pas(219): 'END' expected but 'FUNCTION' found
I use delphi 7 on a 64 bits windows 7 with a 32 bits VCL project.
The same code compiles on XE5.
What happens here ? any idea ?
tl;dr This code is not designed to work under Delphi 7.
Visibility specifiers are not allowed in Delphi 7 records. The compiler is objecting to the use of private. You can remove that, but then the next problem will be all the methods that are declared on the record. Again, they are not available in Delphi 7.
You might be able to make some headway by switching from packed record to packed object. However, I think it highly unlikely that this will be smooth sailing. Expect a lot of work to make this code compile on Delphi 7. Frankly, you would need to be a Delphi expert to take on this task.
You might try to find an old version of the library that actually supports Delphi 7. You might be able to get one from the library's author. But note that the website says:
All code is Delphi 2006 and upwards compatible. I will not support older Delphi version. If you still use them, then its time to upgrade.
Which leads to the other obvious solution. Upgrade to a modern version of Delphi.
If that is impossible, then you should look for a different library.
I'm trying to convert my current Delphi 7 Win32 code to Delphi XE5 Android with minimal changes, so that my project can be cross-compiled to Win32 from a range of Delphi versions and Android from XE5.
Starting from XE5 there are breaking changes in language aimed at future. One of such changes is zero-based strings.
In older versions with 1-based strings the following code was correct:
function StripColor(aText: string): string;
begin
for I := 1 to Length(aText) do
but now this is obviously not right. Suggested solution is to use:
for I := Low(aText) to High(aText) do
This way XE5 Win32 handles 1-based strings and XE5 Android handles 0-based strings right. However there's a problem - previous Delphi versions (e.g. XE2) output an error on such code:
E2198 Low cannot be applied to a long string
E2198 High cannot be applied to a long string
I have quite a lot of string manipulation code. My question is - how to modify and keep above code to be compileable in Delphi 7 Win32 and Delphi XE5 Android?
P.S. I know I can still disable ZEROBASEDSTRINGS define in XE5, but that is undesired solution since in XE6 this define will probably be gone and all strings will be forced to be 0-based.
If you want to support versions that use one based strings then don't define ZEROBASEDSTRINGS. That's the purpose of that conditional.
There's no indication that I am aware of that the conditional will be removed any time soon. It was introduced in XE3 and has survived two subsequent releases. If Embarcadero remove it, none of their Win32 customers will not upgrade and they will go bust. Embarcadero have a track record of maintaining compatibility. You can still use TP objects and short strings. Expect this conditional to live as long as the desktop compiler does.
In fact, all the evidence points towards the mobile compilers retaining support for one based string indexing. All the utility string functions like Pos use one based indices, and will continue to do so. If Embarcadero really are going to remove support for one based string indexing, they'll be removing Pos too. I don't believe that is likely any time soon.
Taking your question at face value though it is trivial to write functions that return the low and high indices of a string. You just use an IFDEF on the compiler version.
function StrLow(const S: string): Integer; inline;
begin
Result := {$IFDEF XE3UP}low(S){$ELSE}1{$ENDIF}
end;
function StrHigh(const S: string): Integer; inline;
begin
Result := {$IFDEF XE3UP}high(S){$ELSE}Length(S){$ENDIF}
end;
Update
As Remy points out, the above code is no good. That's because ZEROBASEDSTRINGS is local and what counts is its state at the place where such functions would be used. In fact it's just not possible to implement these functions in a meaningful way.
So, I believe that for code that needs to be compiled using legacy compilers, as well as the mobile compilers, you have little choice but to disable. ZEROBASEDSTRINGS.
All of the RTL's pre-existing functions (Pos(), Copy(), etc) are still (and will remain) 1-based for backwards compatibility. 0-based functionality is exposed via the new TStringHelper record helper that was introduced in XE3, which older code will not be using so nothing breaks.
The only real gotchas you have to watch out for are things like hard-coded indexes, such as your loop example. Unfortunately, without access to Low/High(String) in older Delphi versions, the only way to write such code in a portable way is to use IFDEFs, eg:
{$IFDEF CONDITIONALEXPRESSIONS}
{$IF CompilerVersion >= 24}
{$DEFINE XE3_OR_ABOVE}
{$IFEND}
{$ENDIF}
function StripColor(aText: string): string;
begin
for I := {$IFDEF XE3_OR_ABOVE}Low(aText){$ELSE}1{$ENDIF} to {$IFDEF XE3_OR_ABOVE}High(AText){$ELSE}Length(aText){$ENDIF} do
DoSomething(aText, I);
end;
Or:
{$IFDEF CONDITIONALEXPRESSIONS}
{$IF CompilerVersion >= 24}
{$DEFINE XE3_OR_ABOVE}
{$IFEND}
{$ENDIF}
function StripColor(aText: string): string;
begin
for I := 1 to Length(aText) do
begin
DoSomething(aText, I{$IFDEF XE3_OR_ABOVE}-(1-Low(AText)){$ENDIF});
end;
end;
Conditional Expressions were introduced in Delphi 6, so if you don't need to support version earlier than Delphi 7, and don't need to support other compilers like FreePascal, then you can omit the {$IFDEF CONDITIONALEXPRESSIONS} check.
This is rather a sum up of the two answers:
As pointed out by Remy Lebeau, ZEROBASEDSTRINGS is a per-block conditional. That means that the following code will not work as expected:
const
s: string = 'test';
function StringLow(const aString: string): Integer; inline; // <-- inline does not help
begin
{$IF CompilerVersion >= 24}
Result := Low(aString); // Delphi XE3 and up can use Low(s)
{$ELSE}
Result := 1; // Delphi XE2 and below can't use Low(s), but don't have ZEROBASEDSTRINGS either
{$ENDIF}
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
{$ZEROBASEDSTRINGS OFF}
Memo1.Lines.Add(Low(s).ToString); // 1
Memo1.Lines.Add(StringLow(s).ToString); // 1
{$ZEROBASEDSTRINGS ON}
end;
procedure TForm1.Button2Click(Sender: TObject);
begin
{$ZEROBASEDSTRINGS ON}
Memo1.Lines.Add(Low(s).ToString); // 0
Memo1.Lines.Add(StringLow(s).ToString); // 1 <-- Expected to be 0
{$ZEROBASEDSTRINGS OFF}
end;
There are 2 possible solutions:
A. Every time there's string items access or iteration place an IFDEF around it, which is indeed a lot of clutter for the code, but will work properly irregardless of ZEROBASEDSTRINGS setting around it:
for I := {$IFDEF XE3UP}Low(aText){$ELSE}1{$ENDIF} to {$IFDEF XE3UP}High(aText){$ELSE}Length(aText){$ENDIF} do
B. Since the ZEROBASEDSTRINGS conditional is per-block it never gets spoiled by 3rd party code and if you don't change it in your code you are fine (above StringLow will work fine as long as the caller code has the same ZEROBASEDSTRINGS setting). Note that if target is mobile, you should not apply ZEROBASEDSTRINGS OFF globally in your code since RTL functions (e.g. TStringHelper) will return 0-based results because mobile RTL is compiled with ZEROBASEDSTRINGS ON.
On a side note - One might suggest to write an overloaded versions of Low/High for older versions of Delphi, but then Low(other type) (where type is array of something) stops working. It looks like since Low/High are not usual functions then can not be overloaded that simply.
TL;DR - Use custom StringLow and don't change ZEROBASEDSTRINGS in your code.
How about defining this as an inc file? Put additional ifdefs depending on what Delphi versions you want to support. Since this code is only for versions before the ZBS to make it possible to use Low and High on strings it will not run into the problem with the ZEROBASEDSTRINGS define only being local.
You can include this code locally (as nested routines) then which reduces the risk of colliding with System.Low and System.High.
{$IF CompilerVersion < 24}
function Low(const s: string): Integer; inline;
begin
Result := 1;
end;
function High(const s: string): Integer; inline;
begin
Result := Length(s);
end;
{$IFEND}
As LU RD told above Low and High functions for string were only introduced in XE3. So how can you use functions in earlier Delphi verions, that are missed? Just the same way as always do - if the function is missed - go and write it!
You should only activate those compatibility additions for Delphi beyond XE3 version, using conditional compilation. One way is described in other answers, using >= comparison. Another usual way would be reusing jedi.inc definitions file.
Then for earlier Delphi versions you would add your own implementations of those, like
function Low(const S: AnsiString): integer; overload;
Pay attention to the overload specifier - it is what would make the trick possible, don't forget it!
You would have to write 4 functions for Delphi 7 till 2007, covering combinations of Low/High fn name and AnsiString/WideString data type.
For Delphi 2009 till XE2 you would have to add two more functions for UnicodeString datatype.
And also mark those function inline for those Delphi versions, that support it (this is where jedi.inc comes handy again.
Hopefully you don't need supprot for UTF8String, but if you do - you know what to do about it now (if compiler would manage to tell it from AnsiString when overloading...)
Data processing with XE3 programs take up to 10 times more than with same programs compiled with XE2. This is known issue (probably refers mainly to TStringField), reported to QC 111942, but it is not fixed yet. Does anybody have a fix / workaround for this issue?
TIA Branko
Same in XE5. Plus extra traffic and all this client-server thing require >5 Mbit per second (!) to work normally. I am using only TFDConnection and TFDQuery. Specially for MySQL the speed is the same with Delphi components and with third-party driver (libmysql.dll). If you have no FireDAC you can replace TFDQuery with TSQLQuery. Here is a procedure how to fill a string grid:
procedure SelGrid(sql:ansiString;Q:TFDQuery;grid:TStringGrid);
var i: integer;
begin
Q.Close;
Q.SQL.Text:='';
Q.Open(sql);
grid.ColCount:=Q.FieldCount;
grid.RowCount:=1;
while not Q.Eof do begin
for i := 0 to grid.ColCount-1 do grid.Cells[i,grid.RowCount-1]:=Q.Fields.Fields[i].AsString;
grid.RowCount:=grid.RowCount+1;
Q.Next;
end;
Q.Close;
if grid.RowCount>1 then grid.RowCount:=grid.RowCount-1;
grid.Row:=0;
//AutoSizeGridColumns(grid,30,200);
end;
This is VCL string grid. Of course you muse deal with updates and so on, but you'll have no more performance problems.
I'm testing a non visual ActiveX control based on a registered .ocx
which I import into Delphi using the provided wizard.
Then, I simply put the generated component on the main form of a new VCL application.
Under old Delphi versions (D5 and D2007), when i launch the application, this raise an AV
during the component initialization.
with Delphi 2009 : no problem, the application starts smoothly.
My questions are :
Are there known enhancements of ActiveX management in recent Delphi versions which
can explain this difference ?
Can I suspect a bug in the ActiveX control, or can I consider the origin of the
problem is from old Delphi versions ?
I need to use this component (if tests OK) in D2007.
Do you think that it is possible to correct the AV problem under D2007 by modifying the D2007 generated .tlb file (for example by trying to use the D2009 generated one)
PS: the ActiveX control is not named, because my question is a general question about Delphi and ActiveX, not about a specific ActiveX control.
Edit :
With D2007, the error (an Access Violation) appears during Application.CreateForm(TForm1, Form1);
and more specifically when the Olecontrol is created :
procedure TOleControl.CreateInstance;
var
ClassFactory2: IClassFactory2;
LicKeyStr: WideString;
procedure LicenseCheck(Status: HResult; const Ident: string);
begin
if Status = CLASS_E_NOTLICENSED then
raise EOleError.CreateFmt(Ident, [ClassName]);
OleCheck(Status);
end;
begin
if not (csDesigning in ComponentState) and
(FControlData^.LicenseKey <> nil) then
begin
// ON THE LINE BELOW : the call of CoGetClassObject raise an AV
OleCheck(CoGetClassObject(FControlData^.ClassID, CLSCTX_INPROC_SERVER or
CLSCTX_LOCAL_SERVER, nil, IClassFactory2, ClassFactory2));
LicKeyStr := PWideChar(FControlData^.LicenseKey);
LicenseCheck(ClassFactory2.CreateInstanceLic(nil, nil, IOleObject,
LicKeyStr, FOleObject), SInvalidLicense);
end else
LicenseCheck(CoCreateInstance(FControlData^.ClassID, nil,
CLSCTX_INPROC_SERVER or CLSCTX_LOCAL_SERVER, IOleObject,
FOleObject), SNotLicensed);
end;
As far as I remember there were major enhancements to the ActiveX/TLB import in Delphi 2009 (related to Unicode support) - that might explain it.
In my personal experience Delphi 7 and Delphi 2007 repeatedly failed to import some Windows 7 type libraries (various new interfaces to work with new taskbar), but Delphi 2009 managed that without any problems at all.
As for using Delphi 2009 generated file in earlier versions - beware of Unicode issues. Plus it won't help if the defect is in RTL... Try to make a wrapper ActiveX in Delphi 2009 and use it in Delphi 2007 - that should work.
Sorry to barge in so late after the battle (5 years later as a matter of fact), but I wasted so much time on this precise issue that I thought I should share what I've seen and what I've done to solve it :
2 machines (win7 64 / win 8.1) same delphi 7 (same version same build), same activeX (MapX to name it) with identical .lic files containing the key made of 59 characters :
uQnZi2sFw22L0-MRa8pYX-1E2P8065-5N5M3459-3C934220-04969-6562
same import producing 2 slightly different TLB.
The one working : (on win 8.1) contains this in procedure TMap.InitControlData :
const
CLicenseKey: array[0..61] of Word = ( $0075, $0051, $006E, $005A, $0069, $0032, $0073, $0046, $0077, $0032, $0032
, $004C, $0030, $002D, $004D, $0052, $0061, $0038, $0070, $0059, $0058
, $002D, $0031, $0045, $0032, $0050, $0038, $0030, $0036, $0035, $002D
, $0035, $004E, $0035, $004D, $0033, $0034, $0035, $0039, $002D, $0033
, $0043, $0039, $0033, $0034, $0032, $0032, $0050, $0030, $002D, $004D
, $0030, $0034, $0039, $0036, $0039, $002D, $0036, $0035, $0036, $0032
, $0000);
which translates to a 61 char key
uQnZi2sFw22L0-MRa8pYX-1E2P8065-5N5M3459-3C93422P0-M04969-6562
The TLB that does not work (win 7 64) contains this instead:
const
CLicenseKey: array[0..2] of Word = ( $0050, $004D, $0000);
which translates to a 2 char key
PM
Replacing one const with the other and recompiling the component solved my issue. I don't really know what happened. I just know the Import/TLB produced a bad .pas file that can be corrected manually.