Andrew Spencer

Using Delphi 11.3 I often have a situation where the .Visible property of a control depends on the .Checked property of a TCheckBox (or similar). To do this, I typically write an OnClick event for the TCheckBox, and set the .Visible property of the target control in a single line of code e.g. TargetLabel.Visible := SourceCheckBox.Checked; I also make sure to call this OnClick event at startup, if I happen to need to load the .Checked state from a previously-saved registry or Ini file entry. I thought that LiveBindings was designed to help me get rid of needing to write OnClick events. So to test I set up a TForm with a TLabel and a TCheckBox, with LiveBindings Designer as follows: My expectation was that, from then on, the TLabel.Visible property will simply follow the state of the TCheckBox.Checked property. No additional code would need to be written. BUT, it didn't work exactly as I expected. Question 1 : When I run this, the TCheckBox.Checked property initialises to the Design-time setting of TLabel.Visible. Setting TCheckBox.Checked to True at Design-time is ignored. Why is it not the other way around i.e. The TCheckBox.Checked value, at Design-time, determines the TLabel.Visible property at Run-time? That's the way that the arrow is pointing. This only appears to happen AFTER the application is up and running i.e. clicking on the TCheckBox will alter the visibility of the TLabel accordingly. Question 2 : How can I get this initialised, at run-time, so that the two controls start off operating correctly? I have only found that setting BOTH the TCheckBox.Checked AND the TLabel.Visible properties to the same value gets things going correctly. Question 3 : Programatically changing the TCheckBox.Checked state at runtime does not cause the TLabel.Visible property to change. Question 4 : Have I just totally misunderstood what I can do with LiveBindings, or how to implement what I want?

I've often used a derived class on TCustomControl to access a control's Canvas property. type TGetCanvas = Class(TCustomControl); and then used it later in a line similar to this: TGetCanvas(progressPanel).Canvas.TextWidth("Hello World") In trying to neaten things up, I noticed that the same type declaration was in the interface or implementation section of numerous units. I tried moving the declaration to the interface section of a "library" unit, and useing that unit in all these other units. On compilation, however, a line like the one above would raise and error "E2362 Cannot access protected symbol TCustomControl.Canvas". Why is this not functioning in the same way as if the type declaration was in the unit itself?

Ouch! OK - that makes sense. I'll have to do a work-around for how I want it to behave. Thanks, Uwe.

Apologies - I zipped up the wrong one. TCalendarViewInvalidDate.zip

A TCalendarView on a TForm, with a TMemo. In the TCalendarView's OnClick event, add a line to the TMemo showing when the OnClick event happened, and the formatted and integer value of TCalendarView.Date. In Delphi 10.4.2 I am seeing that with consecutive <1Hz clicking on the same date, a "bad" date value is returned on every second click returns a null date. Also, when clicking >~1Hz, this can produce multiple "bad" dates. The "bad" date value is -700000 (if you take the Trunc() of it). Does anyone have any ideas? TCalendarViewBadDate.zip

Why can I set the Font.Color property, in Delphi 7, for controls like TCheckBox (and descendents TDBCheckBox etc) TRadioGroup and get the expected result. But in Delphi 10.4.2 everything remains clWindowText (or clBlack). TLabel.Font.Color works, but most other controls do not. Have I really just not noticed this for the past few years!?

I am only using TEdgeBrowser to display the "Release Info" for my software. So it turned out that setting the temporary folder and making sure that the " EBWebView" folder that gets created there (and all sub-folders) are deleted, before calling the .Navigate method was quite suitable for my needs. There was no need to preserve all the additional functionality stored in the cache, as detailed in the Microsoft documentation. Thanks for the responses!

I'm using EdgeBrowser1.UserDataFolder to set up the temporary folder for cache management (as detailed in https://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_TEdgeBrowser_Component_and_Changes_to_the_TWebBrowser_Component) Is clearing the cache as simple as deleting the 'EBWebView' folder that gets created, before navigating with the TEdgeBrowser?

Everything in the Registry looked fine, so I made no changes there. I did delete a couple of folders of old/unused JEDI CL and VCL from My Documents\...\CatalogRepositry That fixed the problem. (Of course, this was nowhere near what the original pop-up message advised to be done!) Thanks

During the Delphi 10.4.2 splash screen, I always receive the following Information dialog: "RAD Studio found some failed deferred GetIt packages. You can revise the list of packages that failed in the GetIt Packages dialog box, and decide to cancel them or try to process them again when the IDE is closed." The closest that I can find to a "GetIt Packages dialog box" is the menu item Tools -> GetIt Package Manager. This does not offer any "list of packages that failed" or any further clue to solving/permanently removing the condition which causes the above message. Any ideas?

Components that are anchored to the right of a form are having their Left (and Width, if also anchored to the left) properties altered following saving. Values seem to be decreasing by 4. This appears to be an IDE bug and has been described and reported at https://quality.embarcadero.com/browse/RSP-39606 If you have seen this happen in your project, or can confirm it on your installation, please vote for the bug report to raise the response level. Otherwise, does anyone have a solution to this problem?

RSP-39760 has been restored, and has now moved from status "Reported" to status "Open" ("The issue is open and ready for the assignee to start work on it.")

Thanks for the suggestion, Remy. After some looking around, I've settled on replacing all the Delphi TRESTxxxxx operations with the offering from Chilkat. It's a slow job, trawling through all the code, but it looks as if it will save the day.

RSP-39760 at https://quality.embarcadero.com/ (and in my frustration, I had caused a double entry - also RSP-39755!) Please also add comments there, or vote.

Uwe, I tried this immediately on seeing your post, and it worked (once). But then it stopped working. In the past few hours, with reboots and various other attempts at fixes, it has somehow worked, but again only once. Closer, but it is not (yet) the solution. In WireShark I do now see that TLS 1.3 is now being used in the transactions, but the 12175 error persists. I have been trying things on two separate PCs - one with Delphi 11.1 / Windows 10 and the other with Delphi 10.4.2 / Windows 10