Leaderboard

Your code logic sounds backward. You should run code in FormCreate inside the calling form and then depending on the result create TChangesLogForm or not. Or if the code really belongs to TChangesLogForm, you should not run that code within FormCreate, but after the form is shown (along with some indication that there is a work in progress) and then if there is an error retrieving the data, you can show error message and close the form in that moment.

I created a simple demo project for mORMot web framework and Sempare Template Engine, both are the most powerful ones in their own catalogs, thus worth knowing how they can work together.

A new version is available at https://github.com/rmesch/Repository-R.Schaaf. The parallel resampler can now be used in concurrent threads. You can define more than one thread pool for the resampling and tell the parallel procedure which pool to use. A new demo "ThreadsInThreads" has been added. Initially I had the problem that this demo would sometimes hang waiting for an event, but that has hopefully been fixed. I'd much appreciate a feedback if it still occurs. Thanks, Renate

For most projects, we want to be able to pass some custom values when starting it. We have ParamStr and ParamCount global functions, enough to retrieve the basic information. But not enough when you want to go any further. We just committed a new command line parser to our Open Source mORMot 2 framework, which works on both Delphi and FPC, follows both Windows not POSIX/Linux conventions, and has much more features (like automated generation of the help message), in an innovative and easy workflow. The most simple code may be the following (extracted from the documentation): var verbose: boolean; threads: integer; ... with Executable.Command do begin ExeDescription := 'An executable to test mORMot Execute.Command'; verbose := Option(['v', 'verbose'], 'generate verbose output'); Get(['t', 'threads'], threads, '#number of threads to run', 5); ConsoleWrite(FullDescription); end; This code will fill verbose and threads local variables from the command line (with some optional default value), and output on Linux: An executable to test mORMot Execute.Command Usage: mormot2tests [options] [params] Options: -v, --verbose generate verbose output Params: -t, --threads <number> (default 5) number of threads to run So, not only you can parse the command line and retrieve values, but you can also add some description text, and let generate an accurate help message when needed. More information available at https://blog.synopse.info/?post/2023/04/19/New-Command-Line-Parser-in-mORMot-2

