Lajos Juhász

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.

The oldest bug report is from July and it's not marked as duplicated if it was a known issue they would flag it.

Unfortunately this is a well known bug in Delphi 10.4 - there was a bug report that I didn't found at first - https://quality.embarcadero.com/browse/RSP-30690 the report is from July an still open. I was a bit shocked that nobody noticed in the betas.

You should also consider to enter a QP ticket for this. I believe for this case there is no ticket yet.

Unfortunately this is Help Insight. For example http://docwiki.embarcadero.com/RADStudio/Sydney/en/Help_Insight show a picture as it was in Delphi XE5. So the expected behavior is still to generate a readable definition of the function.

According to Delphi it's not 66 days but 67: Date: 15.02.2021 Days between: 67 program Project1; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.DateUtils; var X: Tdate; begin try { TODO -oUser -cConsole Main : Insert code here } x:=IncDay(IncMonth(now, 2), 5); WriteLn('Date: '+DateToStr(x)); WriteLn('Days between: '+IntToStr(DaysBetween(x, now))); ReadLn; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end.

Also now it's running in separate process and will not bring / or slow / down the IDE. You can use the IDE to edit your code while the LSP processes are doing their jobs.

According to the Roadmap (https://blogs.embarcadero.com/rad-studio-roadmap-november-2020/) in Delphi 10.5 H2 2021 you can expect a better support for the M1 CPU. In the roadmap it's under Platform Enhancements macOS ARM (Delphi). Of course as ever please do not forget this is only planned. There is no legal bound that it will be delivered in the first release of Delphi 10.5. A more detail can be found also at https://blogs.embarcadero.com/rad-studio-november-2020-roadmap-pm-commentary/ At this moment the best you can do is to wait for the first beta for Delphi 10.5.

I would just set the property Style to csExDropDownList.

Technically there is no problem. However it could be improved: 1.) When _NewUnicodeString failes due to CharLength instead of _IntOver it should raise a more meaningful exception. For example: You cannot create string length of %d. 2.) The overflow occurs in GetTextStr. When debugging a 32 bit application you get the following call stack: :766f9ab2 KERNELBASE.RaiseException + 0x62 :41169900 :41169900 System.Classes.TStrings.SaveToStream($3033D38,???) System.Classes.TStrings.SaveToFile(???,nil) System.Classes.TStrings.SaveToFile(???) mainFRM.TForm1.Button2Click($2FCEEA0) Vcl.Controls.TControl.Click Vcl.StdCtrls.TCustomButton.Click SaveToStream is focused, this almost ok as this method calls GetTextStr. I've tried again to run the 64 bit version and I get a different call stack this time: System._RaiseAtExcept(???,???) System.SysUtils.ErrorHandler(???,$40FA0A) System.ErrorAt(5,$40FA0A) System._IntOver System._NewUnicodeString(1092000000) System._UStrFromPWCharLen('',nil {#0},???) System.Classes.TStrings.GetTextStr System.Classes.TStrings.SaveToStream($302DD30,$302CDD0) System.Classes.TStrings.SaveToFile('d:\temp\StringTest.txt',nil) System.Classes.TStrings.SaveToFile(???) mainFRM.TForm1.Button2Click(???) The IDE focuses System._IntOver instead of System._NewUnicodeString.

Now back to the original problem. This is the limitation of Delphi strings. You cannot allocate string larger than: (MaxInt - SizeOf(StrRec)) div SizeOf(WideChar) = 1073741815. Unfortunately, internally TStringList first tries to convert its content to string and using TEncoding to a byte array. That's why it is not suitable to work with large volume of text.

It's quite easy to test. I've tested using: procedure TForm1.Button1Click(Sender: TObject); var i: integer; begin i:=1024; while true do i:=i*i; ShowMessage('Completed. The result is:'+i.ToString); end; When tested using the 64 bit the call stack is: :00007FF965893E49 ; C:\WINDOWS\System32\KERNELBASE.dll System._RaiseAtExcept(???,???) System.SysUtils.ErrorHandler(???,$70AE52) System.ErrorAt(5,$70AE52) System._IntOver mainFRM.TForm1.Button1Click(???) Vcl.Controls.TControl.Click Vcl.StdCtrls.TCustomButton.Click Vcl.StdCtrls.TCustomButton.CNCommand(???) System.TObject.Dispatch((no value)) But it's not bad, double click on the mainFRM.Tform1.Button1Click and the debugger focues where the 32 bit debugger does, so it's just an extra step.

It's working for me. Try using https://getitnow.embarcadero.com/ . Also if you've used the ISO installer you've to switch getit to "online mode" (from the command line execute: GetItCmd.exe -c=useonline).

The easiest way to kill the compiler is to have huge cyclic unit dependencies. Try to reduce that. Also if the project was created before unit scope names were introduced you should add the scope names to the units in the uses lists and remove from project options in Unit Scope Names.

You are not adding WSNO as I wrote earlier you're adding a pointer to an address of a string returned by a function. You cannot do that. You should try something like this: procedure TForm1.DBGrid2ColEnter(Sender: TObject); if DBGrid2.SelectedField <> CDS1.FieldByName('WSNAME') then Exit; while not MyQry.Eof do begin DBGrid2.Columns[ColIndex].PickList.AddObject(MyQry.Fields[1].AsString, Pointer(MyQry.RecNo)); MyQry.Next; end; procedure TForm1.DBGrid2ColExit(Sender: TObject); var Inx:Integer; begin if DBGrid2.SelectedField <>CDS1.FieldByName('WSNAME') then Exit; Inx:= DBGrid2.Columns[ColIndex].PickList.IndexOf(DBGrid2.SelectedField.asString); MyQry.RecNo:=integer(DBGrid2.Columns[ColIndex].Picklist.Objects[Inx]); CDS1.FieldByName('WSNO').AsString:=MyQry.Fields[0].AsString; end;

There are multiple problems in your code: 1.) It's not a good idea to add the address value of a return value of a function - Pointer(MyQry.Fields[0].AsString) 2.) .PickList.IndexOf('WSNAME') you are searching the index for string 'WSNAME' while you most probably meant to search the index for the value of the selected field: DBGrid2.Columns[2].PickList.IndexOf(DBGrid2.SelectedField.asString)

type Texample = class private findex: integer; public constructor Create; reintroduce; published property Index: integer read fIndex write fIndex default -1; end; constructor TExample.create; begin inherited; findex:=-1; end; If it's a published property you should use the default directive (when the value of the published property equals to it's default value it's not streamed to the dfm). Even if you set the default directive it's the job of the constructor to initialize the field value.

First you've to initialize aBytes. Try something like this: setLength(aBytes, 1024); wsocket.Receive(aBytes, length(aBytes));