Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Is it possible to use new version of Indy 10
#21
(01-13-2020, 04:08 AM)OldBob1938 Wrote: downloaded a fresh copy of Indy 10_5520

And where did you download that from exactly? Indy's Fulgan mirror for nightly snapshots is no longer active.

(01-13-2020, 04:08 AM)OldBob1938 Wrote: extracted everything from Indy 10_5520.zip to folder of the same name in downloads  (instructions said to use a folder of my choice

That is fine.

(01-13-2020, 04:08 AM)OldBob1938 Wrote: should I have run this from the codegear directory in program files?

I wouldn't have, no.

(01-13-2020, 04:08 AM)OldBob1938 Wrote: ran FULLD_2007.BAT and FULLC_2007.BAT 

You don't need to run FULLD_2007.BAT if you don't have Delphi installed. For a C++Builder-only installation, FULLC_2007.BAT will suffice.

(01-13-2020, 04:08 AM)OldBob1938 Wrote: looked in the BIN folder and did not find any indy  bpl files, and there were also no indy files in the source, lib, and include folders?

Because that is not where FULLC_2007.BAT outputs its compiled files to.  It outputs them into a C11 subfolder that it creates in its parent folder.  For example, if FULLC_2007.BAT is located in C:\Indy 10_5520\Lib\ then the compiled files are output to C:\Indy 10_5520\C11\.

(01-13-2020, 04:08 AM)OldBob1938 Wrote: Opened the IDE, looked at componenets->install and there was just a message that it couldn't find any dclindy....100 bpls. 

They shouldn't be in the IDE at all since you removed them before extracting the new source code.  Oh wait, you probably have other components installed that use Indy internally.  But they should have been removed as well when you removed Indy's packages.  If you have components that use Indy, you will have to recompile them too, once you have the updated Indy installed.

(01-13-2020, 04:08 AM)OldBob1938 Wrote: I did notice that there are 2 new folders (C11 and D11) in Indy 10_5520 that are not in the zip.

Correct. The .BAT scripts create them.

(01-13-2020, 04:08 AM)OldBob1938 Wrote: re-ran the BAT files with the output sent to a text file and discovered this message at the end of the FULLD run
......
C:\Users\bob\Downloads\Indy10_5520\Lib\Core\IndyCore110.dpk(25) Fatal: E2202 Required package 'IndySystem110' not found
Error!

Try adding the Indy10_5520\D11 folder to your console's %PATH% environment.  That is where IndySystem110.bpl will be located after it is compiled, but that is not where the FULLD_2007.BAT script compiles IndyCore110.bpl from, so the Delphi compiler doesn't know to look for IndySystem110.bpl there.  Unlike the FULLC_2007.BAT script, which copies everything to the Indy10_5520\C11 folder first and compiles everything from there.  Not sure why the two .BAT scripts are different in that regard.  I didn't write them, MJ did.

On the other hand, I don't really suggest using the FULLD_XXX.BAT scripts for Delphi installations, I tell people to open the individual .DPK project files (or the appropriate IndyXXX.groupproj file) directly in the IDE and compile+install from there instead.  Much easier that way.  That is why the Delphi scripts stop with D2007, while the FULLC_XXX.BAT scripts continue through 10.2 Tokyo (I haven't released updated files for 10.3 Rio yet), as C++Builder installations of Indy have some extra build steps that need to be done at the command-line.

Reply
#22
(01-14-2020, 02:11 AM)rlebeau Wrote:
(01-13-2020, 04:08 AM)OldBob1938 Wrote: downloaded a fresh copy of Indy 10_5520

And where did you download that from exactly? Indy's Fulgan mirror for nightly snapshots is no longer active.

I think I got it from via the Fulgan link on the Indy Update Instructions page.   My last copy was 1/6/20.  I just tried to access the latest snapshot and it's no longer available.


Because that is not where FULLC_2007.BAT outputs its compiled files to.  It outputs them into a C11 subfolder that it creates in its parent folder.  For example, if FULLC_2007.BAT is located in C:\Indy 10_5520\Lib\ then the compiled files are output to C:\Indy 10_5520\C11\.  

OK, I get it.  But the instructions don't mention the C11/D11 folders and I don't see how the files that are in those folders get to the Rad Studio folders.  How do I get them where they are supposed to be?

(01-13-2020, 04:08 AM)OldBob1938 Wrote: Opened the IDE, looked at componenets->install and there was just a message that it couldn't find any dclindy....100 bpls. 

They shouldn't be in the IDE at all since you removed them before extracting the new source code.  Oh wait, you probably have other components installed that use Indy internally.  But they should have been removed as well when you removed Indy's packages.  If you have components that use Indy, you will have to recompile them too, once you have the updated Indy installed.



