DelphiUdIT

But use the "grep" tool on command line to check where the unit are related, in all files (in all disk if necessary 😉) ?

58 minutes ago, David Robb said:

JavaScript and .NET/JSON implementation don't force add ".0" part for floating-point data. Only Python goes in that direction...

But is not forbidden:

6 hours ago, Der schöne Günther said:

.... It may have a fractional part prefixed by a decimal point (U+002E) (...)

If you must use NEW (so create a new variable), why don't declare it like a normal variable or a typed pointer? If you refer a record variable you don't need to allocate memory.

If you need to reference a pointer, this normally means that it's already assigned and you can cast without NEW or DISPOSE.

Another suggestion: in Delphi you don't need to "defererence" a typed pointer, the compiler do it for you:

var
  LPointer : Pointer;
begin
  New(PMyRec(LPointer));
  PMyRec(LPointer).Int := 200;
  PMyRec(LPointer).Str := 'Blah';
  Dispose(PMyRec(LPointer));
end;

var
  LPointer : PMyRec;
begin
  New(LPointer);
  LPointer.Int := 200;
  LPointer.Str := 'Blah';
  Dispose(LPointer);
end;

I don't understand what is bad here.

"FloattoJson" means transform a float value in Json reppesentation ... and this means that should be ".x" in the case that there are not "." or "E" symbol.

This is true and not questionable, but the real meaning to know if that Json format is a "standard" float or a currency is in this phrase:

Quote

JSON instead offers only the representation of numbers that humans use: a sequence of digits. All programming languages know how to make sense of digit
sequences even if they disagree on internal representations. That is enough to allow interchange.

So, I can write this values:

(1)          <- May be a integer, but you can read it like "base 10", binary, hex, octal ....

(1E0)      <- May be a integer, but also a float (and I saw the scientific notation generally is taken like a float) and yes it's "base 10"

(1.0)       <- It's a float "base 10" or currency  ?

(1.00)     <- It's float "base 10" or currency ?

But all this representations are subjective to Json ....

Most often this happens if you use third-party components. Try uninstalling add-ons (such as those installed by GETIT) one at a time to find which one might be generating the AV (assuming it depends on the added components).

May the be graph attached in that post ?

https://en.delphipraxis.net/topic/10229-unit-dependency-viwer/?do=findComment&comment=81286

1 hour ago, Remy Lebeau said:

Yes, I'm well aware of how LIBSUFFIX works and the benefit of using it.  It's been on my TODO list for a long time (https://github.com/IndySockets/Indy/issues/133), but it's not likely to be implemented in Indy 10 because that is a major interface change.  But it's already implemented for Indy 11.

It wasn't for you my reply. You are from TeamB and an MVP Embarcadero, I have nothing to explain, signaling some issue may be but sure not explain to you.

The post was for @Adam and for other readers.

  UseLatestCommonDialogs: Boolean = True;
  MsgDlgIcons: array[TMsgDlgType] of TMsgDlgIcon =
    (TMsgDlgIcon.mdiWarning, TMsgDlgIcon.mdiError, TMsgDlgIcon.mdiNone,
     TMsgDlgIcon.mdiNone, TMsgDlgIcon.mdiNone);

This is how they delete the standard dialogs (MessageBox) icons, except for Warning and Error.

To be more "simple:

1) You can refer in the "requires" section simple with IndyProtocols for example, but the library (bpl) used will be with "290" ... or the new extension for Delphi 11 or Delphi 13 ....;

2) So in every component will you refer in the future you'll refer ALWAYS to with "IndyProtocols" and depending of IDE version will linked to the correct BPL version (280, 290, 300, ....);

This require the changes the name of the DPK/DPROJ files, the changes of the "requires" sections and the use of $LIBSUFFIX = AUTO (in the DPK and in the DPROJ files). In the past that was done using LIBSUFFIX (for example) with "290" instead of AUTO.

The libraries in RAD STUDIO are related without suffix "290" but the BPL still have those suffix (for example you refer to RTL in the DPK files not RTL290).

"NEW" WAY

"OLD" WAY

Bye

3 hours ago, Remy Lebeau said:

The ticket is not closed: https://github.com/IndySockets/Indy/issues/133

I would said that there are some tickets "open" and others "closed" about that.

