Lajos Juhász

You're right. A hidden file can be replaced only with a hidden file. Unfortunately you cannot create a hidden file as in FileCreate the attribute is hard coded to be FILE_ATTRIBUTE_NORMAL.

I think is a poorly engineered code for the IDE. As I scanned the code most probably only the initialization section requires the VCL.Controls and for this one: GroupDescendentsWith(TOleServer, Vcl.Controls.TControl); I've no idea where is this used as find in files returns that RegGroups is only used in System.Classes so my guess is that it is for the IDE. Why they polluted the code only to be used in the IDE? Most probably it could be moved in some package used only by the IDE and not pollute user executables. I wonder what @Marco Cantu, @David Millington or @Dmitry Arefiev can publicly say about this case.

I've tested on at 2K resolution, both 100% and 150% working without a problem. Instead of TLMDButton I used TButton (when possible you should report bugs on a standard components so anyone can verify).

In order to get the stack overflow you've to activate the debug the IDE. Create a new empty package. In Run -> Parameters set Host application to C:\Program Files (x86)\Embarcadero\Studio\21.0\bin\bds.exe. Run and click continue for the Debugger exception notifications. When the second instance of the IDE appear open a project and then you can see the stack overflow.

For me also the IDE asked for international characters (looks like the forum likes to insert those ones). Congratulation you managed to make Delphi unresponsive without debugging. With debug I also get: Project bds.exe raised exception class $C00000FD with message 'stack overflow at 0x51ef04f2. :51ef04f2 ; C:\Windows\SysWOW64\msxml6.dll :51f16f2d ; C:\Windows\SysWOW64\msxml6.dll :51f56860 ; C:\Windows\SysWOW64\msxml6.dll :51f296da ; C:\Windows\SysWOW64\msxml6.dll :51f566ea ; C:\Windows\SysWOW64\msxml6.dll :51f18b90 ; C:\Windows\SysWOW64\msxml6.dll :51f18163 ; C:\Windows\SysWOW64\msxml6.dll xmlrtl.Xml.Win.msxmldom.TMSDOMNodeList.get_length xmlrtl.Xml.XMLDoc.TXMLNode.GetIsTextElement :0c1b42ec ; c:\program files (x86)\embarcadero\studio\21.0\Bin\IDELSP270.bpl :0c1b4390 ; c:\program files (x86)\embarcadero\studio\21.0\Bin\IDELSP270.bpl :0c1b4390 ; c:\program files (x86)\embarcadero\studio\21.0\Bin\IDELSP270.bpl :0c1b4390 ; c:\program files (x86)\embarcadero\studio\21.0\Bin\IDELSP270.bpl :0c1b4390 ; c:\program files (x86)\embarcadero\studio\21.0\Bin\IDELSP270.bpl .....cut, here the IDELSP270.bpl repeats 9992 times..... :0c1b4390 ; c:\program files (x86)\embarcadero\studio\21.0\Bin\IDELSP270.bpl :0c1b4390 ; c:\program files (x86)\embarcadero\studio\21.0\Bin\IDELSP270.bpl fmx.FMX.Platform.Win.TPlatformWin.ThreadSync(???) rtl.System.Classes.StdWndProc(1705986,0,0,0) vcl.Vcl.Forms.TApplication.ProcessMessage(???)

I've tried to compare XML documentation in XE5 and 10.4. For this I've copied an example from the documentation http://docwiki.embarcadero.com/RADStudio/Sydney/en/XML_Documentation_Comments: /// <summary> Removes the specified item from the collection /// </summary> /// <param name="Item">The item to remove /// </param> /// <param name="Collection">The group containing the item /// </param> /// <remarks> /// If parameter "Item" is null, an exception is raised. /// <see cref="EArgumentNilException"/> /// </remarks> /// <returns>True if the specified item is successfully removed; /// otherwise False is returned. /// </returns> function RemoveItem(Item: Pointer; Collection: Pointer): Boolean; begin // Non-XML DOC comment // ... end; In the attachment its clear that 10.4.1 in order to save some space will combine summary, parameter descriptions, remark and return value. I why is this changed?

It's now working again in Delphi 10.4.2.

You forgot to remove the build event. I've tested with Delphi 10.4.2 and the bug is still there: --------------------------- Unexpected Memory Leak --------------------------- An unexpected memory leak has occurred. The unexpected small block leaks are: 13 - 20 bytes: UnicodeString x 2 21 - 28 bytes: UnicodeString x 4 45 - 52 bytes: TTreeNode x 6 --------------------------- OK --------------------------- PS. It looks like that seBorder in the TListView's Styleelement is the problem. Remove it and the leak dissapear!

while FDTableTask.EOF do begin FDTableTask.First; end; This is not correct first will move the cursor to the beginning of the query. You should call FDTableTask.Next, also if the loop contains only the call for the next record you can replace the loop with FDTableTask.Last to jumb to the last record.

The source of Indy is delivered with Delphi so you can find it easily. It's in IdGlobal.pas.

IMHO it's not the sam RSP-24383 is about var parameters. The parameter intToStr is not a var parameter. For example: procedure TForm1.FormCreate(Sender: TObject); var i: record a,b,c: integer; end; a: integer; begin i.a:=i.b; IntToStr(a); IntToStr(i.c); end; I have only one warning: [dcc32 Warning] Unit1.pas(35): W1036 Variable 'a' might not have been initialized

