Remy Lebeau

Same here. Do you have all of the available patches installed for 12.3?

As I said earlier, you are getting the event when the new item's default state image is assigned. More specifically, when TListView.Items.Add() creates a new TListItem object and inserts it into the TListView.Items, it calls the Win32 ListView_InsertItem() function, which immediately sends the TListView a LVN_ITEMCHANGED notification before it returns. In that notification, the item's uChanged field is LVIF_STATE and the state image has changed index from 0 to 1. That condition is what fires the OnItemChecked event. The item is fully initialized from the Win32 perspective before TListView.Items.Add() returns. Anything you do extra to the item after Add() returns is optional, and is initialization from your perspective, not the Win32 perspective.

The checkboxes are implemented as state images. You are getting the event when the item's initial state is assigned. Just check for the nil condition and don't access the object when it's not ready yet: procedure TForm1.ListView1ItemChecked(Sender: TObject; Item: TListItem); begin if Assigned(Item.Data) then TSomeLinkedObject(Item.Data).Enabled := Item.Checked; end; Alternatively, disable the event when adding an item, and then re-enable the event when ready: ListView1.OnItemChecked := nil; var Item := ListView1.Items.Add; ... ListView1.OnItemChecked := ListView1ItemChecked;

You don't need to create an instance of your hint class. By setting the HintWindowClass variable, the VCL will instantiate your class when needed. In any case, the reason your code doesn't work is because by default THintWindow responds to WM_NCHITTEST to return HTTRANSPARENT, thus all mouse activity gets directed to the window that is underneath the hint. You can intercept WM_NCHITTEST yourself to return HTCLIENT instead, so thus your WM_LBUTTONDOWN handler will be triggered when clicking on the hint window. However, then you run into a new problem, because as soon as the mouse enters the hint window, it effectively leaves the control underneath the hint, and thus the control hides the hint immediately before you can click on it. You can work around that by having TMyHintWindow override the virtual ShouldHideHint() method to return False. Then, you will have opportunity to click on the hint window. However, then you run into a new problem, because as soon as your click closes the hint, the mouse will effectively re-enter the control that was underneath the hint, and the control will reshow the hint again. Isn't this fun? What exactly are you trying to accomplish by messing with the hint window's default behavior?

The correct link is https://docwiki.embarcadero.com/Libraries/en/Vcl.Forms.HintWindowClass Also, you don't need to assign the HintWindowClass before Application.Run() is called (though you certainly can). Just be sure to assign it before any hints are displayed at runtime. For instance, in the MainForm's OnCreate event would suffice. Also, if you don't want to override the hint behavior globally, you can customize the hint on a per-invocation basis by using the TApplication[Events].OnShowHint event. It gives you access to a THintInfo describing the hint that is about to be displayed, which has a HintWindowClass field (amongst many others).

Try using WNetAddConnection2() or WNetAddConnection3() to establish a connection to the folder with user/pass before then accessing the files.

That would need to be a discussion for the beta testers to have in private.

You can always use VMs for betas. But I hear you. I usually don't have spare time to actively do any testing, but I do like to join in to see what's coming ahead of time.

What kind of problems, exactly? Less tolerant of what? I don't understand the question. Huh?

That should have no effect on TIdHTTP, as it internally toggles the PassThrough property based on whether an HTTP or HTTPS url is being requested.

In OpenSSL, SSL 3.0 and TLS 1.x share some common code during the handshake, so you may see references to SSL3 when TLS is actually being used. Nor should you, except when you have very specific security requirements. If you don't set a CipherList explicitly, a default one is used, which should usually be suitable for most tasks. HOWEVER, do note that in July 2018 (between D10.2 and D10.3), there was a behavior change made in Indy. Maybe that is contributing to your issue? Prior to the change (ie, in the Indy bundled with XE7), if the CipherList was empty then Indy used a hard-coded cipher list that was taken from the OpenSSL SDK: 'AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH' After the change, Indy no longer uses that. It now lets OpenSSL use whatever default cipher list it was compiled with. If IsTLSv1_2Available() returns False, that means the OpenSSL DLLs you are using do not export the TLSv1_2_method(), TLSv1_2_server_method() and, TLSv1_2_client_method() functions. I can assure you that the OpenSSL 1.0.2 DLLs in Indy's GitHub repo DO export those functions. Note, if Indy doesn't detect TLS 1.1 and TLS 1.2 are available, it will silently fallback to TLS 1.0. That might also be contributing to your issue. Just to check, what does Indy's OpenSSLVersion() function report for you after the DLLs are loaded? I would also suggest using SysInternals Process Explorer to view your app's process at runtime and verify that your app is actually loading the expected OpenSSL DLLs and not some other incompatible OpenSSL DLLs that may be located elsewhere on your PC.

