Brian Warner

Yes. Delphi 12.1, FireMonkey, Win11 64-bit, compiling for Win64 platform. I have one table with 1.2M+ records. Using a TFDConnection and TFDTable to access it and a BindSourceDB component.DataSet the TFDTable. At design time, when I set TFDTable.Acitve = True, it takes < 1 sec to acknowledge the request. If only a TEdit is involved, then at run-time things are very fast. Try to display the table in a TStringGrid and run, it takes several minutes, and the task manager shows more than 1.2 GB before one of several error messages appears. I have the fetch options for both the TFDConnection and TFDTable to Rowset Size = 50 and the TStringGrid.Rowcount = 50. I've attached a screen shot to try to clarify the setup. I should note that if the program eventually displays, using the vertical scroll bar thumb allows very fast scrolling from the top of the table to the bottom. However, if I click the First or Last button on the navigator, it can take 10 seconds to go the top or bottom of the table. Clear Skies Brian D. Warner

Hi, Sorry, I meant to include what was needed. Delphi 11.2. VCL only. It is only after working on a form, closing/reopening it (less often), but (more often) after closing and restarting Delphi with the setup to return to the previous desktop on start up. I have tried with some bare bones forms. It seems, but is not certain, that the problem is more likely to occur when the anchor set to right, without left, as you would with a Close button at the bottom right of the form. The attached shows the mildest effect, note that controls have shifted a few pixels to the left compared to the right edge. They are set to Top/Right anchor on a TPanel with alBottom. However, in more dramatic examples, the Hide button would be somewhere under the Numbers checkbox. I've seen similar cases, mild to dramatic, when the buttons were at the top of form, also in a TPanel with alTop and with the same anchor settings. . Brian

I'm working Delphi 11.2, Win 10 Pro, 64-bit. Monitors all 96 dpi, 1920x1080 resolution. None of that ever changes. With many (most) forms, I get them designed as I want. For example, a close button near the bottom right corner, button A immediately to the right of TEdit1 (outside the margins settings), etc. I'm not working with the DFM files directly, just via the corresponding PAS file. Save the form (*.pas file). Close it. Open the unit again. Most times it comes up OK, sometimes not. However, close Delphi and restart, then all bets are off. On many forms (TForm descendent) the Feng Shui goes kablooey and I spend a lot of time redoing design. Any thoughts? Brian D. Warner

Hi, Thanks for the update. I suspect 12.x is their priority, as it should be. BTW the 12.1 install worked fine. I'm in the middle of a big project and don't want to try to migrate to 12. New stuff, yes, but not old for now. Once the project is "out the door" (is it really ever?), I'll migrate to 12. If I read correctly, I may as well hold off doing that until some new "in-line registration" 12.x is released,since that would require uninstalling and reinstalling, which means reinstalling all the GetIt packages, no?

Is there a way to change the path to the GetIt server in 11.2? It's been days since I've been able to access it. Using the browser access doesn't check for things already installed and, AFAIK, give access to any of the patches. D12.0 Pro is working fine though I get a sense that getting Patch 1 might be an adventure. Brian

I can't get to GetIt via Welcome page or Tools menu in either 11.2 or 12.0. Any further updates? Brian

Running Windows 10/11 Pro, 64-bit, 64-bit application. Delphi 11. GetIt is down, so I can't get exact Indy version but the bpls are *280. As my program starts, it checks the windows path and, if necessary, adds \AROOT\PROGRAMS\ to the path using Get/SetEnvironmentVariable. I've confirmed that the path statement has been altered. In that directory are the two SLL dlls, libeay32.dll and ssleay32.dll (v1.0.22.1). Whenever any program needing FTP or HTTPS under the \AROOT\PROGRAMS runs, it does this check. All of them work fine, i.e., they can do their Internet things. There are no instances of the dlls within the modified Windows PATH. In other words, everything is fine -until- a user tries, or at least this particular one. With the same setup, save using Windows HOME, when he tries to do an https GET, the attached error message is returned. If he puts the program in the same directory as the two dlls, then it works. I know it's ill-advised to put the dlls somewhere under windows, e.g., SYSTEM32, and it's not practical to have the pair in every directory with a program needing them. Any thoughts on what might solve the problem? I've put enough dents in the wall beating my head today. Brian D. Warner

Thanks for the replies. I think I'm on the right track. I thought about creating "simple" threads, each with its own TidFTP/SSLHandler pair but thought the TParallel.For loop might speed things along. Here's what I have so far. I'm hoping that "fully independent FTP clients" doesn't mean actually have separate forms, just one TidFPT/SSLHander component pair per "client", both setup with the necessary information to do an autologin to the correct server. IOW, independently, each does what's intended. type TDL = packed record FTP : TIdFTP; LI : TidFTPListItem; end; var DL := array[0..4] of TDL; { Each Cnx is a TidFTP component on the form that has its own SSL handler component } Cnx[0] := idFTPDL; Cnx[1] := idFTP1; Cnx[2] := idFTP2; Cnx[3] := idFTP3; Cnx[4] := idFTP4; Cnx[0].OnWork := nil; // disables code that updates a TPanel. for I := 0 to 4 do begin if (not Cnx[I].Connected) then begin Cnx[I].Connect; end; Cnx[I].OnWork := nil; end; try for I := 0 to 4 do begin Cnx[I].ChangeDir(ARemoteDir); end; var Idx : integer := 0; var Q : integer := 0; SetLength(DL, Idx); { Didn't use SetLength(DL, DirCount) since it contains one or more ditDirectory items. This leads to some issues below when distributing the file list to the five FTP components. } Cnx[0].List; var DirCount := Cnx[0].DirectoryListing.Count; for I := 0 to pred(DirCount) do begin if (Abort) then begin Exit; end; LI := Cnx[0].DirectoryListing[I]; if (LI.ItemType = ditFile) then begin Idx := Length(DL) + 1; SetLength(DL, Idx); J := Q mod 5; DL[Idx-1].FTP := Cnx[J]; DL[Idx-1].LI := LI; Inc(Q); end; end; { Here's the attempt at TParallel.For, to be replaced by implementing a set of TThread objects. I admit that I was learning about TParallel.For on the fly from Nick Hodges' book at 3AM.} try var LB : integer := Low(DL); var HB : integer := High(DL); TParallel.For(LB, HB, procedure(M : integer) begin try var ADL := DL[M]; if (Assigned(ADL.FTP) and Assigned(ADL.LI) and ADL.FTP.Connected) then begin ADL.FTP.Get(ADL.LI.FileName, ALocalDir + ADL.LI.FileName, True); end; except raise; end; end); except raise; end;

I'm looking for a kick start in the right direction. Is it possible to have multiple connections such that I can have more than one file download going at a time (a cheap version of FileZilla). Many of the software users will find FileZilla too large a leap for their skills. I presume each one requires its own TidFTP and SSLIOHandler pair. I've playing with putting the set in a TParallel.For loop but get a general "too many exceptions" in the debugger after a few seconds. Running outside the IDE doesn't give anything more specific about what's wrong. Generally, Use connection 1 to get file listing. Iterate through the directory listing to create an array of 0..4 of <IdFTP, FileName>. Go through that list such that up to five GET statements are running. I've disconnected the events so that there is no updating of controls, i.e., no need to call Synchronize. Thanks for any help. Brian