jaenicke

He needs help to make a pull request, because this fix should be included in the INDY source. Perhaps someone can do this for him. I do not have the time at the moment, otherwise I would have done it already when I saw the german post.

I found it: One has to implement WMNCCalcSize in the form and, if the window is maximized, decrement NCCalcSizeParams.rgrc[0].Bottom or NCCalcSizeParams.rgrc[0].Right by one, so the taskbar can be activated there.

Hello, in Delphi 10.4 and Delphi 11 there is a problem with the taskbar. If you use the CustomTitleBar and maximize the window, the taskbar does not show up if it is set as automatically hidden. This applies to own programs as well as to the Delphi IDE. Since this has been fixed with Delphi 12, I no longer need to create a bug entry and there was already one for the Delphi IDE, in which I wrote that it works with Delphi 12. My problem now is that I have no idea what change in the VCL did the fix. I already searched, but have not found anything suitable. I have transferred the Vcl.TitleBarCtrls unit completely as a test, but that was not successful. Does anyone have any idea where the cause of the problem could lie, so that I can transfer the fix to Delphi 10.4? Many thanks to all readers! Sebastian

What about using a second DLL? You could write this new DLL with Delphi Community Edition, where you can use newer components. Then you can load this new DLL by your old DLL and just redirect the calls to the new DLL. This way you do not have to upgrade your existing code, but you can use WebView4Delphi though.

Thank you! I didn't pay attention to this call as I do not make many calls, so speed does not matter. But of course I'll use this now that I am aware of it. There the error handling works correctly, though I would prefer not to get an exception, as I can configure it when calling the Get method. LibeayLoad always returns true instead. But it is not important as this is called only once. Thank you for your help!

I first used interfaces via exported DLL functions. This was better than using many individual DLL functions, but still not very flexible. So I thought about how to implement the whole thing in a more general way. The result is this project. With AppCentral you can register interfaces in the host application or a DLL and get them in the host application or another DLL. The DLL can thereby also be written in C#, which is very practical, because you can connect various .NET libraries very well with Delphi. Example: Register an interface in Delphi type IAppDialogs = interface ['{EA3B37D8-5603-42A9-AC5D-5AC9C70E165C}'] procedure ShowMessage(const AMessage: WideString); safecall; end; TAppDialogs = class(TInterfacedObject, IAppDialogs) public procedure ShowMessage(const AMessage: WideString); safecall; end; implementation { TAppDialogs } procedure TAppDialogs.ShowMessage(const AMessage: WideString); begin Vcl.Dialogs.ShowMessage(AMessage); end; initialization TAppCentral.Reg<IAppDialogs>(TAppDialogs.Create); finalization TAppCentral.Unreg<IAppDialogs>; Fetch the interface in the host application or a DLL TAppCentral.Get<IAppDialogs>.ShowMessage('This is a message!'); // fetch directly, an exception will occur, if the interface is not registered yet Or in C# if (AppCentral.TryGet<IAppDialogs>(out IAppDialogs Dialogs)) { Dialogs.ShowMessage("Message from DLL: C# DLL registered!"); } The project can be downloaded here: https://github.com/jaenicke/appcentral Demo applications are included in source and in compiled form. I'll add a quick start manual soon.

Yes, but the problem ist, that I get this: But I should get: I had to search for the error, because the error message from the log did not tell me anything.