Then you will have to escape control characters manually, which QuotedStr() doesn't do for you. But, you really shouldn't be concatenating strings to create SQL queries to begin with. Use a parameterized query instead, letting the DB enging handle all of the escaping and quoting for you. Or, use a blob stream (though, I would use TFQQuery.CreateBlobStream() instead of creating TFDBlobStream directly, but either way works). AFAIK, RTF does not use ASCII control characters. Line breaks are handled by \line and \par control words. And there should be no #0 characters at all. That being said, if there are raw line breaks in the RTF, it might be for human reading purposes, but not machine reading. Delphi 12 uses RichEdit 4.1 (since D11) , which is the current version available from Microsoft at this time. I don't know offhand what version of RTF it supports. RTF is encoded in ASCII, which fits in 8bit (AnsiChar) characters in memory, so you don't need to waste memory using 16bit (WideChar) characters to hold it. A Delphi String is 16bit since D2009. This is why I suggested using varchar instead of nvarchar in the DB. Or, a blob field will suffice, too.

The last archive of Addictive's website before it went offline does indeed claim there was a 4.9 release: https://web.archive.org/web/20230712232007/http://addictive-software.com/ > 18 March 2015 > > Addictive Software is pleased to announce the release of Addict 4.9.

RTF is encoded in plain ASCII text, where non-ASCII characters are escaped. So, you should not need a blob for this, a simple text field will suffice (although, you might consider a blob if you want to store the RTF using 8bit characters but don't want to use varchar instead of nvarchar). Have you tried simply saving the RTF from the RichEdit into a UnicodeString (ie nvarchar) or AnsiString (ie varchar) variable and then load it back in, without involving a DB at all? Set the RichEdit.PlainText property to false to tell the RichEdit to act on RTF, and then use the RichEdit.SaveToStream() and RichEdit.LoadFromStream() methods to get and load the RTF. You can then expand on that logic to introduce text handling with a DB.

Didn't the emails give you direct links to the tickets? If you need to find your tickets, you can login, choose the desired portal, click on your profile icon in the upper right corner, choose Requests, and filter by "Created by me".

No, it does not support OpenSSL 3.x or TLS 1.3 at this time. But, you can use a 3rd party SSLIOHandler that does, such as TaurusTLS (https://github.com/JPeterMugaas/taurustls). Security requirements change all the time. They have to update their systems every so often to keep up. There is much more to HTTP/S than just URLs. Yes. Yes, it does, at least on the client side, and has for 8 years now.

The TComponent.Components list contains the TComponent objects that are owned by the containing TComponent for memory management purposes. All components created at design-time are owned by the parent TForm/TFrame/TDataModule that they were dropped onto. This is why your TTabSheet's ComponentCount is 0 at runtime as it doesn't own anything. The TWinControl.Controls list contains the child TControl objects that are nested inside of the containing TWinControl for UI purposes. This is why your code works when you use the TTabSheet's ControlCount as its child controls list is not empty.

UuidCreate() is a Win32 API function, not a Delphi function. If you can't reach Delphi's declaration, then just make your own declaration in your own code. There is only one physical function to detour (residing in rpcrt4.dll), it doesn't matter how many declarations there are to reach it.

The higher the resolution is, the smaller a 24x24 image is going to look. You need multiple images of different sizes, and then choose the appropriate size for a given resolution. Are you doing that? The whole point of TImageCollection is to provide images of different sizes/resolutions, and then TVirtualImageList presents those images at a given size/resolution. Where are you making adjustments based on the current resolution?

Why are you copying the Indy PostStream into a separate TMemoryStream? The PostStream is already a TMemoryStream by default (unless you use the OnCreatePostStream event to use a different stream). Why not just parse the PostStream as-is? Indy's MIME decoder also supports binary data.

Windows doesn't just arbitrarily screw up files. You must have done something to cause the files to be screwed up, ie loading them or saving them with the wrong charset. You need to use the proper charset when saving/loading files. That's where you need to fix the problem, not in the code that has already loaded the files, by then the data is already corrupted. If you have ANSI files, load them with an ANSI charset. If you have UTF-8 files, load them as UTF-8. Period. If you need to differentiate, use a BOM or other metadata, or hieristic analysis. Don't guess the encoding.

That's a little misleading. SChannel can use the SSL/TLS protocol. So, even if the server were using OpenSSL, a client could connect to it using SChannel. In any case, there is a 3rd party GitHub repo that provides an SChannel IOHandler for Indy. But DataSnap doesn't use that. Also, IIRC, it is only available for clients not servers. iOS is the only platform that Indy statically links to OpenSSL. On all other platforms, including Android, it uses OpenSSL libraries that are already present on the device, unless you provide your own lib files with your app.

That error message does not imply OpenSSL specifically. It could be any SSL library. dbExpress itself doesn't use any SSL DLLs, that's the job of the underlying dbExpress driver to decide what it needs. To remove such a dependency, you will likely need to find another dbExpress driver that supports your database engine without that dependency.

Hard to diagnose without seeing your actual setup - how the BPLs load the images, how the EXE loads the BPLs, how the EXE assigns the images to its UI, etc. Lots of factors here.

What does "template" mean from your code's perspective, though? Are your Forms using a common base class? A common styling theme? Something else? Doubtful, but anything is possible.