[quote pid='4990' dateline='1578888513']
re-ran the BAT files with the output sent to a text file and discovered this message at the end of the FULLD run
......
C:\Users\bob\Downloads\Indy10_5520\Lib\Core\IndyCore110.dpk(25) Fatal: E2202 Required package 'IndySystem110' not found
Error!

Try adding the Indy10_5520\D11 folder to your console's %PATH% environment.  That is where IndySystem110.bpl will be located after it is compiled, but that is not where the FULLD_2007.BAT script compiles IndyCore110.bpl from, so the Delphi compiler doesn't know to look for IndySystem110.bpl there.  Unlike the FULLC_2007.BAT script, which copies everything to the Indy10_5520\C11 folder first and compiles everything from there.  Not sure why the two .BAT scripts are different in that regard.  I didn't write them, MJ did.

On the other hand, I don't really suggest using the FULLD_XXX.BAT scripts for Delphi installations, I tell people to open the individual .DPK project files (or the appropriate IndyXXX.groupproj file) directly in the IDE and compile+install from there instead.  Much easier that way.  That is why the Delphi scripts stop with D2007, while the FULLC_XXX.BAT scripts continue through 10.2 Tokyo (I haven't released updated files for 10.3 Rio yet), as C++Builder installations of Indy have some extra build steps that need to be done at the command-line.

OK again, but for CBuilder, the instructions don't seem to tell me what to do next.  I've got the C11/D11 folders full of stuff.  The instructions say that after compiling I should see compiled DCU files in the Indy directory.  Then I go to the Tools->Environment Option->Select Library Tab and add the path to the files to the filepath collection.   I also don't understand about adding the D11 folder to the %path% environment.  Sorry Remy, but I'm still lost.  
[/quote]
Reply
#23
(01-14-2020, 03:03 AM)OldBob1938 Wrote: I think I got it from via the Fulgan link on the Indy Update Instructions page.   My last copy was 1/6/20.  I just tried to access the latest snapshot and it's no longer available.

OK.

(01-14-2020, 03:03 AM)OldBob1938 Wrote: OK, I get it.  But the instructions don't mention the C11/D11 folders and I don't see how the files that are in those folders get to the Rad Studio folders.  How do I get them where they are supposed to be?

You would have to move them manually after compiling is finished. Or, just leave them where they are, and update your IDE search paths to include the C11/D11 folders.

IIRC, later versions of the .BAT files move the compiled files into the IDE's default folders for you (FULLD_2007.BAT copies the compiled .BPL files into the Windows System folder).

(01-14-2020, 03:03 AM)OldBob1938 Wrote: OK again, but for CBuilder, the instructions don't seem to tell me what to do next. I've got the C11/D11 folders full of stuff.  The instructions say that after compiling I should see compiled DCU files in the Indy directory.