I only wanted to make an SSL call, so I don't think this is a very unusual call. A small example is: uses OverbyteIcsHttpProt, OverbyteIcsLogger, OverbyteIcsWSocket; procedure Test; var SslHttpCli: TSslHttpCli; begin SslHttpCli := TSslHttpCli.Create(nil); try SslHttpCli.SslContext := TSslContext.Create(SslHttpCli); SslHttpCli.URL := 'https://www.example.com'; SslHttpCli.IcsLogger := TIcsLogger.Create(SslHttpCli); SslHttpCli.IcsLogger.LogOptions := [loSslInfo]; SslHttpCli.Get; finally SslHttpCli.Free; end; end; The access violation happens, when Get is called. Of course not all calls can be checked, but I would recommend to do it in IcsX509VerifyErrorToStr, because it is used inside the error handling. You could do it this way: function IcsX509VerifyErrorToStr(ErrCode: Integer): String; begin {$IFNDEF OPENSSL_USE_RESOURCE_STRINGS} if Assigned(X509_verify_cert_error_string) then Result := String(AnsiString(X509_verify_cert_error_string(ErrCode))) else {$ENDIF} case ErrCode of X509_V_OK : Result := sX509_V_OK; X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT: Result := sX509_V_ERR_UNABLE_TO_GET_ISSUER_CERT; X509_V_ERR_UNABLE_TO_GET_CRL: Result := sX509_V_ERR_UNABLE_TO_GET_CRL; X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE: Result := sX509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE; X509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE: Result := sX509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE; X509_V_ERR_UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY: Result := sX509_V_ERR_UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY; X509_V_ERR_CERT_SIGNATURE_FAILURE: Result := sX509_V_ERR_CERT_SIGNATURE_FAILURE; X509_V_ERR_CRL_SIGNATURE_FAILURE: Result := sX509_V_ERR_CRL_SIGNATURE_FAILURE; X509_V_ERR_CERT_NOT_YET_VALID: Result := sX509_V_ERR_CERT_NOT_YET_VALID; X509_V_ERR_CRL_NOT_YET_VALID: Result := sX509_V_ERR_CRL_NOT_YET_VALID; X509_V_ERR_CERT_HAS_EXPIRED: Result := sX509_V_ERR_CERT_HAS_EXPIRED; X509_V_ERR_CRL_HAS_EXPIRED: Result := sX509_V_ERR_CRL_HAS_EXPIRED; X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD: Result := sX509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD; X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD: Result := sX509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD; X509_V_ERR_ERROR_IN_CRL_LAST_UPDATE_FIELD: Result := sX509_V_ERR_ERROR_IN_CRL_LAST_UPDATE_FIELD; X509_V_ERR_ERROR_IN_CRL_NEXT_UPDATE_FIELD: Result := sX509_V_ERR_ERROR_IN_CRL_NEXT_UPDATE_FIELD; X509_V_ERR_OUT_OF_MEM: Result := sX509_V_ERR_OUT_OF_MEM; X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: Result := sX509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT; X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN: Result := sX509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN; X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY: Result := sX509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY; X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE: Result := sX509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE; X509_V_ERR_CERT_CHAIN_TOO_LONG: Result := sX509_V_ERR_CERT_CHAIN_TOO_LONG; X509_V_ERR_CERT_REVOKED: Result := sX509_V_ERR_CERT_REVOKED; X509_V_ERR_INVALID_CA: Result := sX509_V_ERR_INVALID_CA; X509_V_ERR_INVALID_NON_CA: Result := sX509_V_ERR_INVALID_NON_CA; X509_V_ERR_PATH_LENGTH_EXCEEDED: Result := sX509_V_ERR_PATH_LENGTH_EXCEEDED; X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED: Result := sX509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED; X509_V_ERR_PROXY_CERTIFICATES_NOT_ALLOWED: Result := sX509_V_ERR_PROXY_CERTIFICATES_NOT_ALLOWED; X509_V_ERR_INVALID_PURPOSE: Result := sX509_V_ERR_INVALID_PURPOSE; X509_V_ERR_CERT_UNTRUSTED: Result := sX509_V_ERR_CERT_UNTRUSTED; X509_V_ERR_CERT_REJECTED: Result := sX509_V_ERR_CERT_REJECTED; X509_V_ERR_APPLICATION_VERIFICATION: Result := sX509_V_ERR_APPLICATION_VERIFICATION; X509_V_ERR_SUBJECT_ISSUER_MISMATCH: Result := sX509_V_ERR_SUBJECT_ISSUER_MISMATCH; X509_V_ERR_AKID_SKID_MISMATCH: Result := sX509_V_ERR_AKID_SKID_MISMATCH; X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH: Result := sX509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH; X509_V_ERR_KEYUSAGE_NO_CERTSIGN: Result := sX509_V_ERR_KEYUSAGE_NO_CERTSIGN; X509_V_ERR_UNABLE_TO_GET_CRL_ISSUER: Result := sX509_V_ERR_UNABLE_TO_GET_CRL_ISSUER; X509_V_ERR_UNHANDLED_CRITICAL_EXTENSION: Result := sX509_V_ERR_UNHANDLED_CRITICAL_EXTENSION; X509_V_ERR_KEYUSAGE_NO_CRL_SIGN: Result := sX509_V_ERR_KEYUSAGE_NO_CRL_SIGN; X509_V_ERR_KEYUSAGE_NO_DIGITAL_SIGNATURE: Result := sX509_V_ERR_KEYUSAGE_NO_DIGITAL_SIGNATURE; X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION: Result := sX509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION; X509_V_ERR_INVALID_EXTENSION: Result := sX509_V_ERR_INVALID_EXTENSION; X509_V_ERR_INVALID_POLICY_EXTENSION: Result := sX509_V_ERR_INVALID_POLICY_EXTENSION; X509_V_ERR_NO_EXPLICIT_POLICY: Result := sX509_V_ERR_NO_EXPLICIT_POLICY; { V8.39 lots more } X509_V_ERR_UNNESTED_RESOURCE: Result := sX509_V_ERR_UNNESTED_RESOURCE; else Result := sX509_V_ERR_NUMBER + IntToStr(ErrCode); end; end; Of course the resource strings have to be available as well. This way the error handling works correctly, if the DLL is not loaded (if it is neccessary, I don't know, whether any of those errors can occur then) and the correct error is displayed / logged.