I have found a case that there is no warning for records: procedure TForm1.FormCreate(Sender: TObject); var i: record a,b : integer; end; begin showmessage(IntToStr(i.a)); showmessage(i.a.ToString); end;

If you have enough decimals you can do: Hours + minutes / 60

You mean

Only if the QP entry is entered for released version of Delphi. The entries for beta versions are usually locked and can be seen only by the beta testers.

Now I understand Unicode for now is only the subset of the Unicode that the Delphi IDE can display correctly and that's not the definition of a Unicode editor. The editor in the IDE can display only the subset of a Unicode.

Are you sure about that? Pleas try to paste this to the IDE (example from: https://en.wikipedia.org/wiki/Precomposed_character) Åström (U+0041 U+030A U+0073 U+0074 U+0072 U+006F U+0308 U+006D) The result is: It doesn't render it well. If you assign this string to a label.caption then Windows will display it correctly: Even if I paste the code from Delphi here the forum can display it correctly. procedure TForm4.FormCreate(Sender: TObject); begin label1.Caption:='Åström (U+0041 U+030A U+0073 U+0074 U+0072 U+006F U+0308 U+006D)'; end;

My code is simple type TForm1 = class(TForm) FDConnection1: TFDConnection; FDQuery1: TFDQuery; FDQuery1field1: TStringField; FDQuery1calcfield: TStringField; DBGrid1: TDBGrid; DataSource1: TDataSource; Button1: TButton; procedure Button1Click(Sender: TObject); procedure FDQuery1CalcFields(DataSet: TDataSet); procedure FDQuery1FilterRecord(DataSet: TDataSet; var Accept: Boolean); private { Private declarations } public { Public declarations } end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.Button1Click(Sender: TObject); begin FDQuery1.Filtered:=true; end; procedure TForm1.FDQuery1CalcFields(DataSet: TDataSet); begin dataset['calcfield']:=varToStr(dataset['field1'])+' data'; end; procedure TForm1.FDQuery1FilterRecord(DataSet: TDataSet; var Accept: Boolean); begin Accept:=copy(varToStr(dataset['calcfield']),1,1)='1'; end;

I was able to reproduce this behavior when Application.MainFormOnTaskbar := false and the third form is modal with PopupParent is the mainform.

I've tried with calculated field to use in OnFilterRecord and it worked, the grid displayed only the filtered records.

Calculated fields are working in FireDAC and you can use them to display data. However, in order to filter data instead of filter property you can use the OnFilterRecord event. For Example: myQuery.Filter:='cTaxYear = ' + QuotedStr( '2008-09' ); myQuery.Filtered:=true; You can use: For query myquery and form myFormFRM you can write: myQuery.OnFilterRecord:=FilterTaxYear; myQuery.Filtered:=true; procedure myFormFRM.FilterTaxYear(DataSet: TDataSet; var Accept: Boolean); begin Accpet:=VarToStr(DataSet['cTaxYear'])='2008-09'; end;

According to my test with calculated fields you can use only the OnFilterRecord event to filter the data. In my test calculated field didn't worked as expected with the filter property. Is it a bug or buy design I have no idea only @Dmitry Arefiev could give an answer.

Google returned this: http://www.drbob42.com/blog/Blog.aspx?RootId=5:3791 Delphi 2010 introduces theming for the TDBGrid control, using the DrawingStyle property (which can be gdsThemed (default), gdsClassic or gdsGradient) and introducing GradientStartColor and GradientEndColor for the latter. It's not the only change made to the TDBGrid control, unfortunately. New are also the dgTitleClick and dbTitleHotTrack flags in the Options property. And although there's no documentation for them in the help (yet), it's pretty obvious what they do. Specifically, setting the dgTitleClick flag in the Options property will ensure that the OnTitleClick event handler is called (when assigned) when someone clicks on the title. Their intended meaning isn't the issue here. And when you place a new TDBGrid component on a form, the options dgTitleClick and dbTitleHotTrack are included in the Options property by default. However... when you take an existing VCL forms application, and open it up with Delphi 2010, then these previously unknown Option flags will not be in the DFM file, so they will not be set, and hence dgTitleClick and dgTitleHotTrack will be false. And as a surprise the OnTitleClick event handler is no longer called. Simply by recompiling an existing Delphi VCL application in Delphi 2010. Ouch! So, if you or your customers suddenly find that clicking on TDBGrid titles no longer works, check the dgTitleClick flag of the Options property (of all your TDBGrids).

We have zero information about what kind of bug is in the compiler. It can be a 5 second fix or can require a rewrite. I doubt that rollback to Delphi 10.3 is an option otherwise why would anyone change the compiler? As a software developers I think it is reasonable that we can understand that even that there is a bug for some cases nobody tries to rush fixes to be published and risk to introduce new bugs (and make the situation worse). For these kind of things it's better to test and be sure that it's working. BTW. I am also in the process to move from old versions to 10.4 and I am also not happy the state of the IDE and compiler (after these fixes and one minor version there are still known bugs).

It also can be that the application is generating a memory leak log when ReportMemoryLeaksOnShutdown := True it can take longer whene there is an extended leak to report.