Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Indy10 and Delphi 10.4 Sydney
#1
In Delphi 10.4 are AUTOREFCOUNT and NEXTGEN not defined, therefore it is not possible IdGlobal to compile, because USE_OBJECT_ARC, DCC_NEXTGEN, HAS_MarshaledAString and USE_MARSHALLED_PTRS are not defined.

http://docwiki.embarcadero.com/RADStudio...n_(Delphi)
Reply
#2
(11-26-2020, 05:17 AM)radek.secka Wrote: In Delphi 10.4 are AUTOREFCOUNT and NEXTGEN not defined

Correct, because Embarcadero has dropped support for ARC-based memory management of TObject on mobile platforms, and gone back to traditional 1-based string indexing by default on all platforms. So all NEXTGEN features have been disabled in 10.4.

(11-26-2020, 05:17 AM)radek.secka Wrote: therefore it is not possible IdGlobal to compile, because USE_OBJECT_ARC, DCC_NEXTGEN, HAS_MarshaledAString and USE_MARSHALLED_PTRS are not defined.

Those are conditionals that Indy defines for itself when compiled under a NEXTGEN compiler. The IdGlobal unit (and the rest of Indy in general) should compile just fine under non-NEXTGEN compilers without those conditionals defined. I know this, because:

- I develop Indy without having those conditionals defined (I don't do any mobile development, only Windows).

- 10.4 includes an up-to-date copy of Indy, which Embarcadero had to compile themselves for all supported platforms in order to include it in the 10.4 release. They did not come to me complaining about any compiler errors, or submitting any patches for such errors (which they usually do).

So, why do you think IdGlobal won't compile without the NEXTGEN conditionals being defined? Are you just making an assumption, or do you have actual proof (ie, a real compiler error)?

Reply
#3
Thank you a lot, I have compiled old Indy version 10.6.2 and compared it with Git-Repository which is not actual.
Reply
#4
(11-30-2020, 08:54 AM)radek.secka Wrote: I have compiled old Indy version 10.6.2

The current version is 10.6.2.x. Are you, by chance, being confused by the fact that the build number (.x) is 0 in IdVers.inc? That is a known issue - see https://github.com/IndySockets/Indy/issues/292 and https://github.com/IndySockets/Indy/issues/328.

(11-30-2020, 08:54 AM)radek.secka Wrote: and compared it with Git-Repository which is not actual.

I don't understand what you are trying to say.

What was the point in starting this discussion in the first place? Were you having an actual problem in compiling Indy? If so, what problem exactly?

Reply
#5
(11-30-2020, 05:36 PM)rlebeau Wrote: What was the point in starting this discussion in the first place?  Were you having an actual problem in compiling Indy?  If so, what problem exactly?

Hello.
(sorry for my bad english)

Me, i have a problem in compiling the unit IdSASL_NTLM
with this line (in TIdSASLNTLM.ContinueAuthenticate)
Code:
  LMsg := ToBytes(ALastResponse, LEncoding{$IFDEF STRING_IS_ANSI}, LEncoding{$ENDIF});
 
[dcc32 Erreur] IdSASL_NTLM.pas(72): E2250 Aucune version surchargée de 'ToBytes' ne peut être appelée avec ces arguments
Reply
#6
(03-08-2021, 10:41 AM)Cortomatt Wrote: Me, i have a problem in compiling the unit IdSASL_NTLM
with this line (in TIdSASLNTLM.ContinueAuthenticate)
Code:
  LMsg := ToBytes(ALastResponse, LEncoding{$IFDEF STRING_IS_ANSI}, LEncoding{$ENDIF});
 
[dcc32 Erreur] IdSASL_NTLM.pas(72): E2250 Aucune version surchargée de 'ToBytes' ne peut être appelée avec ces arguments

That translates to the following in English:

Quote:[dcc32 Error] IdSASL_NTLM.pas(72): E2250 No overloaded version of 'ToBytes' can be called with these arguments

And yes, there is a suitable overload for those exact arguments (where ALastResponse is a const String, and LEncoding is an IIdTextEncoding):

Code:
function ToBytes(const AValue: string; ADestEncoding: IIdTextEncoding = nil
  {$IFDEF STRING_IS_ANSI}; ASrcEncoding: IIdTextEncoding = nil{$ENDIF}
  ): TIdBytes; overload;

Makes me wonder if you are compiling with an old version of IdGlobal.pas rather than the latest?

Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)