Remy Lebeau

Use the Win32 SHFileOperation() API to copy the file with the FOF_RENAMEONCOLLISION flag: If you need to know what the copied filename was renamed to, include the FOF_WANTMAPPINGHANDLE flag as well: Alternatively, on Windows Vista+, you can use the IFileOperation API instead, using IFileOperation.SetOperationFlags() to set the FOF_RENAMEONCOLLISION flag, IFileOperation.CopyItem() and IFileOperation.PerformOperations() to perform the copy, and if needed use an IFileOperationProgressSink event sink to discover the copied filename in the PostCopyItem event.

That is a known issue with postman. And how are you doing that, when there is no OnCommandGet event fired for that connection? The only option would be to use the OnConnect event, in which case you could instead just assign a ReadTimeout to the connection and let TIdHTTPServer close the connection when no request arrives.

You cannot delete a file that is in use, unless the app that is using the file explicitly permits the deletion (by specifying FILE_SHARE_DELETE when opening the file). Nobody does that under normal usage, so you will need to detect when this condition happens (check GetLastError() when the deletion fails) and then. either 1) retry the deletion later or 2) ask Windows to delete the file on the next reboot (via MoveFileEx(MOVEFILE_DELAY_UNTIL_REBOOT)).

A new Context is not created until a client is accepted. Only 1 Context is created per client. So, there must have been multiple clients accepted. But maybe a client didn't send a request. You should put that loop inside a try..finally block to ensure the list is always unlocked. The list will never hold a freed object, ie the pointers in it are always valid while inside of the lock. Make sure you are not accessing the pointers outside of the lock. There is no guarantee that a client assigned to a Context is still connected to the server while you are accessing the list. But the objects in a Context will still be alive while the list is locked.

I'll rephrase. Prior to the introduction of 64bit, the Tag was an Integer and pointers fit in an Integer, so it was common to store pointers in a Tag. When 64bit was added, the Tag became a NativeInt to preserve existing code in common use.

That is correct. The TService's DataModule is created in the process' main thread, whereas its On(Start|Execute|Stop|Shutdown) events are called in a worker thread.

Never a good idea... This function is not very accurate. A file can fail to open for any number of reasons, and you are treating all errors as success. A more accurate approach would be to open the file in exclusive mode and then check if the error code is ERROR_SHARING_VIOLATION specifically. Can you be more specific? What is the actual problem you are having with it?

An AV near address 0 usually means a nil pointer is being dereferenced. Did you try debugging your service? Where and how are you creating the Python Engine?

That is actually quite common, and is why the Tag is a NativeInt to begin with.

I can't answer that, since I don't know where you got those source files from to begin with. Those are 3rd party units, so you will have to figure out who authored them and ask them for updates, or find alternative replacements. This has nothing to do with Indy.

There has never been a 0.7 version of OpenSSL. In 2010, OpenSSL was at 1.0.0. 0.9.8 was released in 2005. OpenSSL 1.1.0 was released in 2016, and had significant changes to OpenSSL's APIs that are not backwards compatible with the older version your code apparently depends on. Your code needs to be updated to work with the newer APIs.

True. Now I see what the code is doing. It's stuffing the first 4 (32bit) or 8 (64bit) characters of the string directly into the NativeInt's bytes. So, if the string is longer than the NativeInt can hold, the remaining characters get lost. Storing the string's pointer into the NativeInt would preserve the entire string, but at the cost of having to manage its reference count properly.

Very bad idea. ReadTagString() is not so bad, but IDK what WriteTagString() is trying to accomplish. It is converting characters into bytes, completely ignoring the pointer that is inside the string. It is not the inverse of ReadTagString().

😎

Yes, the ssl-oauth branch was registering the components on the palette, but I did not have actual icons for them until right before I merged the branch. I didn't have a chance to test the icons in the IDE.

You can't add a new property to all components. But, the existing Tag property is a NativeInt, so it can hold a String (which is just a pointer under the hood), eg: var tagStr: NativeInt := 0; String(Pointer(tagStr)) := SomeString; SomeComponent.Tag := tagStr; ... var tagStr := SomeComponent.Tag; SomeString := String(Pointer(tagStr)); Just make sure you release the String properly before the Component is destroyed, eg: var tagStr := SomeComponent.Tag; String(Pointer(tagStr)) := '';

That's good to hear, thanks. Though, PR299 is closed now. There is new effort for OpenSSL 3x support in a new repo: https://github.com/IndySockets/IndyTLS-OpenSSL https://www.indyproject.org/2024/08/05/ongoing-work-in-indy-for-openssl-updates/ Oh good, glad to see they made it onto the palette ok. The icons were a last-minute addition. https://github.com/IndySockets/Indy/wiki/Updating-Indy#delphicbuilderradstudio-101-berlin-and-later

Sorry, I meant the TApplication(Events).OnDeactivate event, not the form's OnDeactivate event. You can't click on another form in your app since it has been disabled by the modal form. But, if you click outside of the app then the modal form will lose focus, triggering the TApplication(Events).OnDeactivate event. You can then close the modal form.

You can call the form's Close() method, or set the form's ModalResult property, in the form's OnDeactivate event.

It is generally best NOT to open an old project in a new IDE, but to instead create a new project fresh and add your existing source files to it as needed. This has always been the common advice given through the years.

It doesn't matter if the username and token come from a UI or a database or a config file or an automated process. It's all the same when it gets down to the SMTP level.

I have since merged the sasl-oauth branch into the master code earlier today.

Yes. There has never been an satOAuth2 option for the AuthType property. The correct option is satSASL instead. And then you can add a suitable TIdSASL-derived component to the TIdSMTP.SASLMechanisms collection. But Indy's master code does not have a SASL component for OAuth yet... The status of that branch has not changed, I still need to merge it into the master branch. It is on my TODO list. In the meantime, it is possible to use the TIdSMTP.SendCmd() method to manually send the relevant XOATH2 command per Gmail's documentation (https://developers.google.com/gmail/imap/xoauth2-protocol), eg: var creds: string; creds := Format('user=%s'#1'auth=Bearer %s'#1#1, [Username, Token]); IdSMTP1.SendCmd('AUTH XOATH2 ' + TIdEncoderMIME.EncodeString(creds), ['235']); // Update the DidAuthenticate property so Send() won't try to authenticate again... IdSMTP1.AuthType := satNone; IdSMTP1.Authenticate; Alternatively, you can use the sample code from this repo: https://github.com/geoffsmith82/GmailAuthSMTP/

Can you provide a more complete reproducible example? Are you suggesting that when your custom TreeView is placed on a TForm then the TreeView shows a green background, but when the TreeView is placed on a TFrame than the TreeView does not show a green background? Is it only limited to IDE plugins, or do you have the same problem if you use the TFrame in an application?

I haven't seen anything yet.