Uwe Raabe

That doesn't guarantee that it turns out as feasible.

Ways to add the old reports to the new system is still discussed internally. The presence of two disjunct systems is sub-optimal, but better than the state before.

Actually there is: Embarcadero Quality Portal Mor information here: Delphi 12.1 & New Quality Portal Released

The compiler setting can be overwritten in code by the {$A and {$ALIGN compiler directive. To avoid irritations it might be better to place an {$A4} directly in front of the record declaration. BTW, I was able to read the file correctly with the declaration shown above with Delphi 12.

Did you try Double Word?

It is OK. The long name is Delphi 12 Update 1.

The data file has 140.748 bytes - that doesn't work well with 971 records, but with 951 records with 148 bytes each. That record size also matches the actual file content. You may get better results with this declaration: lexrec = record root_part: string32; filler: string[2]; case speech_part: valid_range of - 1: (suppletive_type: supp_rec); 0: (nsupp_type: integer); 1, 2, 3, 4, 5: (normal_type: normal) end;

Note that the Implicit string operator can make you fall into the same parameter order trap as AddToStock is for NativeInt. To avoid that, you may prefer to replace the operator with a dedicated ToString function, keeping the original call to ShowMessage: type TProductID = record ID: nativeint; public class operator Explicit(A: TProductID): NativeInt; overload; class operator Implicit(A: NativeInt): TProductID; overload; function ToString: string; end; class operator TProductID.Explicit(A: TProductID): NativeInt; begin Result := A.ID; end; class operator TProductID.Implicit(A: NativeInt): TProductID; begin Result.ID := A; end; function TProductID.ToString: string; begin Result := ID.ToString; end; --- procedure TForm6.AddToStock(pid: TProductID; cnt: nativeint); // Both uses internally nativeint begin ShowMessage(pid.ToString); end;

One option would be to add some operator overloading to TProductID: type TProductID = record ID: nativeint; public class operator Explicit(A: TProductID): NativeInt; overload; class operator Implicit(A: NativeInt): TProductID; overload; class operator Implicit(A: TProductID): string; overload; end; class operator TProductID.Explicit(A: TProductID): NativeInt; begin Result := A.ID; end; class operator TProductID.Implicit(A: NativeInt): TProductID; begin Result.ID := A; end; class operator TProductID.Implicit(A: TProductID): string; begin Result := A.ID.ToString; end; This allows to write something like this: var cid : TCustomerID; var pid: TProductID; pid := qryGetStockProductID.AsInteger; cid := qryGetStocCustID.AsInteger; --- procedure TForm6.AddToStock(pid: TProductID; cnt: nativeint); // Both uses internally nativeint begin ShowMessage(pid); end; Note that the operator to convert TProductID to NativeInt is Explicit instead of Implicit. That prohibits the use of TProductID as a NativeInt parameter and the compiler throws an error when the parameters to AddToStock are given in the wrong order.

I guess that is caused by the {$ELSE} part of the TESTINSIGHT conditional. You can safely remove that: System.SysUtils, {$IFDEF TESTINSIGHT} TestInsight.DUnitX, {$ENDIF } DUnitX.Loggers.Console, DUnitX.Loggers.XML.NUnit, DUnitX.TestFramework,

AFAIK, that Package output directory is only used when you build a package (hence the name). For other projects the Output directory is used. In other words, the DRC file is always placed where the compiled binary goes.

I have written a couple of applications for CNC machines. The majority are for wood working and those usually have a resolution of 0.001 mm. Therefore the Epsilon used for matching element start/end points is set to 0.0005. When calculating parallel contours there often are cases where very small elements appear that have to be removed and the disjunct neighbors need some trimming to an intersection. These cases need a much finer epsilon than the first one. Side note: Regression tests comparing float calculations created under Win32 can easily fail when executing on a Win64 platform.

I beg to differ here. The approach is to have a decent epsilon when no one is given. It doesn't prohibit anyone to give an epsilon appropriate to the current scenario. The default values currently used actually cover a common beginner's mistake assuming that floats can be compared for exact equality. Usually the IsZero implementation works pretty good for the majority of the cases - at least those I encountered myself. Perhaps you just never stumbled about code using them appropriately?

Actually, they are not that magic:

Actually that is not the case. The developer license is needed for the Interbase Server, while the Client doesn't need a license - only access to the Interbase Server (i.e. the server PC has to be up and running and the client needs to establish a connection to it). Regarding the Firebird suggestion: Don't try to install Firebird (Server or Client) on a PC where Interbase already is installed unless you know exactly what you are doing. Most likely you will break at least one of these installations.

As far as I can see there are no changes in the implementation. Also a quick console example shows no regression. Can you please provide the source for your test case to verify? BTW, could it be only a problem with Watch Variables?

I'm not sure if that is what you are after: Dataset Enumerator Reloaded. The current location for the unit described in that article is now on GitHub as part of my CmonLib library: https://github.com/UweRaabe/CmonLib/blob/main/source/Cmon.DataSetHelper.pas The code allows to retrieve the current record of a dataset either as a record or a class. The record example shown in the article requires the declaration of a record type [DBFields(mapAuto)] TEmployee = record EmpNo: Integer; LastName: string; FirstName: string; PhoneExt: string; HireDate: TDateTime; Salary: Double; end; With that you can retrieve the data of the current dataset record like this: var Employee: TEmployee; begin { Show the employee's name and the hire date. } Employee := QuEmployee.GetCurrentRec<TEmployee>; ShowMessage(Format('%s %s was hired on %s', [Employee.FirstName, Employee.LastName, FormatDateTime('dddddd', Employee.HireDate)])); end; The article also has another example using a class instead of a record.

Seems to be a known issue: https://quality.embarcadero.com/browse/RSP-23505 Assuming that the Tools - Editor - Line Endings setting is still set as default, the question is: Why doesn't the IDE fix these wrong line endings to CRLF on loading?

The question is: Do you want the current form to close before you have entered the data in the new one or after that?

I suggest to open a support ticket for Registration & Installation via https://www.embarcadero.com/support

As long as you don't change it, any field in a new record is initialized with Null. A TDBCheckBox displays a NULL as grayed - that is what you see. The easiest way to avoid this is to wire the OnNewRecord event of the dataset and initialize the relevant fields with False.

How do you currently write a date?

Perhaps I have a different concept of selected, but any non-empty dataset always has a current record, wich is where the indicator is when dgIndicator is part of the options. The field values from the dataset resemble this current record/row. In addition to this current row, a TDBGrid also has some SelectedRows represented by a TBookmarkList. So with do you mean the current row or the bookmark list?

You need Version 13.1.0.2220 for that.

Probably because of this one: https://quality.embarcadero.com/browse/RSP-38387