giomach

Thanks, that clarifies things. Unfortunately the suggested solution would be difficult given the program structure — the code snippet occurs in one branch of an if statement, and the bulk of the rest of the code comes outside that if statement, after the branches re-unite. Rather than undertake a large-scale program restructure, I think I'll regretfully stick with application.processmessages.

Using SQLiteTable3 in Delphi XE update 1 under Windows 10. I'm a complete novice with SQLite. I have set up a database with a table called FormSenses with the first two fields called Form and Sense. I can load this table into a Delphi ListView and display it. I show a section of the ListView in the attachment. There are five records with Form = 'sean' and they have Sense values of «2», «3.1», «3.2», «5» and «6». The following code however only yields four records, with Sense values of «2», «3», «5» and «6»: sltb1 := sldb.GetTable ('SELECT Form, Sense FROM FormSenses where Form = ''sean'''); for i := 0 to sltb1.Count-1 do begin ShowMessage (sltb1.FieldAsString (1)); sltb1.next end; Why are the values of Sense being truncated like this? In other records, «2.8.4» is truncated to «2.8», «2.1.11» is truncated to «2» but values like «2.3a» are not truncated. Thanks for your help.

Problem solved. I had two copies of the database in different directories, and the copy being accessed by this program was out of date. Ah well 😞

Using Delphi XE update 1 on Windows 10 Home. A project which I have not modified for some time will no longer compile. The sequence of messages is shown in attachments 1..4. I choose "Cancel" in attachment 3. The new messages say that certain entry points cannot be found in dclWindowsAzureManagement150.bpl and in AzureCloud150.bpl. The first of these files exists, see attachments 5..6. It was installed with XE and has not been changed. It appears and is ticked under "Install Packages". The second file does not exist and never has as far as I know. Since I last compiled this project I have updated Indy from 10.1.1 to 10.6.2 — but this project does not use Indy. Thanks for any help.

I think I have got around this by removing the three Indy design-time components from the "Installed Packages" for this project. I don' t know how they got in there. More importantly I don't understand why their presence caused these messages or how removing them solves the problem. I have other projects using the Indy design-time components and they do not give this problem.

This problem is similar to "tlsv1 alert protocol version" raised on this forum in December 2020. I have tried to understand the solution to that problem but I cannot follow it and I cannot know if it applies to my system. I wrote a Delphi program using units IdHTTP, IdSSLOPenSSL, etc. to access the Babelfy server (http://babelfy.org/guide#HowdoIobtainaBabelfyAPIkey? option HTTP API). The program worked until recently, but now gives "Error connecting with SSL. error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert ptorocol version". I gather that this may mean that the server has disabled something called TLS v1, but no information can be obtained about any such change, or what version of TLS is now required. In trying to follow the previous postings, my first step was to change a statement to the following LHandler.SSLOptions.SSLVersions := [sslvTLSv1, sslvTLSv1_1, sslvTLSv1_2]; where previously it has only sslvTLSv1. However the extra parameters are 'undeclared identifiers' in Delphi. I have Delphi XE Version 15.0.3953.35171 with update 1 installed, and (according to the Delphi Help) Indy.Sokets 10.1.1. Is it possible to say from this whether my system can support access to servers which have dropped TLS v1?

Project is now working with Indy 10.6.2 under XE. I don't know what made the difference — possibly I had missed adding sslvTLSv1_1 and sslvTLSv1_2 to one of the several SSLVersions assignments in the program. Thanks for the incredible help received on this list, especially to Remy. Now I want to re-enable Indy 10.1.1 alongside 10.6.2. So I will create a project and try setting project options to make it use 10.1.1 instead of 10.6.2. Without going into details, it seems that my 10.1.1 .dcu files are being picked up correctly, but I'm not so sure about my 10.1.1 .bpl and .dcp files. I have added the directories containing my 10.1.1 files of all three types to the project's search path, but it looks as if the bpls or dcps or both are pushed aside by the 10.6.2 files. So I want to exclude the 10.6.2 .bpl and .dcp files from this project. My 10.6.2 .bpl files are located in C:\Users\Public\Documents\RAD Studio\8.0\Bpl which is on the Windows system PATH (it's also the package output directory). Even if I remove this directory from the Windows path – which I can't do permanently as it may affect other projects — that does not help with the 10.1.1 project: although the directory is no longer listed by Windows in the system path, and after I decline XE's offer on startup (before a project is loaded) to add it to my system path, it nevertheless reappears prepended to the "path" as displayed by XE in Tools/Options/Environment Variables. And then when I try to install the 10.1.1 dclIndyCore150.bpl in the 10.1.1 project, I get "Another package with the same base name is already loaded" viz. the 10.6.2 one, even though no Indy package is showing in the "Install Packages" list. My 10.6.2 .dcp files are located in C:\Users\Public\Documents\RAD Studio\8.0\Dcp which is on the XE default search path ("inherited from base" and "inherited from environment options" as well) and on the XE library path (it's also the DCP output directory). I don't know how to remove it from "inherited from environment options", or how to do this without affecting my other projects.

EDIT: PUT THIS ON HOLD UNTIL I INVESTIGATE FURTHER Process Monitor revealed a load of Indy 10.1.1 .dcu files in the release and debug directories, where they were placed by the Delphi XE installation. I moved these 10.1.1 dcu files out to new directories not on any path, and added the directories containing the new 10.6.2 dcu files to the search path. The project now compiles, with sslvTLSv1, sslvTLSv1_1, sslvTLSv1_2 ... BUT ... when run it gives the original error "tlsv1 alert protocol version". I don't think this can be the fault of the server or of the openssl dlls, for the following reason. I cloned the project to another directory and ran it under the Delphi 10.4 community edition. It works perfectly there, to the same server, with Indy 10.6.2.0 (from Embarcadero), the same OpenSSL dlls (1.0.2u), the same selection of TLS versions (v1, v1_1, v1_2). But I don't want to be using two versions of Delphi, so I still want to get this project working in XE, like my other (non-SSL) projects. There must be something still not right about my upgrade of Indy under XE, but I have no idea what it could be. Just to be clear about your answer to a previous question: all I should have to do with the five created 10.6.2 .dcp files is to ensure they are on the Library path, and there is no need to drop the 150 suffixes — is that correct? (And of course to have removed the 10.1.1 files.)

I have repeated the upgrade from Indy 10.1.1 to Indy 10.6.2, after renaming or moving every vestige of 10.1.1 source or dcps or dcus (including some buried in ProgramData, and including those from Delphi 10.4 community edition, which I installed but never use), and otherwise following the instructions (or so I believe). The result was the same as before. In the IDE, sslvTLSv1_1 and sslvTLSv1_2 are still "undeclared identifiers". The line numbers shown when the cursor rests on sslvTLS1 or sslvSSLv2 or sslvSSLv23 or sslvSSLv3 is line 232, which is the line number in the 10.1.1 source file. The removal of 10.4 did make one small difference. With 10.4 present, the problem identifiers are underlined in red in the (XE) IDE. With 10.4 absent, they are not underlined, and when the cursor rests on them, we see "erroneous type". In either case, compilation produces "undeclared identifier". I am still uncertain about the following points: 1. I have not deleted the old Indy components from the project and recreated them. I don't think that is necessary? 2. About the .dcp files: When I compile Indy 10.6.2, I get five files called IndySystem150.dcp, IndyCore150.dcp, IndyProtocols150.dcp, dclIndyCore150.dcp, dclIndyProtocols150.dcp With Indy 10.1.1, I had two sets of three files each: IndySystem.dcp, IndyCore.dcp, IndyProtocols.dcp — a set in release and a set in debug. Should I have done something to convert the new dcps into two sets of three, dropping the 150 suffix, and ignoring the last two? How? I am getting close to giving up on performing this upgrade in the recommended way, and leaving the project in the deprecated (but working!) position of using sslvTLS1 in combination with one or more of the (older) SSL versions.

I think the situation is not retrieveable, and I need to start the upgrade of Indy over again. The problem appears to have been my reluctance to "remove" the various facets of the old version until after I had at least compiled the new one. I still won't be deleting them, but I can make sure to move or rename them in advance. The experience of packages gained so far will be a help, so grateful thanks for the help with that.

Yes, that's what I'm trying to do. The present state of play is as described in my reply yesterday to Lajos, which may have crossed with your message above.

I've got two source versions of IdSSLOpenSSL.pas on my machine, one is Indy 10.1.1 and one is Indy 10.6.2. The reason I have both is that I'm trying to upgrade from 10.1.1 to 10.6.2, while keeping 10.1.1 available where I can reinstall it if necessary later. I've tried to follow a correct upgrading process, and Delphi informs me that 10.6.2.0 is installed. But clearly the Delphi compiler is still using the variable definitions from 10.1.1, even though the 10.6.2 source has been compiled. I need to know where the compiler is getting these old definitions from. I've tried disabling (by renaming) all the IndyProtocols.dcp files on my computer — I think that's where the compiled source goes — but it makes no difference. One thing I have not done is to delete the old Indy components from the project and recreate them. I don't think that is necessary? About the .dcp files: When I compiled Indy 10.6.2.0, I got five files called IndySystem150.dcp, IndyCore150.dcp, IndyProtocols150.dcp, dclIndyCore150.dcp, dclIndyProtocols150.dcp With Indy 10.1.1, I had two sets of three files each: IndySystem.dcp, IndyCore.dcp, IndyProtocols.dcp — a set in release and a set in debug. Should I have done something to convert the new dcps into two sets of three, dropping the 150 suffix, and ignoring the last two? How?

sslvTLSv1_1 and sslvTLSv1_2 both still come up "undeclared identifier". According to "About Delphi XE", I now have Indy 10.6.2.0 installed. Could I be picking up the wrong .dcp file? At the moment, the following parameter combinations work (with this server anyway): 23 ; 1 & 2 ; 1 & 23 ; 1 & 3 ; 2 & 23 ; 1 & 2 & 23 ; 1 & 2 & 3 ; 1 & 23 & 3 ; 1 & 2 & 23 & 3 Other combinations give the original error (1); error creating sll context (2); handshake failure (3 ; 2 & 3 ; 23 & 3 ; 2 & 23 & 3) There are some strange results there, eg 1 and 2 each fail on their own, but work together. I can see no pattern.

I'm happy to report that the problem is solved, thanks of course to all the help I have had. All I had to do to finish off was to uninstall (using Component/Install Packages) the old dclIndyCore150.bpl and dclIndyProtocols150.bpl (taking careful note of where they were to allow reinstallation if necessary), and install the new versions from the same menu. Then, anywhere in the code that I had created LHandler := TIdSSLIOHandlerSocketOpenSSL.Create(nil); to introduce LHandler.SSLOptions.SSLVersions := [sslvTLSv1, sslvSSLv2, sslvSSLv23, sslvSSLv3]; which statement had either been absent or had only "sslvTLS1" as parameter. For the three runtime-only bpls, I had the three old versions in one directory and the three new versions in another. Both directories were on the Windows PATH variable. I simply renamed the three old versions to something else. The dcp files promised to be a problem. The old system had three run-time ones in a "debug" directory (on the project's "Debug DCU path") and three run-time ones in a "release" directory (on the project's "Library path"). The new system had created two design-time and three run-time ones, all in one directory, which is on the project's "Library path". I didn't make any changes there, and was surprised to find that the project now worked. Perhaps I was just lucky, for the moment. The changes should be easy to reverse if I ever need the old Indy version 10.1.1 again. Thanks again for all the help.

Many thanks again. I have to leave this project aside for a while, but I think I should be able to complete installation when I return to it, with the help I have received here.

Many thanks again for your patience. I've now compiled the five .dpks. The new files created are: • In "Package Output Directory": IndySystem150.bpl, IndyCore150.bpl, IndyProtocols150.bpl, dclIndyCore150.bpl, dclIndyProtocols150.bpl • In "DCP Output Directory": IndySystem150.dcp, IndyCore150.dcp, IndyProtocols150.dcp, dclIndyCore150.dcp, dclIndyProtocols150.dcp The above directories were empty before compilation. There were also loads of .dcu files and a few .proj files created. I'm satisfied that all the files of my original (10.1.1) Indy installation are unchanged. Note that I have NOT (yet) uninstalled anything. The next step seems to be "installation", but I'm not clear what that means. Is it about making the packages appear (or rather, updating them) in the IDE's Tool Palette? And is it then only the two design-time packages that require installation? In the IDE, do I: Open dclIndyCore150.proj, then Component/Install Packages? And then the same for dclIndyProtocols.proj? What files will that create, and how will I avoid disabling 10.1.1, which I might need for DataSnap in the future? It doesn't look like I can have two versions of Indy installed in the IDE at the same time. > you can install the 2 dcl Packages in the IDE if you want to (replacing the old one), or just update individual projects to reference the newer non-dcl packages as needed Does that mean that I might not need to (re)install anything, but just change Project Options to pick up the new files? Looking at the Indy 10.1.1 files, there are the five .bpl files in the \bin directory, all WITH the "150" suffix in their names and three .dcp files, all WITHOUT the "150" suffix, in lib\win32\debug and three others (smaller) in lib\win32\release. I suppose that's the structure I should be aiming for, but in different directories from 10.1.1. How do I get there, please?

Sorry to be so obtuse. I've not worked with packages before. > open the 5 .DPK packages directly in the IDE and then compile+install them from the Project Manager From the directory where I unpacked Indy-master.zip, I opened Indy-master\Lib\System\IndySystem150.dpk in the IDE. I got a warning that IndySystem150.dproj (I think) would be updated and a backup created. I gave that the go-ahead and I have a new IndySystem150.dproj in the \Lib\System directory, which did not exist in the zip file. IndySystem150.dpk has not changed. When I reopen IndySystem150.dpk in the IDE, I find myself in "IndySystem150 - Delphi XE - ProjectGroup1.groupproj." Is my next move to choose "Compile IndySystem150" from the "Project" menu? What will the compiled output be called and where will it be placed? The project option "Package Output Directory" has been set to $(BDSCOMMONDIR)Bpl (wherever that is! - there's a Bpl subdirectory under C:\Users\Public\Documents\RAD Studio\8.0, and it's empty). Do I need to change the package output directory to avoid disturbing the original IndySystem150.bpl in RAD Studio\8.0\bin, or does that only arise at the next step of "installation"? Where is my original installed version of the package anyway? These are among the files that were created long ago when Delphi XE was installed: RAD Studio\8.0\source\Indy10\System\IndySystem.dpk RAD Studio\8.0\bin\IndySystem150.bpl and other copies buried deep in ProgramData and in Users\AllUsers RAD Studio\8.0\lib\win32\debug\IndySystem.dcp RAD Studio\8.0\lib\win32\release\IndySystem.dcp

Two questions already about compilation and installation of Indy. 1. Is the batch file for installation in Delphi XE called FULLD_XE.BAT? I don't see such a file in Indy-master.zip. 2. The instructions for XE say "If you need to use DataSnap, then you will need to maintain the original Indy 10 packages for use in DataSnap projects. You can use a separate installation of Indy 10 for non-DataSnap projects." I don't use DataSnap but I don't want to rule it out unnecessarily for the future. How then can I make a "separate installation" of Indy 10, thus keeping the original packages installed where they are, given that "If Indy10 is installed, it must be uninstalled first"?

Thanks for clarifying the relationship between Delphi, Indy and OpenSSL. I'll try to recompile Indy for XE. Just for the record — it doesn't change anything significant, just makes things more consistent — the references in my last post on this thread to Studio/20.0 should instead have been to RAD Studio/8.0. The libeay32.dll and ssleay32.dll there are version 0.9.8.14. And lines 231–2 of IdSSLOpenSSL.pas actually read type TIdSSLVersion = (sslvSSLv2, sslvSSLv23, sslvSSLv3, sslvTLSv1)

Many thanks for replying. As I'm way out of my depth here, I don't want to try anything too ambitious, like recompiling Indy from source (if that is what your suggestion involves — I downloaded Indy-master.zip from your link and it seems to be all source) . The idea that Indy could be updated independently from the rest of Delphi is something I haven't yet come to terms with. So can I try your patience and ask: can I use compiled dlls instead, like libeay32.dll and ssleay32.dll? I've downloaded those (v 1.0.2.21) from https://github.com/IndySockets/OpenSSL-Binaries but simply placing them in the application directory changes nothing. There are no files called libeay32.dll or ssleay32.dll already on my computer, except in the system directories of installed applications. One of these directories is Program Files (x86)\Embarcadero\Studio\20.0\bin\subversion They are v 1.0.2.14. Could that be where Delphi finds them? My project search path consists of $(BDSLIB)\$(Platform)\release, $(BDSUSERDIR)\Imports, $(BDS)\Imports, $(BDSCOMMONDIR)\Dcp and $(BDS)\include, which doesn't seem to cover it. Also, Delphi tells me that the identifier sslvTLSv1 is defined at IdSSLOpenSSL.pas (232). The source of that file, apparently rev 1.40, in Program Files (x86)\Embarcadero\Studio\20.0\source\Indy10\Protocols, contains no such definition at that line, but lines 236–7 are type TIdSSLVersion = (sslvSSLv2, sslvSSLv23, sslvSSLv3, sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2) Nevertheless only the fourth of these is recognized by my Delphi as a defined identifier. But at least the programmer was aware of the other versions by name. I'm hoping there is some way to "activate" them with the least possible disturbance. The IdSSLOpenSSL.pas in Indy-master.zip and the one in my machine source are both labelled rev 1.40. They differ in a few ways, but not — as far as I can see — in any way that relates to this problem.

This simple test program places a number of strings in a single-column ListView. I don't understand why it behaves differently in virtual and non-virtual modes. In non-virtual mode, the strings are added directly to the ListView. In virtual mode, they are placed in a StringList, and linked from there to the ListView. When the strings are in place, the first item of the ListView is assigned to a local TListItem variable. Then another item (the 7th for example) is accessed (its caption is read and displayed). Then we look at the local TListItem again. In non-virtual mode, it has not changed. But in virtual mode, it now contains the 7th item, not the first. Is this expected behaviour? If so, why? Source and output attached. WNExploreUnit.pas [Sorry this file was wrong. See further message for the right file.]

Thanks for taking the trouble to give this explanation. I've also noticed that, in virtual mode, every item of a ListView has the same Top value of maxint. So its not possible to scroll to a numbered item by using their Items[index].Top property, but the method using DisplayRect (drBounds).Top, mentioned earlier in this thread, works.

I see now ... I should be working with the StringList rather than with ListView.Items. That never occurred to me. In virtual mode, what about code like ListItem := WordListView.FindCaption (0, 'a', true, true, false); WordListView.Scroll (0, ListItem.DisplayRect (drBounds).Top); For example, do I need to replace FindCaption by a search of the StringList? By way of explanation, it was while trying to debug such code that I became concerned about what was happening to ListItem, leading me to display its Index value. Although I no longer need to do this, it is still disconcerting that (in virtual mode) its value can change in the way that my test program showed. Thanks for pointing me in the right direction. @emailx45: I didn't explain it well. I am happy with non-virtual mode. My problem was with virtual mode, the change in value of ListItem between the two lines where its value was displayed.

The right source file this time — hopefully. WNExploreUnit.pas

Sorry, wrong source file. The right one will be posted asap.