.DCU files are typically used with Delphi, not with C++Builder (usless you want to step into Indy's source code with the C++Builder debugger). However, FULLC_2007.BAT deletes the .DCU files after compiling is finished. FULLD_2007.BAT does not.

(01-14-2020, 03:03 AM)OldBob1938 Wrote: I also don't understand about adding the D11 folder to the %path% environment.

Do you not understand what I mean when I refer to %PATH%? If not, then you should read up on what that is.

You don't use the D11 folder with C++Builder, only with Delphi. Use the C11 folder instead with C++Builder. Like I said, for a C++Builder-only installation, you don't need to use FULLD_2007.BAT at all.

Reply
#24
Remy
Thanks, you're a lifesaver.  I've just done the CBuilder part.  I don't use Delphi.  I created a trivial new project with just idFTP and it didn't crash.  The components show as Indy 10.6.2.  

My test app connected to my websites ftp.  I may run into the same problems that others have expressed with the FTP client.  I did have a strange error that has nothing to do with my Indy installation.  It was a EldReplyRFCError with message "I won't open a connection to 192.xxx...(only to 47......)"  This will be part of my learning curve on FTP.

Now I need to get the SSL files that go with 10.6.2.  I'm guessing they will be the latest files.  

Thanks for your help.

Bob
Reply
#25
(01-14-2020, 09:37 PM)OldBob1938 Wrote: My test app connected to my websites ftp.  I may run into the same problems that others have expressed with the FTP client.  I did have a strange error that has nothing to do with my Indy installation.  It was a EldReplyRFCError with message "I won't open a connection to 192.xxx...(only to 47......)"  This will be part of my learning curve on FTP.

Yes, that is an error message from the FTP server, it is actively refusing to open a data connection to your client. Now you need to figure out why. Contact the server admin for help on that, if needed.

If I had to guess, it looks like you are running your client on a private LAN and the server doesn't want to open a data connection to a LAN IP, only to a WAN IP.

FTP file transfers are performed over a secondary TCP connection.

Are you performing your file transfers in Active mode (TIdFTP.Passive=False)? That is the default mode dictated by the FTP protocol. In that mode, the FTP server establishes the secondary connection as an outbound TCP connection FROM the server TO your client. But in order for that to work when your client is behind a proxy/router, you will have to set the TIdFTP.ExternalIP property to your public WAN IP, and setup appropriate port forwarding rules on the proxy/router itself (unless you are using a proxy/router that recognizes the FTP protocol and will forward automatically - most don't do that, though).

Otherwise, perform your file transfers in Passive mode instead (TIdFTP.Passive=True). In that mode, your FTP client establishes the secondary connection as an outbound TCP connection FROM the client TO the server, which is more friendly to proxies/routers.

(01-14-2020, 09:37 PM)OldBob1938 Wrote: Now I need to get the SSL files that go with 10.6.2.  I'm guessing they will be the latest files.  

If you mean the OpenSSL DLLs, then Indy supports up to the latest OpenSSL 1.0.2u, NOT 1.1.x yet (work still in progress). Those DLLs are still currently available on the Fulgan mirror in the SSL folder, though they are expected to be moved to Indy's GitHub repo eventually.

Reply
#26
You are correct in both cases. I've made the change to the passive mode and the problem has disappeared. I've also installed OpenSSL 1.02u.

You were correct that much of my earlier problems had to do with the fact that I tried to use a program that had the old Indy version installed. I deleted the old components from the units that used them, installed the new components, and voila ... it works.

Thanks again for your support.
Reply
#27
Hi, I'm back with a report and a question.

I've created new programs with 10.62 without any problems but, for some reason, I couldn't get it to work on the one program that I really wanted it to work with. On my test computer, I had a perfect copy of the program in question, and new programs, which used indy 10.62, that worked great. I made sure that all of the in both debug and base were identical between the new programs (they worked) and my target program (that didn't). I finally looked at the project file and found, to my amazement, lots of paths that included the old indy (as well as some bizarre references to programs that no longer exist). Knowing that I had a perfect backup of the project file, I edited it to remove all references to the old indy installation as well as the bizarre ones. Voila! The target program now works correctly. What a relief.

Now for the question. I've noticed there is an indy component IdSMTPRelay. I've been using IdSMTP for smtp relay by setting
IdSMTP->Host = "smtp-relay.gmail.com";
I've needed to do this since we do all of our mailing, including bulk email, via gsuite. Is there some advantage to using SMTPRelay instead?

Thanks again
Reply
#28
(01-27-2020, 07:34 PM)OldBob1938 Wrote: Now for the question.  I've noticed there is an indy component  IdSMTPRelay.  I've been using IdSMTP for smtp relay by  setting
    IdSMTP->Host  = "smtp-relay.gmail.com";
I've needed to do this since we do all of our mailing, including bulk email, via gsuite.  Is there some advantage to using SMTPRelay instead? 

TIdSMTP connects to 1 SMTP server and then sends 1 TIdMessage at a time, letting the SMTP server relay the email to all of the recipients as needed. This is the component you should typically be using, especially if you already have a relaying service that you use.

TIdSMTPRelay looks at the TIdMessage recipients, groups them by domain, and then connects to each domain's SMTP server and sends the TIdMessage to only the recipients within that domain. This would be the component you should use if you are implementing your own relaying SMTP server.

Reply
#29
(01-28-2020, 09:03 PM)rlebeau Wrote:
(01-27-2020, 07:34 PM)OldBob1938 Wrote: Now for the question.  I've noticed there is an indy component  IdSMTPRelay.  I've been using IdSMTP for smtp relay by  setting
    IdSMTP->Host  = "smtp-relay.gmail.com";
I've needed to do this since we do all of our mailing, including bulk email, via gsuite.  Is there some advantage to using SMTPRelay instead? 

TIdSMTP connects to 1 SMTP server and then sends 1 TIdMessage at a time, letting the SMTP server relay the email to all of the recipients as needed.  This is the component you should typically be using, especially if you already have a relaying service that you use.

TIdSMTPRelay looks at the TIdMessage recipients, groups them by domain, and then connects to each domain's SMTP server and sends the TIdMessage to only the recipients within that domain.  This would be the component you should use if you are implementing your own relaying SMTP server.

Thanks.  You are a very patient lifesaver.
Reply


Forum Jump:


Users browsing this thread: 4 Guest(s)