WillH

I've just tried your code with Indy version: 10.6.2.0. The SSL part works. I made a change for logging but that's it. Check that the dlls you have match the bitness of your compiled application. A 64bit application needs 64bit openSSL dlls. Otherwise use the latest Indy version or alternate HTTP code such as the ones included in mORMot based on the WinHTTP drivers. At some point tls1.3 will become the minimum and as far as I know Indy does not support it yet. add IdSSLOpenSSLHeaders to your uses clause. Add this -> Memo1.Lines.Add('Indy version: ' + IdHTTP.Version); ssl.OnStatusInfoEx := IdSSLIOHandlerSocketOpenSSL1StatusInfoEx ; Change this -> ssl.SSLOptions.Mode := TidSSLMode.sslmUnassigned; Add this handler -> procedure TForm2.IdSSLIOHandlerSocketOpenSSL1StatusInfoEx(ASender: TObject; const AsslSocket: PSSL; const AWhere, Aret: Integer; const AType, AMsg: string); begin memo1.Lines.Add(Amsg) ; end; The output I get is Indy version: 10.6.2.0 Authorization: Bearer muj_token Dropbox-API-Arg: { "autorename": false,"mode": "add","mute": false,"path": "/test.txt","strict_conflict": false} Content-Type: application/octet-stream before/connect initialization before/connect initialization SSLv3 write client hello A SSLv3 read server hello A SSLv3 read server certificate A SSLv3 read server key exchange A SSLv3 read server done A SSLv3 write client key exchange A SSLv3 write change cipher spec A SSLv3 write finished A SSLv3 flush data SSLv3 read server session ticket A SSLv3 read finished A SSL negotiation finished successfully SSL negotiation finished successfully close notify Followed by Error HTTP/400 Bad Request.

Try setting SSLOptions.SSLVersions to include sslvTLSv1_2 indySSLHandler.SSLOptions.SSLVersions := [sslvTLSv1_2] ; Regards, Will.

Rather than dumping old unmaintained projects, I'd rather they open sourced elements of the existing offering so that the community can help to improve things. The RTL and associated unit tests would be a good start.

There was a big discussion about this a while ago. After a lot of messing about it seems that registration bumps are now done by sales. The rather unclear message seemed to be that sales would try to sell you something but you would get your bump for free if you choose not to buy anything. Although, despite multiple people asking Atanas Popov for clarification, there wasn't anything clear forthcoming. Another major mis-step by Emba. Let us know how you get on with sales.

Indy does not support SSH. I use securebridge which is great for SSH and SFTP. Not free though. https://www.devart.com/sbridge/

I always felt that Nick Hodges had the cojonnes but sadly did not manage to influence the bean counters. It seems that the bean counters find it difficult to place a value on Quality, credibility and trust.

Are Emba doing any unit testing? Clearly, either this isn't tested or isn't sufficiently tested. Is any of the RTL being unit tested?

This looks like a threading issue in FireDAC. When you add a new event listener the event listener unregisters all the events it has and then registers everything again. I've traced it back to uADPhysManager (Yes I have the older source code, but I imagine things are pretty similar in your source) I think that stopping the listener thread is failing because there is an inbound event. procedure TADPhysEventAlerter.AbortJob; begin try InternalAbortJob; FMsgThread.Active := False; // Locks here except // not visible end; end; Just changing your code to use unregister will also trigger the problem. procedure TForm1.Button1Click(Sender: TObject); begin FConn.ExecSQL('EXECUTE BLOCK AS BEGIN POST_EVENT ''EVENT_1''; END'); FEvents.Unregister; end; Maybe, if you don't have many events you could try one event alerter instance per event. I don't get the same error with IBX TIBEvents so maybe you could use that for the event alerts instead.

Hi Bill, Of course you are correct that the way the product is used will affect performance. However, I think that it's a fair test to use the same project and associated third party components to form an opinion on relative performance between the IDE's. After turning off live bindings, the 10.2.3 IDE is running better although still very noticeably slower than XE. Mostly, the slowness is in the form designer when looking at relatively complex screens. This appears to be a fairly common complaint about the IDE's since livebindings were introduced. Maybe it is time for me to break up and simplify the affected screens to work with the IDE a bit more.

See http://docwiki.embarcadero.com/RADStudio/Rio/en/Database_Alerts_(FireDAC) Try setting FEvents.Options.Synchronize := True;

I found a similar bug where the Firebird client will lock up if you try to create two connections at the same time in different threads. In my case I could only reproduce it when a local connection was used. I had to change the API call in IBX so that it was wrapped in a critical section. IBIntf.pas //Create and destroy the critical section in the initialization and finalization sections. ConnLock : TCriticalSection ; function TDynamicLibrary.isc_attach_database(status_vector: PISC_STATUS; db_name_length: Short; db_name: PAnsiChar; db_handle: PISC_DB_HANDLE; parm_buffer_length: Short; parm_buffer: PByte): ISC_STATUS; begin ConnLock.Acquire ; try Result := Fisc_attach_database(status_vector, db_name_length, db_name, db_handle, parm_buffer_length, parm_buffer); finally ConnLock.Release ; end; end; So, have a look at the API call that is being made to make sure it is thread safe. Wrap your calls in a critical section. On a similar note. The events may be getting raised in the context of a background thread, So updating the form caption from that event may be the cause of your lock up. Try using PostMessage to pass the event to the main form in a thread safe way. Or use OutputDebugString for the purposes of your test.

Hi All, Thanks for the replies. I'm currently using Delphi XE. It's worked well for me, fairly quick, mostly stable, gets the job done. Now I have third party component vendors providing features I need but only for newer Delphi versions. XE2 is supported at the moment but I imagine it will be next for the chop. I've tried 10.2.3 which seems OK but it is so slow, especially in the forms designer. I'll try the others mentioned in this thread to see if they are any better. At least I won't need to install and try every single version since XE. It's interesting that most people seem to prefer the very old versions of Delphi and *almost* universally dislike 10.3.1. That is surely something that Embarcadero need to focus on. If their focus is on extracting as much money as possible from existing customers, I would imagine that no new feature (or skin) would beat a stable and responsive IDE.

Hi Everyone, Just wondering which has been the best release of Delphi so far in terms of IDE stability and 32-bit VCL development? (and possibly 64-Bit windows) Have any been particularly good/bad for you?

Like Remobjects ? https://blogs.remobjects.com/2018/03/22/delphi-visual-library-on-webassembly-platform/

Could you use odometer ? https://en.wikipedia.org/wiki/Odometer