Uwe Raabe

You can as well combine both avoiding the hide effect: TBar = class(TFoo) procedure Terminate; reintroduce; overload; end;

"The Dialog" in this context is the whole Project Options dialog - not only this special part of it about Runtime Packages. That is even exactly what David describes in his article.

There are already a couple of issues regarding these controls in the title bar. I suggest to add this to QP so it can be fixed together with the other ones.

David Millington explains in his blog post New in RAD Studio 10.3: Options Dialog Improvements in the section Dialog Search.

My comment has been anything but a personal insult! Bugs cannot be stupid! People can be stupid, so programmers can be stupid, but I would never rate any programmer stupid because of bugs resulting from some oversight, missing test case or incomplete specification. Especially if I don't even know that programmer.

Bugs are never stupid, they are not even clever either. That makes me remember a variable declaration in UCSD Pascal: stupid: boolean; { student programmer id }

AFAIK, Pervasive is not a directly supported database in FireDAC (only via ODBC). Therefore it may be necessary to handle those AutoInc fields manually as described in the documentation.

There actually is some documentation about this: Auto-Incremental Fields (FireDAC)

What database are you using?

At least it already compiles to it.

Indeed, and you can as well send that patch via email to the person supposed to take care of it. On the other hand, if you want to use a Pull Request, so any maintainer of the original repo can take care of it, you must somehow provide that patch in a form that it actually can be pulled - i.e. in form of a forked clone containing the patch. The lack of active maintainers for these projects (as unfortunate as it is) cannot be blamed on the DVCS, though.

I can imagine that the excessive use of branches in DVCSs may frighten users grown up with SVN. I also needed some time to get familiar with that in the beginning, but it makes life a lot easier after I was able to grasp the concept.

In fact, you can even have both: The Old Component Palette is simply a toolbar which can be made visible or hidden via View - Toolbars - Component. The New Component Palette is a tool window that can be reached via View - Tool Windows - Palette. Make sure to save your layout to make your changes permanent.

As far as I can see for now, that is not possible with the convenience methods of TJson. You will have to (de-)serialize the list in your own code. Currently I am not aware of any way to register a converter/reverter globally. Unfortunately that requires to copy some code currently hidden in private methods.

That would also require to change type TThingList = class(TJsonList<TThing>); into type TThingList = TJsonList<TThing>;

You can also have a look at the DUnitX IDE Expert: https://github.com/VSoftTechnologies/DUnitX/tree/master/Expert

So you want the output of "new way" be the same as in "current way"? Can you provide a small but working example program producing both of the above outputs?

That is why those files have to be copied into the builded_dcu folder. You can see the same issue with the standard library folders of the Delphi DCUs. The DFM and RES files can also be found there.

Why don't you use MultiPaste in the first place and let it add the comma after each line. Then you end up with only one remaining error for the semicolon at the last line.

Will have a look when I am back next week.

The two classes are probably already existing classes derived from TDataSet with only a very little chance to adjust that.

Indeed, when you ask for the date you will get 0 even when the DB field is NULL: function TDateTimeField.GetAsDateTime: TDateTime; begin if not GetValue(Result) then Result := 0; end; Unfortunately you cannot distinguish that from a valid date (unless you narrow the range for those). I would prefer when the above function would actually return a non-valid date in that case, but I guess that would break compatibility. Meanwhile, the trick is not to ask for a date in the first place when the field is NULL. To store such an invalid date into a TDateTime field the NullDate approach is quite valid. Actually any value below -DateDelta ( = 693594) would do, as it results in a non-positive Date part of a TTimeStamp and makes DecodeDateFully return false. The chosen value of NullDate = -700000 ist just a bit easier to remember.

There is a similar constant in Vcl.WinXCalendars.pas, albeit only private. I recently had a case where that 0 DateTime value was used instead of NULL in a database. As long as you are keen to update all your customers databases, you better stay with that value and its meaning.

That is somewhat against the introducing condition ruling that option out in the first place.