I had activated loSslInfo as LogOption. Then I got an access violation on another machine. The problem is: - TCustomSslWSocket.StartSslHandshake calls FSslContext.InitContext - An exception is raised, because libcrypto-1_1.dll is missing - This exception is handled in TCustomSslWSocket.StartSslHandshake, but inside the except block TriggerSslHandshakeDone is called. This would be no problem, if IcsX509VerifyErrorToStr would not be called there for logging purposes. In this function X509_verify_cert_error_string is used, which is nil, because the library is missing. I think this is a bug. Am I right? Thank you

Sure, I knew the post, but at the moment it was written the problem I found was neither known nor fixed, so we should instead hope, that 11.3 does not come too fast. 😀

Das hatte ich tatsächlich nicht gelesen. Allerdings ist es schon ein Unterschied, ob es "nur" langsamer ist (beim Kompilieren in dem Fall) oder der LSP schlicht gar nicht mehr geht. Sprich der geht auf "Angehalten", arbeitet also auch nicht langsam weiter.

Important hint regarding LSP Yesterday I noticed that with both Delphi 10.4 and Delphi 11, an invalid path reliably knocks out the LSP. (Yes, this is reported and goes its way). This invalid path can be at least in the system PATH, the library path and unfortunately already simply the search path. You can easily test this yourself by entering a non-existent path there and restart Delphi. Important: If you correct it, you may have to restart Windows. For some reason it is not always enough to restart Delphi and the DelphiLSP.exe (even if the system PATH is not changed). I haven't looked into that yet and it doesn't always happen.

Important hint regarding LSP Yesterday I noticed that with both Delphi 10.4 and Delphi 11, an invalid path reliably knocks out the LSP. (Yes, this is reported and goes its way). This invalid path can be at least in the system PATH, the library path and unfortunately already simply the search path. You can easily test this yourself by entering a non-existent path there and restart Delphi. Important: If you correct it, you may have to restart Windows. For some reason it is not always enough to restart Delphi and the DelphiLSP.exe (even if the system PATH is not changed). I haven't looked into that yet and it doesn't always happen.

Thank you! I had found out, that the rest component has more functionality than the HttpCli, but had overlooked the property CertVerMethod.

Hello, I tried to verify a certificate chain when accessing a simple https page (for example https://www.google.de). I tried ICS and Indy, but as both use OpenSSL I got the same error 20: I know what this means. OpenSSL does not access the local certificate store under Windows and thus cannot find the root certificate locally. I know, that I can provide a certificate manually, so it can be checked. But why is this neccessary? ICS has code to access the Windows certificate store and verifying the peer is an absolute routine task. I searched for hours to find such functionality, because I cannot believe, that this basic task needs so much manual work. I found OCSP functionality and other cool stuff (code to verify a cert chain in ICS, ...), but not what I needed (verification of the root cert in the chain as well using the system store). So my question is: Did I not find this functionality or is it really missing? I would have expected this to work just by activating peer verification in both frameworks (so the AOk parameter should be set to true, when the OnVerifyPeer events are called). Thank you in advance Kind regards Sebastian