I was digging into some code that leverages a custom AssertErrorProc to handle some unique errors in an app and I examined the help page (https://docwiki.embarcadero.com/CodeExamples/en/AssertErrorProc_(Delphi)) which states in a code comment: { No local variables. Not compiler generated temporary variables. } { Using the call stack here will cause Access Violation errors. The routine I'm looking at uses a local variable...so the question is what is the downside of doing so? I couldn't find much info on this - few blog entries. http://www.blong.com/Conferences/BorCon2002/Debugging/3188.htm http://www.blong.com/Conferences/DCon99/VCLSourcery/VCLSourcery.htm https://blog.matthewskelton.net/2012/01/29/assert-based-error-reporting-in-delphi/ I asked ChatGPT "In Delphi, you can reassign the default error handler for assertions by leveraging the AssertErrorProc system variable. In the help file it is stated not to use local variables within this custom error procedure. Why would that be a problem?" Which responded: "The reason for not using local variables within the custom error procedure assigned to the AssertErrorProc variable in Delphi is that the procedure is called at a very low-level when an assertion fails. When an assertion fails, Delphi's runtime system calls the custom error procedure pointed to by AssertErrorProc. At this point, the program is in an unknown state, and the system stack may be corrupted. In this situation, local variables may not behave as expected, leading to unpredictable results or even crashes. To avoid this problem, it is recommended to keep the custom error procedure as simple as possible and avoid using local variables or other resources that may rely on a stable system state. It's also a good idea to log any relevant information about the error before attempting to handle it, as the program's behavior may be unpredictable after an assertion failure." Does anyone have further insight? Currently it's just a matter of curiousity and I'm not tracking down a specific error.

or just scanning for both

ICS V8.66 has been released at: http://wiki.overbyte.eu/wiki/index.php/ICS_Download ICS is a free internet component library for Delphi 7, 2006 to 2010, XE to XE8, 10 Seattle, 10.1 Berlin, 10.2 Tokyo, 10.3 Rio and 10.4 Sydney, and C++ Builder 2006 to XE3, 10.2 Tokyo, 10.3 Rio and 10.4 Sydney. ICS supports VCL and FMX, Win32, Win64 and MacOS 32-bit targets. The distribution zip includes the latest OpenSSL 1.1.1k win32, with other versions of OpenSSL being available from the download page. Changes in ICS V8.66 include: 1 - Added a new TIcsInetAlive component to check for IPv4 and/or IPv6 internet connectivity, using Ping and/or HTTP, defaulting to www.msftconnecttest.com run by Microsoft for Windows 10 alive checking. The online and offline check intervals may be set, and event fires when online state changes. Sample OverbyteIcsHttpRestTst has a demo for new component. 2 - OpenSSL 1.0.2 and 1.1.0 ceased security fix support over 12 months ago so ICS now only supports 1.1.1, with 3.0 support due in the next few months. This removes a lot of legacy code and functions, and several old ICS functions needed for backward compatibility. Two components only used for 1.0.2 have been removed, TSslStaticLock and TSslDynamicLock which may give an error loading forms, until they are removed. SslContext SslOptions is now ignored, use SslOptions2 instead which has more modern options. Can not remove SslOptions because it's saved on too many DFMs. Most modern applications should not be using SslConext, but IcsHosts for servers for high level client components like TSslHttpRest. 3 - Undertook a major clean-up of OpenSSL functions that may require end user application changes if low level OpenSSL functions have been used, hopefully very rarely. All OpenSSL functions have been renamed to their original names removing ICS f_ prefix for commonality with other Delphi applications. Renamed literals BIO_CTRL_PENDING_, CRYPTO_NUM_LOCKS_, CRYPTO_LOCK_, OPENSSL_VERSION_ with underscore to avoid conflicts with functions of the same case sensitive names. Removed unit OverbyteIcsLibeayEx not used for a while. Most OpenSSL type pointers to Dummy array are now simple Pointer type. Changed most OpenSSL var parameters to pointers for commonality. New TSslWSocket method SslOK is TLS/SSL negotiated OK. LoadVerifyLocations no longer lets OpenSSL use default CA folder locations which is potentially a security risk. 4 - Bring server SSL/TLS security levels up to latest Mozilla recommendations. In 2021 Mozilla now recommends TLSv1.3 as modern ciphers and TLSv1.2/1.3 as Intermediate supporting all browsers from last five years, so IcsHosts now use sslCiphersMozillaSrvTLS12 as Intermediate level, also Mozilla recommends no cipher server preference so changed that. Updated SslSrvSecurity levels: sslSrvSecInter, sslSrvSecInterFS and sslSrvSecHigh now all the same TLSv1.2 or 1.3, sslSrvSecTls12Less now TLSv1.2 only, sslSrvSecSsl3 not supported, only sslSrvSecBack supports TLSv1 and 1.1, sslSrvSecTls13Only unchanged TLSv1.3 only. 5 - Added support for YuOpenSSL which provides OpenSSL in a pre-built DCU statically linked into applications, rather than using external OpenSSL DLLs. This make application distribution more reliable since it can not fail by users deleting the DLLs or copying incompatible versions into the directory. YuOpenSSL is a commercial product from https://www.yunqa.de/ and is supplied as separate compiled DCUs for Delphi 5 to 10.4. DEFINE YuOpenSSL in Include\OverbyteIcsDefs.inc determines whether the DCU is linked or the external DLLs. Note only one version of OpenSSL can be linked with YuOpenSSL, whereas different DLLs can be supported. Apart from setting the define and adding a path to YuOpenSSL.dcu, no other application code changes are needed unless you check or report the DLL directory, when GSSLStaticLinked can be checked to see if OpenSSL is statically linked. Also worth noting that YuOpenSSL provides access to the all OpenSSL APIs, while ICS only accesses those DLL APIs needed for functionality we support. 6 - Added a better way of configuring Socks proxy and HTTP Tunnel proxy settings in TWSocket, similarly to that added for THttpCli in V8.62. The new ProxyURL property sets SOCKS or HTTP Tunnel proxy settings using a single URL, ie proto://[user:password@]host:port where proto is socks5 or http. Also added new methods SetSocks and SetHTTPTunnel to set proxy properties in a single call. Socks proxy and HTTP tunnelling again support host names, broken in V8.56. The sample OverbyteIcsSocksTst has been updated to demonstrate use of the new ProxyURL property and also now supports HTTP Tunnel proxy. 7 - TIcsRestEmail has new OAAuthType property and event for OAuth2 browser URL perhaps via email for servers. TIcsRestEmail now sets OAuth2 errors, and clears old tokens. Increased default timeout for TIcsRestEmail AOuth2 login to 120 seconds since several web page warnings may be seen while attempting to login through the web page. 8 - TIcsHttpMulti has a new ParseLevels property that follow links on a parsed web page to lower level pages, which are also parsed, looking for files to download with a specific file extension, ie .avi. It ignores parent links without a file extension, and external links. This allows the component to download files indexed using HTTP from CCTV camera memory cards. 9 - In TSslHttpRest ensure SSL is initialised for non-REST HTTP requests like GET, POST and PUT. 10 - In TSslWSocketServer, added better error handling when IcsHosts SslCert is blank, so SslContext is still created for automatically created self signed certificates. 11 - In TSslWSocketServer, TSslHttpAppSrv and TSslHttpSrv, added new onBeforeCtxInit event which if set is called once before each IcsHosts SslContext is initialised to allow the context parameters to be adjusted for special ciphers or protocols. 12 - In THttpCli, AddrResolvedStr is now still available after the connection closes to report the IP address used for the connection. When using an HTTPS proxy with the CONNECT command don't send host and port which some servers are unable to handle, probably broken with V8.64. 13 - In TIcsMailQueue, added a new method CheckOAuthLogins that should be called before the queue starts when using OAuth2 email logins, which allows interactively checking with a browser of any OAuth2 login credentials, avoids asking for login first time email sent maybe days later. 14 - In TSslX509Certs, When starting the local web server for file challenges, check the server IP address still exists or change to 0.0.0.0, may not work if multiple IPs exist. 15 - Updated to OpenSSL 1.1.1k with two high security fixes, one introduced in the last version relating to a certificate chain validation that ICS does not use, the other relating to servers using TLSv1.2 and renegotiation, and that feature is removed in V8.66.

Sounds like this here to me: https://quality.embarcadero.com/browse/RSP-40939

You should move this code to a class procedure in that case you can execute the dialog before you create the form. If it's a modalform before wm_close you have to set the modalresult. I've tested in Delphi 11.2: procedure TForm2.FormCreate(Sender: TObject); begin if not OpenDialog1.Execute then begin modalResult:=mrCancel; PostMessage(handle, wm_close, 0, 0); end; end;

Hej Anders, thank you again for the dedicated help! As I had some to do some clean-up in another project, this one received a little less attention. But some progress is there: - the save I could just use from the Layers-example 😉 - the OnConstraint works (I was using OldLocation instead of new - along the lines of NewLocation := OldLocation div x etc. So I have quite a bit of work left to do but the project is alive! 😄

The FIdSSLIOHandler.PassThrough property is True by default, so the connection is treated as a plain TCP connection. You need to set the PassThrough property to False to initialize the TLS handshake. So, that is why you are getting the error on your 1st Send(). Your application data is the 1st thing being transmitted, so the server is mistaking that as the TLS handshake, hence the error. You can set the PassThrough to False either before calling Connect() (ie, for implicit TLS, sending the handshake as soon as the TCP connection is established) or afterwards (ie, for explicit TLS, to allow for a protocol-level STARTTLS-style command before sending the handshake): procedure myFoo; var FIdTCPClient : TIdTCPClient; FIdSSLIOHandler : TIdSSLIOHandlerSocketOpenSSL; begin FIdTCPClient := TIdTCPClient.Create; FIdTCPClient.Host := '10.10.10.10'; FIdTCPClient.Port := 10007; FIdSSLIOHandler := TIdSSLIOHandlerSocketOpenSSL.Create; FIdSSLIOHandler.SSLOptions.Mode := sslmClient; FIdSSLIOHandler.SSLOptions.VerifyMode := []; FIdSSLIOHandler.SSLOptions.VerifyDepth := 0; FIdSSLIOHandler.SSLOptions.SSLVersions := [sslvTLSv1_2]; FIdTCPClient.IOHandler := FIdSSLIOHandler; FIdSSLIOHandler.PassThrough := False; // <-- either here FIdTCPClient.Connect; // <-- will send the handshake if PassThrough is False FIdSSLIOHandler.PassThrough := False; // <-- or here, optionally after sending a STARTTLS command FIdTCPClient.Send([0,1,2,3]); end; That is because you are explicitly setting Sock.SslEnable to True and then calling Sock.StartSslHandshake() after calling Sock.Connect(). You are not doing the equivalent with Indy. No, it is a bug in your code. You are telling ICS to initiate the TLS handshake, but you are not telling Indy to do the same. This is not a new issue in 11.3. This is how Indy has always behaved. Yes - the PassThrough property. OpenSSL DLLs that are known to work with Indy are available in Indy's GitHub repo: https://github.com/IndySockets/OpenSSL-Binaries

@KodeZwerg That is basically the same answer as I gave yesterday... He probably got a screen dump of the source code as a jpg image and renamed the file to .pas thinking this is the way to get the actual source code 😄😄😄 Of course it isn't...

On the Delphi side you can use PyArg_ParseTuple to get the pointer to the python object. Then you can either: use the python API to call the desired method on the python object or wrap the python object into a custom variant (VarPythonCreate in the VarPyth unit) and call the method in a high-level way. See tutorials and demos on VarPyth for details