There are a lot of github repo to OpenCV for Delphi, this is another one:

https://github.com/gidesa/ocvWrapper46

25 minutes ago, esegece said:

If you want to compile the latest Indy package with Devexpress installed, you should do some changes, there is a post in the devexpress website which explains this:

This is right if you want maintain the full compatibility with Embarcadero and all third parts packages.

But this is not all, you must set also the $LIBSUFFIX to "AUTO", because the BPL packages should be named with "290" version. Indy packages in the repo are not set for this, there are some "ticket" open (and "closed") about this.

I wrote some posts about substitute the original Indy and restore the compatibility with Embarcadero environment, but after last changes in Indy repository I will rewrite again a full post with all steps in simply mode including openssl indy repo and ssl-oauth indy repo, possibly via script.

I compiled the new Indy package (https://github.com/IndySockets/Indy/tree/sasl-oauth) in Android platform too with success.

Three issues found:

1) In the IDHL7.PAS, after the implementation section two uses files do not exists. Comment out there will be no apparent issue. In the Embarcadero release IDHL7.PAS is not present.

2) In the IdCompilerDefines.inc there is a $DEFINE (HAS_getifaddrs):  I had undefined that since one records that will be used if that define is in use in Android platform is never delclared.

3) One settings on Embarcadero Rad Studio path is wrong, should be Android not OSX  - this is for both Android 32 and Android 64:

After those modifies, I was able to compile the Indy for Android. I try also an old Android project with IdSMTP protocol (with SSL) without any issue.

34 minutes ago, Remy Lebeau said:

Yes, but you did that using Indy's master code, which only had bug fixes and new package files.  Try it again with branched code that has interface changes in it, and you may have a different result.

I used the last update branch (SASL-OAuth) yesterday night.

3 hours ago, Adam said:

Some components had to be dropped

What components were dropped ? I replaced totally Indy without any issue, restoring also the IDE functionalities.

I think that DevEx (if it recompile the units) should no have issues.

Edit:

I tested quickly the old project that use the IdSmtp, IdTCP, IdFTP, IdHttp all with SSL and were no change on compilation. I don't use IdPop3.

I think @Remy Lebeau is working on repository branch of SASL-OAuth. 

UPDATE: I updated this repository in Rad Studio and TLS1_3 is working, an also the OAUTH2 is available on the component palette. Waiting for @Remy Lebeau news.

Why you don't use only the modified files along with yours projects (in a common repository for example) instead to porting all Indy environment ?

I use Indy from a long time and I never saw a big changes. I used in the past ( very past  ) to modify some IdAuto* protocols 'cause incompatibility with private Servers (MD5 bugged ... and stay bugged on their side).

Bye

The source of those files (idoc and idispids) are under "source/internet" (from Rad Studio base dir). The date of the files of course are like the others, but internally they are generated on 1998 from typelib. I think they are related to Internet Explorer. I don't know why I have them and you don't. I have all the platforms installed (Rad Studio Enterprise edition).

Play* are from android environment.

If make a "del Id*" from batch file, only the "idoc and idispids" are interesting, from explorer all the others are presented.

You can copy those files (idoc and idispids) to a backup place and restore after delete.

Others way is to delete only a list of know files.  Both methods, however, require monitoring of patches and environment updates.

@jesu

You can open a ticket from support if you have a subscription.

... from previous post, instructions to restore all Indy functionality inside IDE.

Go to Rad Studio installation directory (normally "C:\Program Files (x86)\Embarcadero\Studio\23.0"), in the "source" directory.

Inside the "source" should be present 3 Indy folder:

"indy", "Indy10" and "indyimpl".

Indy10 is the real source of Indy like that in the GitHub.

Instead, "indy" and "indyimpl" are the folders that contains the IDE functions implementations of Embarcadero.

The path is protected, so copy these to folder (with the content of course) somewhere ... I copied them where are the new Indy source (look at https://en.delphipraxis.net/topic/6844-tls-v13/?do=findComment&comment=88750), changing the name of "indy" in "indyextra".

EDIT: Forgot to insert the new path in the browsing property.

You must insert the path of the new folders inside the browsing property of TOOLS/OPTIONS/LANGUAGE/DELPHI/LIBRARY of the IDE.

If there are the originals, you must overwrite them.

Of course that in the image are mine, you must set yours.

Now you have to build some packages and install some of them.

In the new "indyextra\implementation" build the packages present in this sequence:

1) IndyIPCommon.dpk;

