giomach

Thanks for your replies. FocalForm is the only form in my application. The code snippet occurs in the implementation section of the form, but in a procedure which is not declared as a member of the TFocalForm class.(Perhaps the procedure could/should be so declared, if that would make any difference in this case.) At present, the statement FocalFormResult := FocalForm.LemmaListBox.ShowModal; produces the error undeclared identifier:'ShowModal'. I'm guessing that I would have to create a second form/unit just to hold the TListBox before I can use ShowModal on it. If that's so, I think I prefer my present method which keeps the TListBox integrated with the rest of the form, so that eg. I can control its placement, and I can allow some of the other controls to remain accessible while the TListBox is waiting to be clicked.

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.

A rather basic question, sorry. In the middle of a fairly large program, I want to put some items in a TListBox, display it, click on an item, and continue the program taking account of the item clicked. My code is like this: FocalForm.LemmaListBox.Clear; FocalForm.LemmaListBox.Show; for i := nwordfirst to nwordlast do begin getword (i, jstoretmp, jhmgrphtmp, whead, nheadlast); FocalForm.LemmaListBox.Items.Add (jstoretmp); end; {x} nwordfirst := nwordfirst + FocalForm.LemmaListBox.ItemIndex; etc. When this is run, the ListBox is displayed correctly, but there is no opportunity to click it, and the program carries on with ItemIndex = -1. I've tried setting focus to the ListBox but it makes no difference. I can get the desired result by inserting the following code at point {x}: repeat Application.ProcessMessages until Focalform.LemmaListBox.Visible = false; and having the ListBox OnClick set Visible to false. But I am uneasy with that technique — is there a better way? Thank you.

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 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.

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.

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.

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.