Andrew Spencer

I have a table with a float field, and would like to format the decimal places displayed for this value based on the content of another (integer) field in the same record. Access is via a TFDQuery. I tried to hook the OnGetText event of the float field in question with the following code, but this is giving an access violation error. procedure TfrmMain.ItemValueFormat(Sender: TField; var Text: String; DisplayText: Boolean); begin Text := Format('%.*f', [qMyTable.FieldByName('decimals').AsInteger, Sender.Value]); end; If anyone has tried something like this before, I'd appreciate some tips/code snippets. Thanks!

Answering my own questions... The line should have been Text := Format('%.*f', [TfrmMain.qMyTable.FieldByName('decimals').AsInteger, Extended(Sender.Value)]);

I get the feeling that qMyTable is no longer in scope when this event is launched

Hi Somehow in the update to Delphi 12.2, I have lost the Windows icons associated with the various Delphi file extensions (.pas, .dfm, .dpr, .dproj etc) Is there any easy/quick way to get these back?

Excellent - thank you - that did exactly what I was looking for.

I narrowed it down to Jedi Component Library. The same 3rd party installation also appeared to give the same IDE closing error with Delphi 11.3

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?

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!?

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

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

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?

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?

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!

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

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?

A very simple Delphi application (with TRESTClient, TRESTResponse and TRESTRequest) configured for a GET operation to our server fails after the most recent Windows 10 update (KB5018410 rolled out on 10 October 2022). It reports 'Error sending data: (12175) A security error occurred'. Rolling back the update works again. The URL that I am testing is https://yams.ked.co.za/version Insomnia, Firefox, Chrome, Edge and other clients have no problems with the polling. Any advice would be very much appreciated

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

Does anyone have advice on an alternative for the TRESTClient / TRESTRequest / TRESTResponse set of Embarcadero components? I have found that the ICS TSslHttpRest component does work (and uses TLS1.3), but the lack of documentation and sample code, and the odd handling of JSON mean that committing to replace all Embarcadero TRESTxxxxx operations in my code may be overly risky. The best would be a well-supported, documented (commercial) solution (or a component fix from Embarcadero!) Rolling back the Windows update is not going to be a good solution for large corporate clients spread all around the world!

I have tried to use the SecureProtocols property of TRESTClient, but it makes no difference. (In the large application that had been working fine till KB5018410 came around, I used the default, which is none of these protocols ticked) I have also tried various options (with rebooting) in the Control Panel -> Internet Options -> Advanced -> Security -> Use TLS x.x It did not change anything. I agree with Brian Evans' comment, above " No combination of settings gets it to work again on a patched Windows 10 system (KB5018410). There is some weird interaction between the patch and Delphi REST components it seems. It breaks TLS 1.2 somehow and TLS 1.3 isn't functional either." A WireShark capture, trying to access our site, shows TLS1.2 attempts, but results in a 12175 in the Delphi Application Insomnia, by contrast moves to TLS1.3 My application is attached. SimpleREST.zip

Hi Brian I agree with what you have found. I am running Delphi 11.2 patch 1 and Windows 10. This problem has also been seen under Delphi 10.4.2. As with your tests, I get no operations with any variation of the Internet Properties "Use TLS x.y" checkboxes. It sounds as if this should be raised on the Delphi bug website