2) IndyIPClient.dpk;

3) IndyIPServer.dpk

ATTENTION: depends how you build the new Indy packages, you should change the name of the 3 requires packet (IndyCore, IndyProtocols, IndySystem) referred in the DPK source files. This is for every packages that you compile with Indy.

After that go to "indyimpl" folder and BUILD and INSTALL the "dclIPIndyImpl.dpk".

Now you have restored the original functionality inside the IDE ("FIREUI Live Preview" and " Embarcadero RAD Server Edge Components"), and you can install also the new packages that require those functions inside the IDE.

BUT ONE MORE STEP NEED TO complete the work: you must change the Windows registry, because when you install the new Indy from github repo you have disabled permanently two Embarcadero packages. Pay attention to what you are doing with Windows registry.

Open the registry with command prompt "regedit" and go to this section: "HKEY_CURRENT_USER\Software\Embarcadero\BDS\23.0\Disabled IDE Packages"

Delete the key "$(BDS)\Bin\LivePreview290.bpl"

Now go to next section "HKEY_CURRENT_USER\Software\Embarcadero\BDS\23.0\Disabled Packages"

and delete the key "$(BDSBIN)\dclemsedge290.bpl"

Now you can restart your IDE and you'll have the full functionality.

Indy works like always, and if you want to use the "new" TLS1_3 you must do some coding (also mixed designtime / runtime). But this is another chapter ...

Happy work.

The "Jedi Common Files" aka jedi.inc / kylix,inc are in the repository: https://github.com/project-jedi/jedi

You must extract this two files in the 'jcl\source\include\jedi' directory.

Hallo to all,

after update the original version of Indy, Delphi12 with patch 1, I restore also the FireUI Live functionality and may be all the other functionalities (and this with only one Indy installed, no clone or separated project).

EDIT: I confirm also the other package that was disabled (Embarcadero RAD Server Edge Components) is now restored.

I research that because some new packets (like the new RDGoogleAI in getit) need some Indy component not present on GitHub.

This post is a first little help to update Indy: https://en.delphipraxis.net/topic/6844-tls-v13/?do=findComment&comment=88750

This are the Images about FireUI working with the new Indy:

Tomorrow I'll insert the instructions to reconstruct the functionalities inside IDE (now is too late ...)

11 hours ago, David Heffernan said:

Wrong. Setting a dynamic array to nil is identical to setting length to 0 and identical to passing it to Finalize. 

Thanks, I really didn't know this.

May be March 13th  we will know 😉

The record generally doesn't need to be freed.

The array should not to be freed setting a nil, you must use:   

EDIT1: MY FAULT, like @David Heffernan  said in the next post setting a nil is right.

EDIT: Of course only with dynamic arrays !!!

SetLength(records, 0);

Every single elements of the array must be released if necessary.
In you case you must release ALL arrays inside the record structure:

EDIT2: I FORGOT ALWAYS, AND ALSO THAT IS NOT NECESSARY LIKE @Remy Lebeau  later explained.

for var i :=  Low(records) to High(records) do
  begin
 	SetLength(records[i].names, 0);
 	SetLength(records[i].age, 0);
  end;

Integral type and string doesn't need to be released in Delphi, this include all numerical type and string. All others types should be released before resizing the array.

//Example
var A: array of integer;
	B: array of string;
	C: array of TComponent;

SetLength(A, 9);
A[0] := 1;
A[1] := 2;
..... // Do something with A[]
SetLenght(A, 0); //OK, right

SetLength(B, 9);
B[0] := 'Ola';
B[1] := 'Bye';
..... // Do something with B[]
SetLength(B, 0); //OK, right

SetLength(C, 9);
C[0] := TEdit.Create(self);
C[1] := TLabel.Create(self);
..... // Do something with C[]
SetLength(C, 0); // NOOOOO, wrong


SetLength(C, 9);
C[0] := TEdit.Create(self);
C[1] := TLabel.Create(self);
//release every single element
for var compo in C do
  begin
    if Assigned(compo) then
      FreeAndNil(compo);
  end;
SetLength(C, 0); // OK, right